RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


The HTML 5 Layout Elements Rundown : Page 2

HTML 5 is a broad specification with dozens of distinct changes from HTML 4. Get a comprehensive breakdown of the HTML 5 layout elements.


Layout Element Changes

Beyond the media elements (which will be deployed in the upcoming Firefox 3.5 implementation), a number of the new elements introduced into HTML 5 are intended to establish structure or divisions on the page.

<article> and <section>

The <article> tag is intended for use as a container to hold article content, such as the main story on a web page. Similarly, the <section> tag subdivides an article into individual sections, making it easier to identify and navigate such content. Within each of these, the headings tags (<h1>, <h2>, etc.) serve to demarcate header titles, indicating the level of importance of each particular section.

Two of the biggest mistakes made in the original HTML specification were not having a formal containment model for sections—content is simply a linear narrative with the occasional header rather than sections within sections—and reserving the <title> element early on as the title for the page itself within the <head> element.

One consequence of the latter mistake was that it prohibited the use of a generic <title> element as a section, image, table, or other structure label. At the same time, there no longer was a direct one-to-one correlation between the title of a document and the actual title of the main body (the article) within that document. At this stage, there's no real way to change this; <title> is too intimately embedded into the framework of the web to change its definition.

However, the use of the <article> and <section> groups indicates that the emerging HTML document bears an increasingly close resemblance to DocBook. What's more, such a containment organization will:

  • Make things such as automatic generation of meaningful tables of content far easier.
  • Make it generally simpler to lay out content in meaningful ways.
  • Make storing subordinate content within web pages for later inclusion more efficient, as you need only store the articles rather than the whole page.


HTML 5 includes a <hgroup> element that can hold subordinate <h1>, <h2>, etc. elements. This at least ameliorates one of the trickier problems involved with layout: providing a semantically consistent way of creating subtitles, especially at different levels in a document. For instance, take the following snippet:
         <h1>An Overview of HTML 5</h1>
         <h2>Looking at Spec Changes</h2>
    <p>This is the first paragraph.</p>
    <p>This is the second paragraph.</p>
               <h2>Laying out the markup</h2>
         <p>This is the subsection P1</p>


This markup shifts the h1 tag from a single document-level tag to something bound to the scope of its container, whether article or section. Using <hgroup> also makes it easier to put together tables of content. As HTML becomes more widely used for purposes other than simple browser display, changes like this should serve to make the language sufficiently flexible for print or other media organization.


The <aside> element establishes inline sidebars or related content. In a magazine, short articles often run within the context of a larger article. For instance, a review of HTML 5 may contain a quick summary of the relevant tags, as a floating block above or below the main article. While this is certainly feasible on the web, the implementation typically was left to CSS gurus (usually as part of a larger organizational stylesheet) because it was so difficult. The <aside> element performs the same function, but it lets the browser establish a default style-setting so that people can use it semantically without needing to know the gory details of supporting it in CSS.


The <nav> element uses a similar rationale to <aside>. Any given page usually draws a fairly clean line between the navigational elements and the primary content. One or more <nav> elements in a page clearly delineates what is navigational and what is content. As with <aside>, the role of <nav> is semantic more than presentational; it clearly identifies a given purpose for the content within the <nav>. A browser may then take this content and, without any CSS, lay it out in a cohesive manner.

<header> and <footer>

The <header> and <footer> elements work as additional page-level organizational elements. Header content appears at the top of the page, and footer content at the bottom. Both may end up getting repeated on each page when HTML documents are printed.

Typically, header content contains a web site's banner and related content, and it may contain a menu or nav element as well. The <footer> element, on the other hand, usually runs along the bottom of the page (though it may also be at the bottom of an article or section) and contains boilerplate legal content, secondary navigational links to pages and email, or related communication content.


There are a plethora of navigational structures within HTML 5, but the <menu> element may be one of the most important. In the abstract, a menu is a sequence of commands. In practice, a menu is a visible structure that can be one of three types:
  • Context Menu: The menu items contained within the menu replace the context menu for that page. The commands within the menu are available only when the user initiates the context menu sequence, typically by right- or option-clicking on a page.
  • Toolbar: When a toolbar menu is instantiated, it creates a toolbar if one doesn't already exist and establishes a menu on the toolbar in the order encountered.
  • List: The list items are simply enumerated either as a list (via the <li> tag) or inline via other elements. This is often useful when creating custom menu formats using CSS.

Each of the menus make use of <li> elements in order to define each entry, with the <command>, <a>, <button>, or related command-enabled elements actually performing the actions. For instance, if you wished to create a context menu that handled editing a blog, you'd probably build something like the following:

<menu type="context>
     <li><command label="Clear Record" action="this.clear()"/></li>
     <li><command label="Submit Record" action="this.submit('submission-agent'"/></li>
     <hr/> <!-- this creates a break --></hr>
     <li><command label="Search Records" action="this.search('submission-agent'"/></li>

Not surprisingly, menus can get very complex. Moreover, the menu specifications still don't appear as well established as those across most of the navigation elements.


