Extra Credit | Web Standards Solutions: The Markup and Style Handbook (Pioneering Series)

< Day Day Up >

So far in this chapter, we've focused on and , which are part of a larger group of elements that the W3C likes to call "phrase elements." For extra credit, let's take a look at a few more of these phrase elements, and how they relate to the web standards world.

The Phrase Elements

In addition to and , the entire list of phrase elements as outlined by the W3C's HTML 4.01 Specification contains the following:

<cite>: Contains a citation or a reference to other sources
<dfn>: Indicates that this is the defining instance of the enclosed term
<code>: Designates a fragment of computer code
<samp>: Designates sample output from programs, scripts, etc.
<kbd>: Indicates text to be entered by the user
<var>: Indicates an instance of a variable or program argument
<abbr>: Indicates an abbreviated form (e.g., WWW, HTTP, URI, Mass., etc.)
<acronym>: Indicates an acronym (e.g., WAC, radar, etc.)

Let's take a deeper look at a few of these, beginning with <cite>.

<cite> Design

<cite> is an interesting element to discuss—especially when talking about substituting the tag due to its purely presentational nature. <cite> is used to reference a citation of a source: an author or publication. Historically, designers may have used the tag to render a book title in italics, but we've learned earlier in the chapter that CSS is the best tool for styling text this way.

You may suggest marking up a publication's title with instead—but when referencing a book or other publication, we're not intending to add emphasis; we're merely trying to set it apart from normal text. We're also trying to stay in line with conventional typography practices, where titles are often shown in italics (underlining is also common in the print world, but would create obvious confusion for a hyperlink).

Here enters the <cite> tag, specifically created for the job. Most browsers will even render text contained within <cite> tags in italics by default, and we can support that by adding a general CSS declaration that will do the same.

The Specification

