- Adding a Paragraph
- Specifying Fine Print
- Marking Important and Emphasized Text
- Creating a Figure
- Indicating a Citation or Reference
- Quoting Text
- Specifying Time
- Explaining Abbreviations
- Defining a Term
- Creating Superscripts and Subscripts
- Adding Author Contact Information
- Noting Edits and Inaccurate Text
- Marking Up Code
- Using Preformatted Text
- Highlighting Text
- Creating a Line Break
- Creating Spans
- Other Elements
Other Elements
This section covers other elements that you can include within your text, but which typically have fewer occasions to be used or have limited browser support (or both).
The u element
Like b, i, s, and small, the u element has been redefined in HTML5 to disassociate it from its past as a non-semantic, presentational element. In those days, the u element was for underlining text. Now, it’s for unarticulated annotations (sounds a little befuddling, I know). HTML5 defines it thus:
- The u element represents a span of text with an unarticulated, though explicitly rendered, non-textual annotation, such as labeling the text as being a proper name in Chinese text (a Chinese proper name mark), or labeling the text as being misspelt.
Here is an example of how you could use u to note misspelled words:
<p>When they<u class="spelling">
recieved</u> the package, they put it with<u
class="spelling">there </u> other ones with the intention of opening them all later.</p>
The class is entirely optional, and its value (which can be whatever you’d like) doesn’t render with the content to explicitly indicate a spelling error. But you could use it to style misspelled words differently (though u still renders as underlined text by default). Or you could add a title attribute with a note such as “[sic]”—a convention in some languages to indicate a misspelling.
Use u only when an element like cite, em, or mark doesn’t fit your desired semantics. Also, it’s best to change its styling if u text will be confused with linked text, which is also underlined by default .
Like links, u elements are underlined by default, which can cause confusion unless you change one or both with CSS.
The wbr element
HTML5 introduces a cousin of br named wbr. It represents “a line break opportunity.” Use it in between words or letters in a long, unbroken phrase (or, say, a URL) to indicate where it could wrap if necessary to fit the text in the available space in a readable fashion. So unlike br, wbr doesn’t force a wrap; it just lets the browser know where it can force a line break if needed.
Here are a couple of examples:
<p>They liked to say, "FriendlyFleas andFireFlies<wbr/>
FriendlyFleasandFireFlies<wbr />
FriendlyFleasa ndFireFlies<wbr />
" as fast as they could over and over.</p> <p>His favorite site is this<wbr />
is<wbr />
a<wbr />
really<wbr />
really<wbr />
longurl.com.</p>
You can type wbr as either <wbr /> or <wbr>. As you might have guessed, you won’t find many occasions to use wbr. Additionally, browser support is inconsistent as of this writing. Although wbr works in current versions of Chrome and Firefox, Internet Explorer and Opera simply ignore it.
The ruby, rp, and rt elements
A ruby annotation is a convention in East Asian languages, such as Chinese and Japanese, and is typically used to show the pronunciation of lesser-known characters. These small annotative characters appear either above or to the right of the characters they annotate. They are often called simply ruby or rubi, and the Japanese ruby characters are known as furigana.
The ruby element, as well as its rt and rp child elements, is HTML5’s mechanism for adding them to your content. rt specifies the ruby characters that annotate the base characters. The optional rp element allows you to display parentheses around the ruby text in browsers that don’t support ruby.
The following example demonstrates this structure with English placeholder copy to help you understand the arrangement of information both in the code and in supporting and non-supporting browsers. The area for ruby text is highlighted:
A supporting browser will display the ruby text above the base (or possibly on the side) without parentheses because it ignores the rp elements.
A non-supporting browser displays the rt con-tent in parentheses in the normal flow of content.
<ruby> base <rp>(</rp><rt>ruby chars </rt>
<rp>)</rp> base <rp>(</rp><rt>ruby chars </rt>
<rp>)</rp> </ruby>
Now, a real-world example with the two Chinese base characters for “Beijing,” and their accompanying ruby characters :
<ruby> <rp>(</rp><rt></rt><rp>) </rp> <rp>(</rp><rt></rt><rp>) </rp> </ruby>
Now, the ruby markup for “Beijing” as seen in a supporting browser.
You can see how important the parentheses are for browsers that don’t support ruby . Without them, the base and ruby text would run together, clouding the message.
In a non-supporting browser, the content could be harder to understand without the parentheses.
The bdi and bdo elements
If your HTML pages ever mix left-to-right characters (like Latin characters in most languages) and right-to-left characters (like characters in Arabic or Hebrew), the bdi and bdo elements may be of interest.
But first, a little backstory. The base directionality of your content defaults to left-to-right unless you set the dir attribute on the html element to rtl. For instance, <html dir="rtl"
lang="he"> specifies that the base directionality of your content is right-to-left and that the base language is Hebrew.
Just as I’ve done with lang in several examples throughout the book, you may also set dir on elements within the page when the content deviates from the page’s base setting. So if the base were set to English (<html lang="en">) and you wanted to include a paragraph in Hebrew, you’d mark it up as <p dir="rtl" lang="he">...</p>.
With those settings in place, the content will display in the desired directionality most of the time; Unicode’s bidirectional (“bidi”) algorithm takes care of figuring it out.
The bdo (“bidirectional override”) element is for those occasions when the algorithm doesn’t display the content as intended, and you need to override it. Typically, that’s the case when the content in the HTML source is in visual order instead of logical order.
Visual order is just what it sounds like—the HTML source code content is in the same order in which you want it displayed. Logical order is the opposite for a right-to-left language like Hebrew; the first character going right to left is typed first, then the second character (in other words, the one to the left of it), and so on.
In line with best practices, Unicode expects bidirectional text in logical order. So if it’s visual instead, the algorithm will still reverse the characters, displaying them opposite of what is intended. If you aren’t able to change the text in the HTML source to logical order (for instance, maybe it’s coming from a database or a feed), your only recourse is to wrap it in a bdo.
To use bdo, you must include the dir attribute and set it to either ltr (left-to-right) or rtl (right-to-left) to specify the direction you want. Continuing our earlier example of a Hebrew paragraph within an otherwise English page, you would type <p lang= "he"><bdo dir="rtl">
...</bdo>
</p>. The bdo element is appropriate for phrases or sentences within a paragraph. You wouldn’t wrap it around several paragraphs.
The bdi element, new in HTML5, is for cases when the content’s directionality is unknown. You don’t have to include the dir attribute, because it’s set to auto by default. HTML5 provides the following example, which I’ve modified slightly:
- This element is especially useful when embedding user-generated content with an unknown directionality.
In this example, usernames are shown along with the number of posts that the user has submitted. If the bdi element were not used, the username of the Arabic user would end up confusing the text (the bidirectional algorithm would put the colon and the number “3” next to the word “User” rather than next to the word “posts”).
<ul> <li>User<bdi>jcranmer</bdi>:
12 posts.</li> <li>User<bdi>hober</bdi>:
5 posts.</li> <li>User<bdi>
</bdi>:
3 posts.</li> </ul>
The meter element
The meter element is another that is new thanks to HTML5. At first glance, it seems very similar to the progress element, covered next, which is for indicating “the completion progress of a task” (to quote the spec).
In contrast, you can use meter to indicate a fractional value or a measurement within a known range. In plain language, it’s the type of gauge you use for the likes of voting results (for example, “30% Smith, 37% Garcia, 33% Hawkins”), the number of tickets sold (for example, “811 out of 850”), a numerical test grade (for example, “91 out of 100”), and disk usage (for example, “74 GB out of 256 GB”).
HTML5 suggests (but doesn’t require) that browsers could render a meter not unlike a thermometer on its side—a horizontal bar with the measured value colored differently than the maximum value (unless they’re the same, of course). Firefox, one of the browsers that supports meter so far, does just that . For non-supporting browsers, you can style meter to some extent with CSS or enhance it further with JavaScript.
A browser, like Firefox, that supports meter displays the gauge automatically, coloring it based on the attribute values. It doesn’t display the text in between <meter> and </meter>. As seen in the last example, if you include title text, it displays when you hover over the meter.
Although it’s not required, it’s best to include text inside meter that reflects the current measurement for non-supporting browsers to display .
IE9 doesn’t support meter, so instead of a colored bar, it displays the text content inside the meter element. You can change the look with CSS.
Here are some meter examples (as seen in and ):
<p>Project completion status:<meter
value="0.80">80% completed</meter> </p> <p>Car brake pad wear:<meter low= "0.25" high="0.75" optimum="0" value="0.21">21% worn</meter></p>
<p>Miles walked during half-marathon:<meter min="0" max="13.1" value="5.5" title="Miles">4.5</meter>
</p>
The meter element doesn’t have defined units of measure, but you can use the title attribute to specify text of your choosing, as in the last example. As is usual with title text, browsers display it as a tooltip .
The progress element
The progress element is yet another of the new elements in HTML5. As stated earlier, it indicates the completion progress of a task. Think of a progress bar, like the kind you might see in a web application to indicate progress while it is saving or loading a large amount of data.
As with meter, supporting browsers automatically display a progress bar based on the values of the attributes . And again like meter, it’s usually best to include text (for example, “0% saved,” as shown in the example) inside progress to reflect the current progress for older browsers to display , even though it’s not required.
A browser, like Firefox, that supports progress displays the progress bar automatically, coloring it based on the value. It doesn’t display the text in between <progress> and </progress>. The value attribute is set to 0 in this example, so the bar indicates no progress.
IE9 doesn’t support progress, so instead of a colored bar, it displays the text content inside the element. You can change the look with CSS.
Here’s an example:
<p>Please wait while we save your
data.</p>
<p>Current progress: <progress
max="100" value="0">0% saved
</progress>
</p>
A full discussion of progress is beyond the scope of this book, since typically you would dynamically update both the value attribute and the inner text with JavaScript as the task progresses (for example, to indicate that it’s 37% completed). The visual results are the same whether you do that with JavaScript or code it that way in the HTML initially; for example, <progress max="100" value="37"
>37% saved
</progress> . Of course, non-supporting browsers would display it similarly to .
The progress bar in Firefox when the value attribute is set to 37 programmatically with JavaScript (or directly in the HTML), assuming max="100". The blue area reflects the amount of progress.