Should I use <b> and <i> elements?
The HTML5 specification redefines b and i elements to have some semantic function, rather than being purely presentational. However, the simple fact that the tag names are 'b' for bold and 'i' for italic means that people are likely to continue using them as a quick presentational fix.
This article explains why that can be problematic for localization (and indeed for restyling of pages in a single language), and echoes the advice in the specification intended to address those issues.
You should always bear in mind that the content of a b element may not always be bold, and that of an i element may not always be italic. The actual style is dependent on the CSS style definitions. You should also bear in mind that bold and italic may not be the preferred style for content in certain languages.
You should not use b and i tags if there is a more descriptive and relevant tag available. If you do use them, it is usually better to add class attributes that describe the intended meaning of the markup, so that you can distinguish one use from another.
The rest of this article will explain this in more detail.
The HTML5 specification redefines the intended use of these elements as follows.
Theielement represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose in a manner indicating a different quality of text, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, transliteration, a thought, or a ship name in Western texts.
Thebelement represents a span of text to which attention is being drawn for utilitarian purposes without conveying any extra importance and with no implication of an alternate voice or mood, such as key words in a document abstract, product names in a review, actionable words in interactive text-driven software, or an article lede.
You need to bear in mind that misuse of these tags can make localization of content difficult.
A general issue. Using b and i tags can be problematic because it keeps authors thinking in presentational terms, rather than helping them move to properly semantic markup. At the very least, it blurs the ideas. To an author in a hurry, it is tempting to just use one of these tags in the text to make it look different, rather than to stop and think about things like portability and future-proofing.
Internationalization problems can arise because presentation may need to differ from one culture to another, particularly with respect to things like bold and italic styling.
Japanese example. An English document may use italicization for emphasis, document titles and idiomatic phrases in a foreign language, but a Japanese translation of the document may not use a single presentational convention for all three types of content. Japanese authors may want to avoid both italicization and bolding, since their characters are too complicated to look good in small sizes with these effects.
The Japanese localizer can certainly apply different styling to b and i elements by changing the CSS style sheet. However, the Japanese person may find that the content communicates better if they use wakiten (boten marks) for emphasis, corner brackets for 『document names』, and double angle brackets for 《foreign language idioms》. These are common Japanese typographic approaches that are not used in English.
The problem is that, if the English author has used i tags everywhere (thinking about the presentational rendering he/she wants in English), the Japanese localizer will be unable to easily apply different styling to the different types of text.
The problem could be avoided if semantic markup is used. If the English author had used <em>..</em> and <cite>...</cite> and <i class="foreignphrase">..</i> to distinguish the three cases, it would allow the localizer to easily change the CSS to achieve different effects for these items, one at a time.
Of course the author could also have used span elements instead of the i or b. The difference would be that there would be no fallback to italics or bold in the absence of style rules.
The monolingual angle. Of course, over time, this is equally relevant to pages that are monolingual. Suppose you want to change your new corporate publishing guidelines because you feel that document names look better when bold rather than italic. With semantically marked up HTML, you can easily change the styling of just the document names throughout a whole site with one tiny edit to the CSS. If, however, you had used i without distinguishing the different semantics, you’d have to hunt through every page for relevant i tags and change them individually, so that you didn’t apply the same style change to emphasis and foreign words too.
Using language attributes. If you adopt the convention to apply italicization to foreign words or phrases in your content it may seem sufficient to rely on the presence of a language attribute to identify what needs styling, for example <i lang="fr">..</i>.
Actually you should think carefully before using this approach, since the language attribute only describes the language of the text, not the semantics. It is possible that in the future you will want to style text in another language differently according to the context in which it is used.
Therefore, it is usually safer to also use class attributes to describe the semantics, and not overload the language attribute, eg.
<p>There is a certain <i class="foreignphrase" lang="fr">je ne sais quoi</i> in the air.</p>.
The HTML5 specification has the following recommendations with regards to the use of the i element (highlighting added):
Authors can use theclassattribute on theielement to identify why the element is being used, so that if the style of a particular use (e.g. dream sequences as opposed to taxonomic terms) is to be changed at a later date, the author doesn't have to go through the entire document (or series of related documents) annotating each use.
Authors are encouraged to consider whether other elements might be more applicable than theielement, for instance theemelement for marking up stress emphasis, or thedfnelement to mark up the defining instance of a term.
Similar wording appears in the description of the b element, including the sentence: The
b element should be used as a last resort when no other element is more appropriate.
In the HTML5 specification 4.5 Text-level semantics lists other elements that can be used to describe inline text semantically, such as dfn, cite, var, samp, kbd, etc.
It may help to think of b or i elements as essentially a span element with an automatic fallback styling. Just like a span element, these elements usually benefit from class names if they are to be useful.
Related links, Authoring HTML & CSS