The other day, I got to thinking about the HTML elements <b> and <i>, and wondered if they were still viably usable in production code. I’ve personally never used them before but I was aware that they existed and were still very much valid XHTML markup (even in the Strict DOCTYPE!). Wondering whether I’d avoided two elements for three years unnecessarily, I did some digging.
What the facts state
<b> and <i> are still valid, and as XHTML is just an XML serialisation of HTML, pretty much all the elements apparent in the HTML spec are true of the XHTML spec too—it is, pretty much, just the way in which these elements are written that makes them different in XHTML.
With the help of @smashingmag I turned to Twitter and my knowledgeable followers and asked the question:
“Using <i> and <b> in (valid) XHTML (strict)… your thoughts on this would be much appreciated. #upcomingBlogPost Cheers all!” @csswizardry
Most of the answers I got said petty much the same thing: use strong and em … b and i are deprecated. While this is largely true, there are some myths that need dispelling.
strongandemare not the same as bold and italics. strong is strong emphasis and em is emphasis. It is purely through convention that these two elements happen to adopt either bold or italicised appearances.bandiare not deprecated in any way in HTML or XHTML. They are still in existence, still valid and still (in the right places) usable.
Some replies
A few choice replies I received which are, on the whole, representative of everyone’s thoughts:
“strong and em make more sense, especially when taking screen readers into account. @CreativeNotice
Or so you’d think, see below…
“I prefer <strong> </em> because of semantics . You want to put emphasis, not just make text italic.” @WeHelpDesign
True, if you do just want emphasis that is…
“Using <i> and <b> is just fine if it’s for visual bling without real semantic background.” @levito
Ah, this is more like it!
“<b> and <i> tags describe presentation, not structural semantics. Rather style <em> and <strong> tags.” @hornergraphic
A view that is seemingly shared by almost everyone else who responded.
What about strong and em?
The vast majority of people who replied were in favour of strong and em over b and i. Presuming all respondents were assuming the question was ‘What are your thoughts on using b and i to represent strong emphasis and emphasis, and thus replace strong and em?’ then they’d have all been spot on correct. However, b and i and strong and em are totally separate things. b and i assume no semantic value, meaning literally bold and italic respectively. strong and em however have nothing to do with bold or italics. As previously mentioned, it is through convention only that the default styling for each is so.
strong and em are ‘spoken word’ type elements, where they represent a change in tone only. This means that their styling is in no way linked to their naming, it is just that us, as people, are familiar with italicised prose sounding more stressed—or emphasised—than surrounding text. This is where the importance of aforementioned semantics and screenreaders come in. Or is it…?
The screenreader fallacy
Screenreaders don’t use strong and em!
The common belief is that strong and em’s semantic meaning is used by screenreaders to alter tonality when reading content aloud, thus letting the user know that the copy is in fact meant to be understood in a different manner to any neighbouring text. This was something I too believed until the wonderfully knowledgeable @pekingspring pointed me toward this article by @stevefaulkner—it turns out screenreaders don’t use strong and em to alter tonality!
This means that screenreaders see no semantic value in the strong and em element. However, they should be used unconditionally where a change in tone is implied, whether a screenreader will understand this or not.
Where to use <b> and <i> then?
One of my first thoughts was where to use these elements if indeed they are still usable. My initial idea was the use of i for markup up things that have to be italicised but the italics aren’t indicative of any tone. To quote the Penguin Guide to Punctuation:
“Another use of italics … is to cite titles of complete works…”
Initially I thought this was the ideal use for the i element—something that had to be in italics, yet implied no tone of voice. It was such a good fit! However, @pekingspring came to my aid again and reminded me that the cite element is for this exact purpose. That was that idea gone.
Another possible usage for the i element was gleaned from the Typography Manual iPhone app, which states:
“Italics should be used for single letters in a sentence referred to as letters. [for] example ‘The letter j appears too large.’”
An idea I had for using b was somewhat linked to the cite element anyway. A common mistake is to markup the ‘author’ of a quote in cite tags. This is of course incorrect, but what do you use? It’s not really a paragraph, so what is it? I did consider the b element for this, but I feel that such a piece of information does need a more semantic element to represent it.
Friend and colleague @simonwiffen has a very nicely written example usage for each, which I personally think are spot on. The following chunk of text is lifted directly from an internal document written by @simonwiffen:
1.4.3 Strong, emphasis, bold and italic
<strong> (strong emphasis) and <em> (emphasis) should be used as opposed to <b> (bold) and <i> (italic) unless the bold or italic is required without any semantic context (for example in a product name).
Examples
Remember you must check this box
<p>Remember <strong>you must</strong> check this box.</p>You should really try to validate your pages
<p>You should <em>really</em> try to validate your pages</p>Read more about Splashdown!™ below
<p>Read more about <b>Splash<i>down</i>!™</b> below</p>Succinct and, in my opinion, pretty hard to argue with.
HTML5 has it sussed
I won’t be using HTML5 for a long while yet, but that’s another story altogether…
Ideally I’d like to retrofit the HTML5 specification’s definitions of each for use right now in XHTML, however I’m not sure I’d be comfortable going ahead with doing such a thing, coding to one spec whilst picking my favourite bits of another.
The <b> element in HTML5
“The b element represents a span of text to be stylistically offset from the normal prose without conveying any extra importance, such as key words in a document abstract, product names in a review, or other spans of text whose typical typographic presentation is boldened.”
The <i> element in HTML5
“The i element represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, a ship name, or some other prose whose typical typographic presentation is italicized.”
A go-between in the meantime?
There will always be the argument that instead of using b and i you could or should use something like <span class="italics"> or <span class="bold"> so as to avoid using insemantic elements, however a class name like that is more insemantic than an in-spec HTML element. Not to mention the fact that a span with a class applied is far more cumbersome than a ‘pre-made’ piece of HTML.
The resolve?
So which is worse?
- Using
ito mark up emphasised text - Using
emto mark up italicised and non-emphasised text - Using
ito mark up purely italicised text - Using
<span class="italics">to mark up italicised text
Special thanks to the following for help with this article: @smashingmag, @pekingspring, @stevefaulkner, @simonwiffen and all my Twitter followers.
I think that the fact that b and i are still in the spec, are valid (even in strict) and are being carried over to HTML5 (albeit slightly redefined) indicates that there is still a very real place for them in web development right now. The frequency with which they’ll be used is slim at best, but they should not be ruled out, and at the very least not misunderstood. I’m not going to make the leap myself just yet, but they are there, they are usable, and one day I might just use them.
What are you going to do?
+
Tuesday, January 26th, 2010 in Web Development.
Jim Moran said on 27 January, 2010 at 8:21 am
Nice article Harry.
I can think of one real instance where this would have been useful to me in the past; engage Mutual Assurance (which does look a little awkward with the initial caps on M and A) always have engage in bold lowercase as part of their brand, regardless of its position in a title or sentence, therefore ignoring the convention to capitalise the first letter of a sentence.
The <b> tag seems ideal here, but how would you suggest the lowercase “e” is handled?
- CSS text transform
- leave it as it is? (e.g. a sentence beginning with the chemistry term “pH” would not be capitalised)
Cheers.
Harry Roberts said on 27 January, 2010 at 9:03 am
Hi Jim,
I agree on the use of the
bthere. Just as Simon said, too.For the ‘e’, I’d type it lowercase as it’s technically content. You’d always want that ‘e’ to be lowercase no matter what stylesheets (if any) you threw at it.
H
Brad Czerniak said on 27 January, 2010 at 4:27 pm
Thought-provoking article, Harry.
To me, semantic HTML means that the markup indicates what something is rather than what it looks like. Using <b> and <i> sort of indicates what something isn’t if I understand your contention here. Plus, these tags have strong presentational connotation (for instance, user agent stylesheets).
My understanding of <span> is that it is specifically a semantically-meaningless inline element. That’s why it makes more sense to me to use a classed span for purely-presentational bolding or italicizing.
Altogether, it’s a huge edge case that adds complexity to the HTML spec. In practical terms, since screen readers don’t place any specific emphasis on strong or emphasized text, it makes sense to just use strong and em, even if it’s not semantically-defensible. Chances are those marked-up words have some SEO value anyway.
I’d say using <i> to mark up emphasized text is the worst of the four cases mentioned above.
Thanks!
LeRenard said on 27 January, 2010 at 4:57 pm
IMHO, <i> and <b> tags could be only used if you’re sure you will never ever (never say never) need to change style to those elements.
For example, imagine there were no <cite> element, if you had set a <i> tag instead. Then you wanted to change the style of authors in your pages, you could simply change your css instead of going through all of your <i> tags.
In the end, your text is not just italicised text, it’s often more than that semantically (even if there’s no special tag for it)
Reusability is a main advantage for css, use it !
LeRenard said on 27 January, 2010 at 5:00 pm
Sorry I didn’t escape tags, can you correct it please (and maybe set a warning about your comment box allowing HTML ;) ) ?
Bryan said on 27 January, 2010 at 10:08 pm
I run a website that posts monthly journal entries of several people. One of them likes to format his in what he calls the “comic strip fashion.” Basically this means that the first time a new person or place is mentioned in his journal, he wants it bold. For me this is the perfect use of the b tag.
Bryan said on 27 January, 2010 at 10:09 pm
Make that the bold tag. I don’t know what escaping to use in this box.
Jon said on 27 January, 2010 at 11:39 pm
Really good article and I think it highlights a problem where a lot of developers are just blindly following some guide that they read on a website that said ‘<b> and <i> tags are bad’ or ‘don’t use tables use div tags instead’, without really understanding the reasons why. This leads to common misuse/overuse of those tags (I’ve seen so many websites where tabular data has been laid out with div tags) which, to me, is just as bad as the problem they were trying to get away from in the first place.
Having said that, I’m still not a fan of using <b> and <i>, having markup that denotes nothing but style just doesn’t feel quite right to me, after all markup is just supposed to be about semantics. Personally I’d much rather see than <b> to boldify a company’s name for branding requirements. At some point in the future the company’s branding may change and they might drop the boldifying (err..??) requirement, if you used <b> you’re either going to have to replace all instances of <b> around the company name within your markup OR be a bit rubbish and style all of your <b>’s as font-weight: normal, not very nice at all.
jose said on 28 January, 2010 at 6:34 am
Interesting article.Tags like b, i, pre, small, sub, sup, tt, big are elements grouped in xhtml presentational module.They are valid, non-deprecated, with lack of semantics, affecting only the visual part of the web.There is just one issue that contradicts the use of them.It’s about separating structure, style and behaviour….and all of theese tags can be replaced with a css property. Then why does theese tags still exist in xhtml specs?????Anyway i tend to use b and i instead of span element for rounded corners because they are shorter than span(just 1 letter) and sometimes I use big for tagging prices with big font-size.They don’t have semantics so I could use them for anything I want(but not as replacement for semantic tags)…..Using a span with a class for every each of the cases increases code and load time, but it’s more correct, because we leave style out of structure.So we have to choose:less code, faster load, structure mixed with presentation or more code, slower load(depends of the number of uses), correct separation of structure and style….
jose said on 28 January, 2010 at 6:45 am
I would like to make a correction:
“Using a span with a class for every each of the cases increases code and load time”
should be : “increases code and decreases load time”
The big tag though doesn’t have semantic meaning, but th word itself reflects the state of the element for me…there is no conclusion. Presentational tags are not recomended in favor of css.
CSS Brigit | A reconsideration—in defence of bold and italice said on 28 January, 2010 at 1:57 pm
A reconsideration—in defence of bold and italice…
A post covering the availability and usability of the demonised HTML elements b and i.
…
Jim O'Donnell said on 28 January, 2010 at 4:27 pm
Ships’ names and latin words, such as the names of species, might also be good examples of text which is commonly italicised, but the italics don’t denote emphasis. There’s no specific tag for those in HTML (<cite> maybe?) which leaves <i> or <span>
The B and I buttons on some WYSIWYG editors insert strong and em tags into HTML. In that case, strong and em don’t indicate text emphasis – they’ve replaced b & i for people who want a semantically neutral equivalent to the terms ‘bold’ and ‘italic’.
Diptanshu said on 29 January, 2010 at 9:23 am
Tonal aspects aside, ‘b’ and ‘i’ tags offer the same kind of presentation. Why have …class=’bold’ etc when the simple b can also be stylized?
IMO, strong and em tags are not necessary. Doesn’t make a difference when we have to read the text anyway; it will have the emphasis anyway.
John Faulds said on 3 February, 2010 at 11:10 am
Just to expand on this, and on the point made earlier about using cite for titles: you can mention a title without necessarily citing it, e.g. I’ve just finished reading The Great Gatsby. In my opinion, as with ships’ names and latin names, <i> is the appropriate tag to use in this situation, and it’s one I’ve used in the past (except as Jim points out when a CMS WYSIWYG editor will for insert <em> for <i>).
I’ve never quite found a use for <b> though as I can’t think where you would want something to be bold but not emphasised (I don’t really agree with the examples that the HTML5 spec puts forward).
Andrew Johns said on 19 April, 2010 at 10:29 am
My take on it, coming from a CSS + Accessibility + General Semantics and Standards view, regardless of CURRENT level of screenreaders to accurately represent the difference – is that if we’re saying that some text should be made bold or italic purely for presentational reasons, then the Level A requirement in WCAG 2.0, “1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. ” dictates that the i and b tags should be dropped in favour of using css, regardless of the extra amount of code that might be required to produce the same effect, because that’s what is required to be “valid” by recommended practices. After all, how often would this be an issue? In most cases the requirement for styling will come from the need for emphasis.
However, the problem with this view is whether you consider i and b to be a presentational effect or whether it is conveying information that is different to emphasis (em or strong). if it’s conveying any form of information then it becomes semantic rather than presentation, and is therefore acceptable.
The argument that it is widely used and so should be kept in is rubbish, because fonts were widely used and they’ve been deprecated, as is the U tag, etc. It’s a bit of dilemma really.