Author Archive: Charles Nadeau

Figure or aside: Figuring out the difference

Not unexpectedly, the goal of the semantic element figure is to flag illustrations, diagrams, and other content blocks that are referred to from the main content of the document. The author usually makes the referral in the text with a simple “See Exhibit 1″ or “See Illustration B,” or something along those lines. Content that could fall into this category include code samples, charts, graphs, and photos. The HTML spec even uses a poem as an example of a figure.

See this example figure (which itself could be flagged by a figure element on this blog page – whoa, meta!):

<p>The third quarter results were disappointing. For details, see Figure 2.</p>
...
<figure>
<img src="sales_Q3_FY12.jpeg" alt="Third quarter sales results">
<figcaption>Figure 2: Q3 sales results</figcaption>
</figure>

(The new figcaption element in the example is optional and self-explanatory.)

According to the HTML5 spec, one property of the figure element is that it “could, without affecting the flow of the document, be moved away from [the] primary content, e.g. to the side of the page, to dedicated pages, or to an appendix.”

Wait a minute, stuff on the side of a page that doesn’t affect the flow of the document sounds a lot like an aside element. How is a figure different?

Figure content has some relation to the main content, but so can aside content (at least in a tangential way). What then? The thing that seems to make the figure stand out is the reference made from the main content — the “See Figure 1″ part. The author wants to direct the reader to a figure, but not necessarily to an aside. The content in an aside is for users to discover on their own.

Finding your way: the nav element

It won’t come as a surprise to anybody that the nav element is defined in the HTML spec as representing “a section of a page that links to other pages or to parts within the page” and “a section with navigation links.” But not all links are created equal. The spec goes on to say that “the element is primarily intended for sections that consist of major navigation blocks.”

What qualifies as a “major navigation block” worthy of the nav element? One way to figure it out is to think of the search results for the page. Search crawlers will one day scrub web pages for various HTML5 elements, including the nav element. Think of the scrubbed information that will appear in search results. What navigation links for the page would you like people to click directly from the search result?

For example, say you have a group of “See also” links following an article on your page. Should you apply the nav element to the links? You probably wouldn’t want the links to appear in the page’s search result on Google. So in this case, no, the “See also” links are not nav-worthy.

The answer is not definitive because it could change depending on the page. Say you’re revamping a prehistoric HTML research report from 1995 with no main menu or any other links except for some “See also” links. Then you could argue that the “See also” links are a major navigation block and thus nav-worthy.

But wait, there’s more. The nav element can also make pages more accessible in the long run. Future screen readers could use the element to identify and skip navigation blocks, sparing listeners boring recitals of links. The element could also allow screen readers to scan and then out read the links to users on demand. All good stuff.

You can start using the nav element today to prepare for these and future developments in web technologies.

Spec: the nav element

Stand out from the search crowd

David Gould explains how the new structural elements — article, section, nav, aside — can help search engines improve how they understand and deliver your content. He writes that “the sooner that sites adapt their content to HTML5, the better chance they have to stand out from the sea of indistinct <div> tags — and to be ahead of the curve as search algorithms increasingly weight clean, semantic code.”

For example, the nav element can be like a town crier for search crawlers: “Oyez, oyez, this way to the most important content!”

The article element tells search crawlers that they’ve hit a rich vein of content. As Gould writes, “Text and images within an <article> is more clearly identified as primary content, and likely be weighted as more significant to a page than something tucked in an <aside> or <footer>.”

Read the rest at HTML5 and SEO: New Strategies for Optimizing Code.

Step aside

You can use the aside element for any section of content on your page that is “tangentially related” to the content around it. If you’re not sure if a chunk of content is tangentially related or not, it helps to think in terms of printed materials. An advertisement or a New Yorker cartoon would be considered asides. A parenthetical like a spec sheet in a car magazine review would not be considered an aside because the information is related to the other content in the review.

Here’s what the HTML5 spec has to say about the aside element and the distinction between tangentially related content and main content:

“The aside element represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content. Such sections are often represented as sidebars in printed typography.

