- Starting a New Paragraph
- Adding Author Contact Information
- Creating a Figure
- Specifying Time
- Marking Important and Emphasized Text
- Indicating a Citation or Reference
- Quoting Text
- Highlighting Text
- Explaining Abbreviations
- Defining a Term
- Creating Superscripts and Subscripts
- Noting Edits and Inaccurate Text
- Marking Up Code
- Using Preformatted Text
- Specifying Fine Print
- Creating a Line Break
- Creating Spans
- Other Elements
This chapter is from the book
This chapter is from the book
This chapter is from the book
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. 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 called 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, "FriendlyFleasandFireFlies<wbr />FriendlyFleasandFireFlies<wbr />FriendlyFleasandFireFlies<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, 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 a supporting browser 
. The area for ruby text is highlighted:
<ruby>
base <rp>(</rp><rt>ruby chars</rt><rp>)</rp>
base <rp>(</rp><rt>ruby chars</rt><rp>)</rp>
</ruby>
A supporting browser will display the ruby text above the base (or possibly on the side), without parentheses.
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.
A browser that supports ruby ignores the rp parentheses and just presents the rt content 
and 
. However, a browser that doesn’t support ruby displays the rt content in parentheses, as seen here.
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 the base directionality of your content is right-to-left and 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>. bdo 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. You can use it to indicate a fractional value or a measurement within a known range. Or, in plain language, it’s the type of gauge you use for the likes of voting results (for example, “30% Smith, 37% Garcia, 33% Clark”), the number of tickets sold (for example, “811 out of 850”), numerical test grades, and disk usage.
HTML5 suggests 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). Chrome, one of the few 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 Chrome that supports meter displays the gauge automatically, coloring it in based on the attribute values. It doesn’t display the text in between <meter> and </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 
.
Most browsers, like Firefox, don’t support meter, so instead of a colored bar, they display 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="4.5" title="Miles">4.5</meter></p>
meter 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. Chrome displays it as a tooltip .
TIP
At the time of this writing, meter is supported only by Chrome 11+ and Opera 11+. This partially explains why you don’t yet see it in the wild too much. Feel free to use it, but just understand that most browsers will render the meter text rather than the visual gauge by default .
The progress element
The progress element is yet another of the new elements in HTML5. You use it for 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.
)
Firefox 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. 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 hard-code it in the HTML, that is, <progress max="100" value="37">37% saved</progress> 
. Of course, non-supporting browsers would display it similarly to 
.
)