This question came up in one of my college classes. The professor only gave the answer that it was more descriptive, but it seems as though <b> and <i> are rather explicit in their meaning and is easier to type than <strong> and <em>.

What were the official arguments for the deprecation of these tags?

  • 36
    I'm fairly sure <b> and <i> aren't deprecated. – Doval Sep 4 '14 at 14:37
  • 12
    Related reading: What's the difference between <b> and <strong>, <i> and <em>? along with <strong> vs <em>? – user40980 Sep 4 '14 at 15:10
  • 3
    I tend to reason about it like this: Do I want a screen reader to read this differently, or not? If I just want to pick out words to be easy to find by a (non-blind) reader, I might use b - it literally means "this is bold", not "this is emphasized". But the main point is, they're different in meaning - there's no deprecation, just a not that when you used to do b or i, you usually meant strong or em. – Luaan Sep 5 '14 at 11:24
  • 1
    @MichaelT I remember when I first began using LaTeX, I was confused about all the different ways text could be italicized and bolded on when beginning on a blank document (with no style packages). – Cole Johnson Sep 5 '14 at 16:35
  • @Luaan: Even if <i> and <b> aren't actually deprecated, <tt> and <u> are, and the question would be just as applicable to those. – supercat Sep 8 '14 at 18:07
up vote 126 down vote accepted

Last summer, I read the complete HTML5 specification, and every previous HTML specification (even the abandoned ones), and all CSS specs I could find, and a lot of XML specs. Since I love semantically rich hypertext documents, let me give you the idea behind the relevant HTML semantics in HTML5.

Before HTML5

Before HTML5, i and b were indeed out of fashion. The reason was that they essentially worked like em and strong, respectively, but with focus on presentation and not on semantics (which is bad).

Indeed, i meant that the text should be in italics (it said something about how the text should be rendered on-screen). On the other hand, em meant that the text was to be emphasised (it said something about the semantics of the text).

There is an important theoretical difference here. If you use em, the user agent (=browser) knows the text should be emphasised, so it can render it in italics if the document is displayed on-screen (or all-caps if formatting is not possible, or maybe even in boldface is the user prefers that), it can pronounce it differently if the document is spoken to the user, etc.

Notice that emphasis really is about semantics. For instance, the phrases

  • The cat is mine. (=not the dog!)
  • The cat is mine. (=not yours!)

do not have the same meaning.

The same difference applies to b (boldface font) and strong (strong emphasis).

A general principle of digital writing in general, and of hypertext authoring in particular, is that you should separate content and style. In hypertext authoring, this means that the content should be in the HTML file, and the style should be in a CSS file (or a number of CSS files). A different but related principle is that the document should be rich in semantics (like marking up headers, footers, lists, emphases, addresses, navigational areas, etc.). This has a number of advantages:

  • It is much easier for computer programs to interpret the document. These programs include browsers, text-to-speech applications, search engines, and digital assistants. (For example, the browser can let you save an address to your address book, if only it can find and interpret it. Also, you might know that Microsoft Word can create and automatically update a TOC for you if you mark up your headings correctly.)
  • It is much easier to change the style later on. (If you want to change the colour of all your third-level headings in your 860-page document, you can change a single line in the stylesheet. If you had mixed content and presentation, you would have to go through the entire document manually. And you would probably miss a heading or two, making the document look unprofessional.)
  • You can use different stylesheets depending on the circumstance (is the document being displayed on-screen or printed on paper?). You can even let the end user choose the style herself. (My website offers a number of alternate stylesheets. In IE and FF, you change these using the View menu.)

So, in short, i and b were deprecated because they were HTML tags concerned about presentation, which is totally wrong.

In HTML5

In HTML5 i and b are no longer deprecated. Instead, they are given sematic meaning. So they are now actually about semantics, and not about presentation.

As before, you use em to mark up emphasis: "The cat is mine." But you use i for almost all other cases where you would use italics in a printed work. For instance:

  • You use i to mark up taxonomic designations: "I like R. norvegicus."
  • You use i to mark up a phrase in a different language compared to the surrounding text: À la carte
  • You use i to mark up a word when you talk about the word itself: "drink is both a noun and a verb"

