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?
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, 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
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:
So, in short, i and b were deprecated because they were HTML tags concerned about presentation, which is totally wrong.
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:
i to mark up taxonomic designations: "I like R. norvegicus."i to mark up a phrase in a different language compared to the surrounding text: À la cartei 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.:
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):
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).
<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.
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.
Commented
Sep 7, 2014 at 15:04
<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.
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.
Commented
Jul 31, 2016 at 16:51
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.
<span class="keyword">...</span> in the first place saves you a lot of trouble.
Commented
Sep 5, 2014 at 9:21
<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>.
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.
<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 ;-)
Commented
Sep 4, 2014 at 20:10
<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>?
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.
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.
<b> and <i> however it sees fit, too.
Commented
Sep 5, 2014 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...
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.
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!
Commented
Sep 4, 2014 at 20:50
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.
Commented
Sep 4, 2014 at 21:05
<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">.
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.
<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.
<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...
<i> tags would seem like it would be useful in some cases, and nearly always harmless in any event. Humans may pronounce things like titles the same as the surrounding text in cases where it would not cause ambiguity, but would generally alter the pronunciation or prosody when necessary to prevent confusion. Since a text-to-speech utility won't know what will or won't be confusing, having it always adjust...
The bold and italic tags are purely decorative, when we moved towards HTML5 there was a great emphasis on semantically meaningful tags. That is to say tags that are not purely decorative, but give meaning to the web-page, meaning that the google-bot can, for instance, parse and understand.
The discipline of semantics is very important in HTML, but unlike the regular philosophical inquiry of semantics, HTML is concerned with the semantics of which a computer understands.
<b>and<i>aren't deprecated.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 dobori, you usually meantstrongorem.<i>and<b>aren't actually deprecated,<tt>and<u>are, and the question would be just as applicable to those.