“The element can be used for typographical effects like pull quotes or sidebars, for advertising, for groups of nav elements, and for other content that is considered separate from the main content of the page.

It’s not appropriate to use the aside element just for parentheticals, since those are part of the main flow of the document.”

Source: The aside element, HTML5 Edition for Web Developers (WHATWG)

Fairly straightforward except for the pull quote example. The spec says the pull quote qualifies for the aside treatment, yet aren’t pull quotes by definition a part of the main content of the page?

The third paragraph of the spec above hints at an answer. It talks about the main flow of the document. A parenthetical is part of the main flow but a pull quote is not. What’s the difference between the two? A pull quote repeats a bit of the main flow, so removing it (by a user agent, for example) would have no effect on the main flow of the document. Removing parenthetical information, however, subtracts information and would change the main flow of the document.

So I like the following test to determine if a chunk of content qualifies for the aside element: Can the chunk be removed by a user agent and not affect the main flow of my document? If yes, it qualifies for the aside element. If no, it doesn’t.

Surviving in a world without context

You can use the article element in HTML5 to mark chunks of your web page as standalone content. Example:

<article>
   <h1>title1</h1>
   content
</article>

<article>
   <h1>title2</h1>
   content
</article>

Aside from organizing the content of a page, the article element helps machines work with the page. To reduce clutter, for example, you could instruct mobile browsers to only display the articles in the document. Or in the future, a browser maker could add a feature to their Print dialog box that lets users print any or all of the articles in a document rather than full pages.

Not all content can be article-ized. The HTML5 Edition for Web Developers specifies that the article element “represents a self-contained composition in a document, page, application, or site and that is, in principle, independently distributable or reusable, e.g. in syndication. This could be a forum post, a magazine or newspaper article, a blog entry, a user-submitted comment, an interactive widget or gadget, or any other independent item of content.”

To determine if a piece of content is article-worthy, I apply the Facebook test. If a web crawler scraped the piece of content from my page, could somebody share the content (or a link to it) on Facebook? In other words, could the content survive in a world without context?

More information on the article element:

Section styling

If you use HTML5 section elements to structure content groupings on a page, and every level in the structure has a h1 heading, how do you style each heading level?

In the previous post, Structural engineering, I wrote that through the magic of the section element, you can make a browser grasp the structure of your document. Using section elements also allow each level in the structure to have a h1 heading. For example, the items in the following outline can all have h1 headings:

The Daily Planet
   News
      Local news
      National news
      International news
   Sports

Now say you want different styles for each heading level. The h1 type selector is obviously a no-go:

h1 {
   style declarations
}

You could use the section type selector with descendent selectors, but then you get CSS like this:

section h1 {style declarations}
section section h1 {style declarations}
section section section h1 {style declarations}

It leaves a bad taste in the mouth. The HTML5 spec discourages using semantic elements like section for styling purposes. Nicole Sullivan at stubbornella.org gives a good overview of the issue. She also suggests that that way coding madness lies. See this scary CSS example.

Another solution is to define and apply heading classes to h1 elements:

<h1 class="head1">
...
<h1 class="head2">
...

This is fine if you don’t have too many heading elements on your page. If you’re using section elements, you probably have lots of them. It also assumes you can edit the heading elements. Some content groupings may be syndicated and come with their own heading elements.

I think the best solution is to define and apply classes to the section elements instead of the h1 elements:

<section class="level1">
...
<section class="level2">
...

You can use descendent heading selectors with the classes to style the headings:

.level1 h1 {
   style declarations...
}

.level2 h1 {
   style declarations...
}

The fact the class names help you parse nested section elements in your markup is gravy.

Structural engineering

HTML5 introduces an intriguing if somewhat confusing element called the section element. The HTML5 spec specifies that “the section element represents a generic section of a document or application. A section, in this context, is a thematic grouping of content, typically with a heading.”

The “thematic grouping of content” bit is important. What does it mean for web pages? I find it useful to think of HTML5 section elements in terms of newspaper sections. A typical newspaper consists of a news section, a sports section, a business section, maybe other sections. Each section in the paper consists of a thematic grouping of content — news articles, sports articles, business articles.