It is also a good idea to use the class attribute to specify the precise usage (also Google "microformat" and "microdata"). And, of course, in the second case, you should really use the lang attribute to specify the correct language. (Otherwise, for instance, a text-to-speech agent might mispronounce the text.)

A year ago or so, the HTML5 specification also said that cite should be used to mark up names of books, films, operas, paintings, etc.:

  • What do you think of Nymphomaniac?

Finally, since long ago, dfn is used to mark up the defining instance of a phrase in a text (like a mathematical definition, or the definition of a term):

  • A group is a set X equipped with a single binary operation * such that...

So the italics in your printed book, which can mean a lot of different things, is represented by four different HTML5 tags, which is really great, because semantics is good, as I tried to convince you about earlier. (For instance, you can ask your browser to make a list of all definitions in the text, so you can make sure you know them all before the exam.)

Turning to strong and b, the HTML5 specification says that strong should be used to mark up an important part of the text, like a warning or some very important-to-catch word in a sentence. On the other hand, b should be used to mark up things that need to be easy to find in the text, like keywords. I also use b as headings in list items (LIs).

  • 1
    Correction: the definition tag is <dfn>, not <def>. Otherwise, great comprehensive summary of all the issues. Your suggestion to use <b> as headings in list items is interesting; the semantic approach is to use a definition list, but since no browsers currently support display:run-in, inline keyword markup with <b> or <span> are the best you can do. – AmeliaBR Sep 7 '14 at 14:46
  • @AmeliaBR. Thank you for observing the typo (def). About the definition lists: definition lists should be used for name-value pairs, and I always use them for this (have a look at my guestbook, for instance). I also loved display:run-in, but since its support is decreasing, you have to use the float or the content: trick, see rejbrand.se/rejbrand/news.asp?ItemIndex=169. When I talk about using b to mark up 'headings' in lists, I do not mean name-value pairs, but rather simple lists where I want to use a 'header' in each item. – Andreas Rejbrand Sep 7 '14 at 15:04
  • 1
    @SarahofGaia There are at least two flaws with reasoning that <b> guarantees emboldened text. 1) Screen readers, braille displays, and other means of consuming text for which thicker glyphs is a meaningless concept. 2) b { font-weight: normal }, meaning the display style isn't fixed for <b> either. – 8bittree Jul 29 '16 at 13:44
  • 1
    Finally, you are always free to supply your own CSS if you don't trust the browser: b, strong { font-weight:bold; }. That way you can be as sure as you could possibly be. CSS is the way to specify the visual format. HTML is about the meaning (content), CSS about the visual presentation of it. – Andreas Rejbrand Jul 31 '16 at 16:51
  • 1
    This answer gave me the understanding why I need to change my font tags to css. I have always liked font tags bold and all that, now I understand why I shouldn't use them. Thank you – Andreas May 31 '17 at 21:09

As Doval says, they are not deprecated. They still exist but should be used differently from what many people where used to before HTML5.

It's about 'semantic' html. It should describe 'what' it is, instead of how it should look. The browser or theoretically any other display medium (say a reading app for the blind) should be able to decide how exactly should be interpreted.

This is similar why you should not use CSS class names like "red" and use more descriptive classes that describe the functional idea behind using a different color here. You may later decide that green is better (and maybe anything "strong" should be shown by using red color instead of bold text). Or a color blind user may have some special browser settings where colors are replaced by other means.

  • 1
    Are there any situations in which it is preferrable to use <b> as opposed to <strong>? Or is <strong> always a "more semantic" tag? – LanceLafontaine Sep 4 '14 at 14:48
  • 4
    Roughly you could use <b> for things that should be "highlighted" but not "emphasized", like keywords in a text. In technical documentation you find often different text styles used to show certain attributes, like in programming books code samples or technical terms. For such use cases like a technical term <b> or <i> could be used. – thorsten müller Sep 4 '14 at 14:56
  • 3
    @LanceLafontaine Take a look at the official standard. – Rufflewind Sep 4 '14 at 15:56
  • 4
    @thorstenmüller I think that's a bad example too... it is the textbook case where management decides later that instead of bold they want their attributes in type-writer font and not bold but underlined, in which case using <span class="keyword">...</span> in the first place saves you a lot of trouble. – CompuChip Sep 5 '14 at 9:21
  • 2
    @LanceLafontaine <b> is an edge case, but there are solid examples for using <i> for cases where <em> is inappropriate: scientific names of species or latin words adopted into English (you could use a span with a language attribute, but that has all sorts of other implications -- a screen reader might switch voices for a different language). It can also be used for italicizing titles of other works, although the semantically correct approach is to use <cite>. – AmeliaBR Sep 5 '14 at 15:02

