{"id":140,"date":"2007-05-07T08:19:09","date_gmt":"2007-05-07T08:19:09","guid":{"rendered":"http:\/\/lachy.id.au\/log\/2007\/05\/b-and-i"},"modified":"2013-09-07T16:42:54","modified_gmt":"2013-09-07T16:42:54","slug":"b-and-i","status":"publish","type":"post","link":"https:\/\/lachy.id.au\/log\/2007\/05\/b-and-i","title":{"rendered":"The <b> and <i> Elements"},"content":{"rendered":"

Over on public-html<\/a> (and cross posted to www-html<\/a>), there is some intense
\n\tbikeshedding<\/a> going on pertaining to the
\n\tuse of the b<\/code> and i<\/code> elements
\n\tand why they should or should not be retained in HTML 5. Some have argued
\n\tthat b<\/code> and i<\/code> are
\n\tstrictly presentational elements<\/a>, and that they should not<\/em> be retained
\n\tin HTML5.<\/p>\n

Others have argued that the b<\/code> and i<\/code> elements are
\n\tvirtually synonymous with strong<\/code> and em<\/code> in reality<\/a>, so trying
\n\tto define otherwise is pointless. The reason that i<\/code> and b<\/code> could
\n\tbe considered synonymous with em<\/code> and strong<\/code>, respectively,
\n\thas to do with them being used largely interchangeably with each other in
\n\treality, and very little to do with their actual definitions.<\/p>\n

However, it’s reasonable to hypothesise that there would be significantly
\n\tmore non-emphasis-usage of i<\/code> than there would be usage for emphasis,
\n\tand so defining that all uses of i<\/code> represent emphasis would be
\n\ta mistake (similarly for b<\/code> and strong<\/code>).<\/p>\n

Therefore, the pragmatic approach is to specify that i<\/code> and b<\/code> convey
\n\tunspecified semantics, which are to be determined by the reader in the context
\n\tof their use. In other words, although they don’t convey specific semantics
\n\tby themselves, they indicate that that the content is somehow distinct from
\n\tits surroundings and leaves the interpretation of the semantics up to the
\n\treader.<\/p>\n

That is effectively the approach taken by the HTML5 spec. These are the current
\n\tdefinitions for the b<\/code> and i<\/code> elements.<\/p>\n

The b<\/code> element<\/a>:<\/p>\n

\n

The b<\/code> element represents a span of text to be stylistically
\n\t\toffset from the normal prose without conveying any extra importance, such as
\n\t\tkey words in a document abstract, product names in a review, or other spans
\n\t\tof text whose typical typographic presentation is boldened.<\/p>\n

The b<\/code> element should be used as a last resort when no other
\n\t\telement is more appropriate. In particular, headers should use the h1<\/code> to h6<\/code>\t\telements, stress emphasis should use the em<\/code> element, importance should be denoted
\n\t\twith the strong<\/code> element, and text marked or highlighted should use the m<\/code> element.<\/p>\n<\/blockquote>\n

The i<\/code> element<\/a>:<\/p>\n

\n

The i<\/code> element represents a span of text in an alternate voice
\n\t\tor mood, or otherwise offset from the normal prose, such as a taxonomic designation,
\n\t\ta technical term, an idiomatic phrase from another language, a thought, a ship
\n\t\tname, or some other prose whose typical typographic presentation is italicized.<\/p>\n

Terms in languages different from the main text should be annotated with
\n\t\tlang<\/code> attributes (xml:lang<\/code> in XML). <\/p>\n

The i<\/code> element should be used as a last resort when no other
\n\t\telement is more appropriate. In particular, citations should use the cite<\/code> element,
\n\t\tdefining instances of terms should use the dfn<\/code> element, stress emphasis should
\n\t\tuse the em<\/code> element, importance should be denoted with the strong<\/code> element, quotes
\n\t\tshould be marked up with the q<\/code> element, and small print should use the small<\/code>\t\telement.<\/p>\n<\/blockquote>\n

Context is effectively how users distinguish between italics used for emphasis
\n\tand the variety of other uses, so providing a couple of catch-all elements for
\n\tthe remaining cases that don’t have specific elements, isn\u2019t all that bad.<\/p>\n

The separation of presentation and semantics isn’t a goal in and of itself
\n\tthat needs to be strictly adhered to. Rather, it’s just a means to an end and
\n\tif that end can be reached without a strict separation, then so be it.<\/p>\n","protected":false},"excerpt":{"rendered":"

Over on public-html (and cross posted to www-html), there is some intense bikeshedding going on pertaining to the use of the b and i elements and why they should or should not be retained in HTML5.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[2,7,3,6,21],"tags":[],"_links":{"self":[{"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/posts\/140"}],"collection":[{"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/comments?post=140"}],"version-history":[{"count":4,"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/posts\/140\/revisions"}],"predecessor-version":[{"id":247,"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/posts\/140\/revisions\/247"}],"wp:attachment":[{"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/media?parent=140"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/categories?post=140"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/tags?post=140"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}