In a couple of cases, HTML 5 repurposes existing content for more contemporary uses. As an example, one set of terms that are almost never used anymore are the <dl>, <dt>, and <dd> tags, used initially for dictionary entries (dictionary listing, dictionary term, dictionary definition). While <dl> is still supported, HTML 5 introduces the <dialog> tag and then uses <dt> and <dd> as speaker identifier and what's being spoken, respectively. Here is an example of <dialog> using a segment from the classic Abbot and Costello comedy routine, "Who's on First:"
    <dt> Costello</dt>
    <dd> Look, you gotta first baseman?</dd>
    <dt> Abbott</dt> 
    <dd> Certainly.</dd>  
    <dt> Costello</dt>  
    <dd> Who's playing first?</dd>  
    <dt> Abbott</dt>
    <dd> That's right.</dd>
    <dt> Costello</dt>  
    <dd> When you pay off the first baseman every month, who gets the money?</dt>
    <dt> Abbott</dt>  
    <dd> Every dollar of it.</dt>

The result is:

	Look, you gotta first baseman? 
	Who's playing first? 
	That's right. 
	When you pay off the first baseman every month, who gets the money? 
	Every dollar of it.

The beauty of this is that most older browsers will still render this more or less properly because the dictionary listing and dialog terms are very similar in underlying structure.


HTML 5 also adds a few new inline tags. The <mark> tag is designed to emphasize text content in a quotation that was added by the current writer, not the original quoted writer (such as emphasizing a particular statement within a paragraph). For instance, if you had a paragraph along the lines of:
<p>The economic conditions continue to deteriorate, <mark>even as the 
media focus on "green shoots" showing apparent growth in various sectors</mark> 
(emphasis mine).</p>

The result is:

The economic conditions continue to deteriorate, even as the media focus on "green shoots" showing apparent growth in various sectors (emphasis mine).

In addition to emphasizing previously quoted content, mark could be used to mark search terms in a retrieved web page or similar content.


The <time> element is used to wrap a specific date, time, or period of time in a semantic label, making it easier to build applications that can parse the document and build timelines. Here is an example for the Web 2.0 Conference:
<div class="event">
 <a class="url" href="http://www.web2con.com/">http://www.web2con.com/</a>
  <span class="summary">Web 2.0 Conference</span>:
  <time class="dtstart" datetime="2007-10-05">October 5</time> -
  <time class="dtend" datetime="2007-10-20">19</time>,
  at the <span class="location">Argent Hotel, San Francisco, CA</span>


The <details> element is perhaps more useful than <time>. It actually resolves a fairly common challenge for HTML: placing inline, detailed content into a page that shows up only when a link is activated. Tooltips were one way of solving this problem, but because most tooltip mechanisms (@alt or @title attributes) didn't allow for inline markup, the content could only be unmarked text. The <details> element changes this by using a <legend> element to render the link content, which when activated via a click or rollover would then pop up the contained, marked up text:
<p>The conference was most notable for it's coverage of <details>
<legend>HTML 5</legend> The successor to HTML 4 that's intended  
to work with new web technologies such as <i>AJAX</i> and inline 
graphics.</details> as well as other new standards.</p>

When rendered, the phrase "HTML 5" in the text would be highlighted in some manner. Also, when the user rolled over the link, the detailed text would be displayed in a popup or similar type of inline display.


The <figure> element provides yet another DocBook-like feature. Images, as originally defined, were generally seen as standalone entities in HTML. However, in many cases, it may be advantageous to have a wrapper around images (especially for blog content) that can also showcase a caption and possibly a sub-leader. This is the role of the <figure> element. In addition to acting as a container, specific identification of <figure> elements makes it possible to put together a table of figures (just as <section> elements would support a table of contents). Additionally, figures do not need to hold illustrations (though its likely this will be the common use case). They can be used as something between a sidebar (which is usually fully self contained) and a section. The <legend> element serves to identify the caption for the figure.

<progress> and <meter>

The <progress> and <meter> elements are intended to indicate the status of a given operation or state. Both are forms components, though they serve fairly different roles. The <progress> element is used to indicate the state of completion of a given operation, such as the percentage completed of a download operation. As such, it would typically be implemented as a progress bar. The <meter> element, on the other hand, is used to show a number within a given range of numbers, such as a gauge or other indicator.

It's a little hard to tell from the specification whether these are input controls, though it would seem odd if they weren't. Thus, if you wanted to show a grade inline as a ranking, it might look something like:

<div class="score">Your score was 
<meter value="88" min="0" max="100" low="64" high="96" optimum="100">B+</meter>

How this would be represented is still up in the air, however. Obviously, deriving the real value of something like both <meter> and <progress> would require using them in conjunction with JavaScript, something I actually find a little disturbing. The shift towards JavaScript-centric elements doesn't necessarily bode well for the use of HTML 5 in a purely declarative sense, and also illustrates the continued resistance on the part of the HTML contingency towards XForms, which is friendlier to a declarative architecture.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date