The true story is that b and i were first obsoleted, deprecated, cursed, and anatematized as “presentational” in various HTML5 drafts (broadly speaking), but then they realized that these tags are widely used and also generated by many authoring programs. Instead of simply allowing them, they developed contrived new “semantic” definitions for them, to be able to allow the elements but still pretend to be strict about “presentational” markup. The new definitions have varied from one draft to another and are obscure: you can hardly find two people who understand and interpret them the same way.

Sorry, no references. The description above is a result of following the changes and reading the drafts and discussions, often between the lines. They are not explicitly telling the cause. I still think it’s the true story.

The conclusion is: Move on. There’s nothing useful here. The b and i elements do the same thing as they always have: they make the font bold or italic, respectively, with the usual caveats. This is the reality that you should take into account, not the quasischolastic “semantics” that has no impact on browsers, search engines, or other software.

  • 3
    That said, you can follow the quasischolastic semantics just by treating <b> as a funny kind of <span> that by default renders in bold. Then if you can be bothered, give your uses of it a class attribute too so that when necessary you can restyle multiple things at once that used it because they have common semantics. It's quasischolastic in the sense that people will think you're quasi in the head for doing b.productname {font-weight: normal; font-style: italic; } after you changed your mind about presentation and took advantage of your wise choice of semantic markup ;-) – Steve Jessop Sep 4 '14 at 20:10
  • 1
    @SteveJessop: For those few of us in the world who still care about file size, saying <b>this</b> seems much more reasonable than <span class="bold">this</b> (the eight-byte overhead of the former is irksome enough; the 23-byte overhead of the latter seems crazy). I wonder why HTML never defined any short-form representation like <@quack>this</@> as equivalent to <span class="quack">this</span>? – supercat Sep 4 '14 at 20:29
  • 4
    @supercat: that's what transfer-encoding: gzip is for. Or maybe XML+XSLT, depending exactly where and how you want to introduce a more concise notation for "quack". – Steve Jessop Sep 4 '14 at 20:53
  • 7
    @supercat class='bold'? Master Suku of The Codeless Code would have words with you about the use of such poor classnames. Consider this your last boldRedText. – user69037 Sep 4 '14 at 23:33
  • 2
    In the days of 14.4 modems, CSS was an idea not yet realized or implemented in any user agent. These HTML elements are merely ancient legacy cruft we'll be stuck with forever. – Michael Hampton Sep 5 '14 at 11:04

The <b> and <i> tags originated with the concepts of "bold" and "italic". The problem is these may be completely meaningless for some user agents. For instance, what does "italic" sound like in a screen reader for a blind person?

Replacing them with <strong> and <em> removed the direct link to typographical concepts. Instead, the user agent can render them however it sees fit.

  • 2
    Strictly speaking, the user agent can render <b> and <i> however it sees fit, too. – Jonathan Eunice Sep 5 '14 at 13:51

The <b> and <i> tags are essential when you literally require text in 'bold' or 'italic'.

If you're writing an equation in HTML where an italicised 'I ' has a different meaning from a non-italicised 'I' it's important to be able to make that distinction.

I think of them in the same way I think of <sup> or <sub> tags - you can't correctly represent the meaning of an equation without using such 'appearance' tags.

