Matthew Thomas wrote a long piece on the
<i> elements in HTML. It’s called When semantic markup goes bad. (Coming soon on Fox, after an all-new Who Wants to Marry a Standardista!) Dave Shea linked to it on the Web Standards Project site, and opined, “What’s clear from Matthew’s analysis is that simply steamrolling ahead with global use of
<strong> is the wrong approach.”
Me, I don’t get it.
<i> should not exist. They should not be used. They have no value.
Thomas points out that semantic elements exist “for some of the things you might want presented in bold or italics.” This is not the right way for a semantic HTML coder to look at things, because it puts the presentational cart in front of the semantic horse. HTML provides style guidance for its semantic elements. The
<h1> element is not designed to bold things, but that is its default presentation. The same goes for
<th>. If you don’t like them bolded, then you change them using CSS.
In the case of text in other languages, which Thomas suggests has no semantic representation in HTML, well, that’s wrong. Attributes convey semantics, too:
<span lang="fr">je ne sais quoi</span>
The entire point of designing with semantics is that the elements you use convey semantic value. The
<i> elements convey no semantics. They are purely presentational elements. (Which is why they’re missing from XHTML 2.) And if you’re just going to style things, you should do it in CSS. If you’re using
<i> to cover for real or perceived weaknesses in the expressiveness of HTML, quite simply, you’re doing it wrong. I think Thomas (and of course Dave Shea) get this — Thomas mentions using a style sheet to define
<dfn> — but that’s an approach that should be extended to his entire thesis.
So, here are my rules for
- When intending to convey emphasis, use
- When intending to change only visual style, use either
font-style: italicin CSS.
- When indicating changes in language, use the lang attribute, and style that in CSS if necessary.
- Do not use
(Yes, I used
<em> there. Heh.)