HTML and CSS Reference
In-Depth Information
This is what the markup for the following screenshot looks like:
<img src="scenery.jpg" alt="Picture of the Irish south coast">
<figcaption>Looking out into the Atlantic Ocean
from south west Ireland</figcaption>
Note that <figure> doesn't have to contain
an <img> element. It might instead contain
an SVG drawing or a <canvas> element, or
even ASCII art in a <pre> element. What-
ever type of graphic it contains, the <figure>
element links the graphic to the caption.
Emphasizing words and phrases
The <b> and <i> elements have a long history in HTML . They were
listed, along with the <em> and <strong> elements, in the character-high-
lighting section of the 1993 IETF draft proposal for HTML . The <b> and
<i> elements are listed in the subsection “Physical Styles” (along with
<tt> )—that is, their purpose was entirely presentational. Meanwhile,
<em> and <strong> (along with several others) are in the subsection
“Logical Styles”—elements with semantic meaning. This early distinc-
tion highlights the problem <b> and <i> would later run into.
You saw at the start of this chapter that separation of concerns is the
Holy Grail of web authoring— HTML for content, CSS for presenta-
tion, and JavaScript for behavior. Because <b> and <i> are entirely pre-
sentational, their use has long been frowned on, and there have been
several serious proposals to remove them from HTML . Meanwhile,
<strong> and <em> have always had a semantic definition while appear-
ing identical to <b> and <i> , respectively, in most browsers.
Ever pragmatic, the HTML5 spec recognizes that, with millions of pages of
legacy content out there, browsers aren't going to be dropping support
for <b> and <i> any time soon. On the other hand, blindly using <em> instead
of <i> and <strong> instead of <b> , or using a <span> element to apply a
bold or italic style to a word isn't good practice semantically.
Search WWH ::

Custom Search