The purist approach would be to use MathML or TeX but browser support isn't there yet...

  • 14
    I wish the people pushing for "semantic" markup would recognize that in some cases the old tags were more semantically correct than any alternatives. If the text of a document makes reference to certain underlined words, then showing those words in any fashion other than by underlining them would be semantically wrong. If one is importing text from a system which puts some of it in a monospaced typeface but which makes no distinction as to why, then using one of the "replacements" for <tt> would falsely imply that the code doing the import knew more than it did about the purpose. – supercat Sep 4 '14 at 20:24
  • I agree with the suitability of b and i in mathematical (and physical) contexts, but such usage is not mentioned in HTML5 drafts. When I raised this question, it was seriously responded that the Unicode special characters (mathematical bold letters and mathematical italic letters) be used instead! – Jukka K. Korpela Sep 4 '14 at 20:50
  • 1
    @supercat: the general claim (which I admit is not always applicable) is that you shouldn't write cheques that the user-agent can't cash. In particular you shouldn't write a page that claims somebody's screen-reader will speak in a monospaced font (I imagine a robot-voice would be appropriate: I've never actually used a screen reader). Of course this ignores that most people's pages don't work on screen-readers in the least, and so there's no point them paying any price for a hypothetical accessibility they don't care about. But W3C deliberately neglects that fact as a matter of principle. – Steve Jessop Sep 4 '14 at 21:01
  • In the case of the code import, I suppose the canonical (if unsatisfactory) answer is class="source-X-asserts-it-should-be-monospace", thus distinguishing it from text that is semantically different in the sense that some other source asserts for unknown reasons that it should be monospace. In effect this is auditing the stuff that HTML considers bad, instead of merely translating the badness into the HTML. – Steve Jessop Sep 4 '14 at 21:05
  • 1
    @SteveJessop: In other words, we should improve <TT>, which directly suggested that text should be set in a contrasting monospace font, with markup which, after a few layers of indirection, will indicate that text should be shown in some particular font which happens to be monospace. While I would not expect all screen readers to do something useful with <tt>, I would expect they'd have a much easier time with <tt> than <span class="styleNameThisImportUtilityPicked">. – supercat Sep 4 '14 at 21:13

The design principles underlying the HTML tags is that they should be "semantic" i.e. they should indicate meaning and intent rather than low level instruction.

The classic test is "can the tags be meaningfully used in a browser for the blind".

So for an audio based browser the "i" for italic is pretty useless as you cannot have italic speech. However the "em" tag is meaningful as an audio device can emphasize a phrase in many ways: by raising pitch, increasing volume or changing accent. A Braille renderer could emphasize by raising the dots changing spacing, changing size or adding vibration.

  • As you say you can't have italic speech - but you can have italic text where the fact it is italic has semantic meaning, eg equations... – SAL Sep 5 '14 at 9:14
  • 2
    'So for an audio based browser the "i" for italic is pretty useless as you cannot have italic speech.' ... Yes, and so is <img> because you can't speak an image, and a system without sound hardware can't present <audio>. Sometimes presentation is the very purpose of an element, and it doesn't need to be universally supported (and unlike other potentially unsupported elements, <i> doesn't need alt text because the fact that it's italic is the only information lost). The real problem is when people say i when they mean em. – nmclean Sep 5 '14 at 12:53
  • @SAL: Why can't one have "italic speech"? If normal speech is spoken with a "pitch" value of 100, having text within an <i> tag use pitch of 120 and text within a <b> tag use 80, and having text within a <tt> synchronize the speech with a synthesized typewriter producing the text would allow the listener to readily distinguish those forms of markup. The job would be much harder if instead of using an <i> tag the text instead used a <span class="whatever"> which caused parts of the text to be shown using "Acme SemiScript" rather than "Waldorf Sans" [some font families... – supercat Sep 5 '14 at 16:25
  • ...don't have a good italic font, but sometimes an italic-only font may look good when set within text written using another font family]. – supercat Sep 5 '14 at 16:28
  • @supercat You're describing emphasized speech, not italic speech. If you want a different tone then you should use em, like nmclean said. If you want it italicized, use i. It doesn't matter that a screen reader doesn't know what to do, because there's nothing for it to do. Book titles are often italicized, but you don't pronounce them any differently. – DCShannon Sep 5 '14 at 23:05

protected by gnat May 24 '17 at 0:30

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.