The W3C is somewhat brief regarding the <cite> tag, simply saying in the HTML 4.01 Specification (www.w3.org/TR/html4/struct/text.html#h-9.2.1)

"<cite>: Contains a citation or a reference to other sources."

That's about all we have to go on, and it's unclear exactly what types of data we can wrap <cite> around. But by "sources," we can take to mean at least people and publications.

Let's take a look at <cite> in action.

 The novel, <cite>The Scarlet Letter</cite> is set in Puritan Boston and like this book, was written in Salem, Massachusetts.

From the use of <cite>, the title The Scarlet Letter will, in most browsers, be rendered in italics. To be sure, we'll add the following, utterly simplistic, CSS rule—for cases where the browser doesn't:

 cite {   font-style: italic;   }

To recap, we've replaced the tag for instances where we're marking up book titles and other publications with <cite>. What we get is italic text in most visual browsers, and once again, we get more structure and meaning added to our pages. That structure can, as always, be harnessed fully by the use of CSS. Let's take a look.

A Change in <cite> Style

When we talk about building pages with structure and meaning, it goes hand-in-hand with a page that becomes easier to style (and restyle) using CSS. Take for instance the <cite> tag. If we become consistent in marking up titles of publications with this tag, we then have full control over the style presented—to be changed at any time that we wish.

Let's say that we've authored an entire site, all the while using the <cite> tag to mark up references to book and publication titles. We've added the global CSS rule to render all <cite> elements in italics, but a few months later decide that we'd like all book and publication titles to be not only in italics, but also bold and red in color with a light gray background.

We can, of course, do this quickly and easily with a few CSS rules—instantly changing all references that we've previously marked up with the <cite> tag—something we couldn't specifically target if we had used or to simply render publication titles in italics.

 cite {   font-style: italic;   font-weight: bold;   color: red;   background-color: #ddd;   }

Figure 6-2 shows how this would appear in most browsers, and it's another nice example of the power of writing structural markup first—allowing you to make easy, site-wide design changes later.

Figure 6-2: A book title marked up with <cite> and styled with CSS

Leveraging the Structure

In addition to being easily styled, using structured markup can lead to interesting things when server-side software takes advantage of it.

Take for instance, what author and accessibility advocate Mark Pilgrim has done with the <cite> tag on his personal site, "dive into mark" (www.diveintomark.org/). By marking up citations to people and publications on his weblog with the <cite> tag, Mark was able to write software that would create a database from a parsing of all of his posts—organized then by the person or publication that is referenced (www.diveintomark.org/archives/citations/).

Figure 6-3 shows the results of searching for myself. Two posts were found on Mark's weblog—all thanks to the power of marking up the reference to "Dan Cederholm" with the <cite> tag.

click to expand
Figure 6-3: Mark Pilgrim's "posts by citation" results on "dive into mark" (www.diveintomark.org/archives/citations/dan_cederholm/)

<abbr> and <acronym>

Two other phrase elements that I'd like to note are <abbr> (for abbreviations) and <acronym> (for ... you guessed it, acronyms). Using these tags can improve the accessibility of web pages by giving definitions to abbreviations and acronyms, so that all users are informed.

Let's reacquaint ourselves with the W3C's HTML 4.01 Specification on what the <abbr> and <acronym> elements are used for:

<abbr>: Indicates an abbreviated form (e.g., WWW, HTTP, URI, Mass., etc.)
<acronym>: Indicates an acronym (e.g., WAC, radar, etc.)

Using these elements along with a suitable title attribute will help users who would be otherwise unfamiliar with the term. For instance, if we were marking up the abbreviation "XHTML", we could use the <abbr> tag like this:

 <abbr title="eXtensible HyperText Markup Language">XHTML</abbr>

Using <abbr> is this case can provide a cue for screen readers in regards to spelling out the text (X-H-T-M-L), rather than reading it as a normal word. Conversely, the use of <acronym> provides a cue to speak the word normally, rather than spell it out.

An example of the <acronym> tag could be applied to the following:

 <acronym title="North Atlantic Treaty Organization">NATO</acronym>

There are also two CSS rules that could be added to an aural style sheet to further reinforce these directives:

 abbr {   speak:spell-out;   } acronym {   speak:normal;   }

Aural style sheets allow authors to construct CSS rules specifically for screen reader applications. Harnessing structural markup, changes in pitch, voice-type, inflection, etc. can be altered to present the page aurally, more in line with what it reads like, visually.

Define Once

Many suggest defining an abbreviation or acronym that appears multiple times on a page only once. It's argued to be a waste of bytes to redefine a term each time it appears, and better to set the title attribute only on the first occurrence of the page. I tend to think this makes sense, although in the event that people are directed to a specific section of a page, and the abbreviation or acronym is only expanded at the top, then the user can't take advantage of the definition.

Use your best judgment on when (and how often) to define your terms contained within <abbr> and <acronym> tags.

The Presentation

To cue readers on the visual side, some browsers by default will render text marked up with <abbr> or <acronym> with a 1-pixel dotted bottom border, enticing users to move their mouse over the underlined abbreviation or acronym. When moused over, the definition provided in the title tag will show up in the browser as a "tooltip."

For browsers that don't by default add that dotted line, we can easily create a CSS declaration that does essentially the same:

 abbr, acronym {   border-bottom: 1px dotted;   cursor: help;   }

We've also added an additional rule that will turn the cursor (in most browsers) into the "help" symbol, which will help signify that this isn't a link to be clicked on, but rather a definition to be expanded with the "tooltip" (Mark Newhouse, "Real World Style: CSS Help," http://realworldstyle.com/css_help.html).

Figure 6-4 shows the results in a browser, with the abbreviation "XHTML" being expanded with its definition—as well as a dotted border and "help" cursor.

Figure 6-4: Example of <abbr> results in a typical browser

Compatibility Issues

It's important to mention that, at the time of this writing, Internet Explorer for Windows doesn't support the styling or tooltip for the <abbr> element. IE/Win does support the <acronym> element, which has encouraged some designers to use only <acronym> for both abbreviations and acronyms alike.

It might be tempting to do the same, but using the wrong element for the sake of a display issue seems like the wrong road to take. For this specific problem, I prefer marking the term up according to the specifications, letting browsers that properly handle the <abbr> element style it accordingly.

Let's take a quick look at the remaining phrase elements that we haven't yet covered.

<code>

The <code> element is designed for demonstrating code examples within XHTML pages. For instance, if you'd like to share a CSS example, you could do something like this:

 <code> #content {   width: 80%;   padding: 20px;   background: blue;   } </code>

Generally, visual browsers will render text held within <code> tags in a monospaced serif font, but we could, of course, style code examples any way we wish by adding a CSS rule:

 code {   font-family: Courier, serif;   color: red;   }

All text contained in <code> would now be rendered with the Courier typeface in red.

<samp>

The <samp> element is used to show sample output from programs and scripts. For example, if I were talking about the results of a Perl script I was working on, I may say something like

 <p>When the script has executed, at the command line you will see the message <samp>script was successful!</samp>.</p>

Here, I'm essentially "quoting" the output of a script, and a similar CSS rule could be defined for styling program samples uniquely—just as we had done with <code> elements.

<var>

Related to the <samp> element, the <var> element is used to designate a program parameter or variable. For instance, if I were talking about an XSLT style sheet, I could code the following:

 <p>I'm going to pass the parameter <var>lastUpdated</var> to my main.xsl file.</p>

Many browsers will render text within <var> tags in italics—but feel free to write a simple rule that would override that. If we don't like italics, we could use the font-style property in CSS:

 var {   font-style: normal;   font-family: Courier, serif;   color: purple;   }

Lastly, let's take a look at the <kbd> element to finish off the phrase elements.

<kbd>

The <kbd> element is used to signify text to be entered by the user. For example, if I were explaining how someone might use the accesskey we had assigned to switch focus to a search box, I might say

 <p>To quickly change focus to the search input field, Mac users type <kbd>Command+9</kbd>.</p>

You can only guess what I'm going to say next, can't you? That's right! Through the magic of a simple CSS rule, you can customize the style of all <kbd> elements, just as we had previously with the other phrase elements.

< Day Day Up >