Semantics vs bold and italics
In his article When Semantic Markup Goes Bad, Matthew Thomas writes about why always replacing <i> and <b> with <em> and <strong> is bad, which is absolutely correct. Instead, he suggests using <i> and <b> in some situations. But doing so will prevent the separation of content from presentation, something that a lot of people are trying hard to achieve by using XHTML and CSS instead of presentational markup.
It would be nice if there was a semantic XHTML element for every markup situation, but there isn’t. You will run into situations when what you are marking up doesn’t have a perfectly matching XHTML element.
So, what is the best thing to do in those situations? Using <em> or <strong> will add emphasis to the text, and a screen reader may pronounce those words differently. Is that what you want? Try reading the sentence out loud. Does it make sense to emphasize the words you want displayed in italics or bold?
Some suggest using <span> elements, others say that <i> and <b> are the way to go when XHTML doesn’t have a suitable semantic element. Matt May, James Craig, and Lachlan Cannon are in the <span> camp, and Matthew Thomas has posted his reply to them in When semantic coders go bad.
I’m not going to suggest what to do. I think it will depend on the circumstances which method is the most correct (or the least wrong). What I believe is even more important than what you actually decide to use is that you stop to think about it, and make an effort to make your markup as semantic as possible.
- Previous post: Navigation Matrix
- Next post: Extending XHTML: Target and Strict
Information, sponsorship, and externals
About the author
Roger Johansson is a Swedish web professional specialising in web standards, accessibility, and usability. More about me and this site.
Latest articles
- Validation statistics from Nikita the Spider Comments off
- An analysis of the sites crawled by the bulk validation tool Nikita the Spider during March 2008.
- Authentic Jobs API and Affiliates program Comments off
- The Authentic Jobs job listing service now has a public API and an affiliate program.
- What does Acid3 mean to you and me? Comments off
- Opera and Apple have announced that their web browsers pass the Acid3 Browser Test, but how will that help web designers and developers?
- Designing Web Navigation (Book review) Comments off
- Learn the fundamentals of navigation design and design better navigation systems for large and small sites as well as for web based applications.
- DOMAssistant bundle for TextMate Comments off
- To save keystrokes and speed up development I have created a DOMAssistant bundle for TextMate.
- First impressions of Internet Explorer 8 Beta 1 Comments off
- My impressions after trying out Internet Explorer 8 Beta 1 for a couple of days.
Comments
Separating content and presentation is a means to an end, and not an end in itself. The ends are (1) easier redesign (you need to change much less code), (2) lower bandwidth (through non-repeated code, and CSS being cached on subsequent pages), and (3) adaptability to different output devices (e.g. speech browsers).
For (1), b/i and span are exactly equal (you can use a class with both). For (2), span is 100% worse (no caching benefit, and the tags combined are 12 characters vs. 6 characters). And for (3), span is much worse (since it doesn’t work in browsers ignoring CSS, and it works in very few browsers if you’re styling lang instead of class).
Anyway, good on you for at least thinking about it. :-)
Sorry, comments are closed for this post.