A newspaper web page could look like this:

<h1>The Daily Planet</h1>

<section>

<h1>News</h1>
News articles…

</section>

<section>

<h1>Sports</h1>
Sports articles…

</section>

This is where I would tell Neo to buckle up because Kansas is going bye-bye. Notice how two h1’s follow each other (“The Daily Planet” and “News”), but the headings represent different levels in the structure of the document. HTML5 browsers and other user clients interpret the outline of the document as follows:

The Daily Planet
   News
   Sports

Whoa. In HTML5, you structure content groupings with sections instead of traditional heading elements. If you want to create sub-groupings, forget h2 or h3. Instead, nest sections in other sections as follows:

...
<section>

<h1>News</h1>

<section>

<h1>Local news</h1>
Local news articles…

</section>

<section>

<h1>National news</h1>
National news articles…

</section>

<section>

<h1>International news</h1>
International news articles

</section>

</section>

The updated table of contents of our online newspaper looks as follows:

The Daily Planet
   News
      Local news
      National news
      International news
   Sports

I used h1 headings for every level in the structure of the document. As the HTML5 Spec notes, “the use of section means that the author can use h1 elements throughout, without having to worry about whether a particular section is at the top level, the second level, the third level, and so on.”

For more information on the section element, see the WHATWG’s HTML5 Edition for Web Developers at http://developers.whatwg.org/sections.html#the-section-element.

Web Standards Hoedown

Who gives a damn who I’m frustratin’?
Look – my webpage is rotatin’!

Gather on Bruce Lawson’s website for a good old fashioned web standards hoedown.

Hint hint, nudge nudge

If you work with HTML forms, you can use a new HTML5 attribute to populate text fields with short hints to help users complete a form. If you’re reading this in Chrome, Safari, or Firefox 4 or later, here’s what I’m talking about:



(If you’re using IE, no biggie. It’s a regular input box, but without the hint.)

The browser clears the placeholder text when you click (or tab into) the field. If you click elsewhere without entering a value, the placeholder text returns. If you submit the form without entering a value, the browser ignores the placeholder text and submits the rest of the form data.

To start adding hints to your text fields, use the new placeholder attribute in the input element:

<input type="text" id="name" placeholder="Click me!" />

That’s it. You can use the attribute with any text input and textarea element, including input types like email, url, and password.

Until they figure out a better way, you can style placeholder text using the following vendor-specific CSS selectors for Mozilla (Firefox 4 or later) and Webkit (Chrome, Safari):

input:-moz-placeholder {
}
input::-webkit-input-placeholder {
}

It’s probably a good idea to stick with the basics — color, font-style, and font-variant. For more information, see “HTML5 Placeholder Styling with CSS” on David Walsh’s blog.

You’ll find more on the placeholder attribute here:

Feed the machine

HTML5 introduces a number of elements to provide context to content — elements like section, article, and nav.

Of course, using markup to provide context isn’t a new concept. Before HTML5, people used tags like <div id="nav"> to make pages more structured and usable. Unfortunately the attribute values of the div tag were left to the whim of developers so the tags didn’t make a lot of sense to machines. If <div id="deep_thoughts"> described your content, then bravo! But the machines were unimpressed.

The standardized semantic elements in HTML5 not only help humans make sense of the content but machines too. The elements open up realms of possibilities for the future. New products, features, and extensions could be developed. Examples:

  • A browser on a mobile device could hide all <aside> elements to reduce clutter
  • A standard browser could provide a print dialog that lets the user skip all <nav> elements
  • A screen reader could announce <aside> elements, or be configured to skip <nav> or <footer> elements
  • A search engine could sniff out headings to index pages more effectively, or pick up the links in nav elements to display them as quick links in search results.

Who knows? A yet-to-be-imagined use case could give birth to the next Internet giant.

For more information, see the Semantics section of the W3C HTML5 spec. For a good overview of semantic markup, see Semantic Markup and Page Layout by Jennifer Marsman on her MSDN blog.