Headings, Hierarchy and Document Structure

Eric Meyer has followed up on Tomas Jogin’s post Hierarchy in his post Pick a Heading. Something Eric said struck me, so I need to post as well. He provides a code sample from Netscape DevEdge that really got me thinking about where this might go in the future:

<h1>
 <a href="/" target="_top"><span>Netscape</span> DevEdge</a>
</h1>
<form action="/search/app/" id="srch" method="get">
<h4><label for="search-input">Search</label></h4>
("¦inputs"¦)
</form>
<h2>Netscape 7.1 is now available</h2>
("¦paragraph text"¦)
<h2>The DevEdge RSS-News Ticker Toolbar</h2>  
("¦paragraph text"¦)
<h3>Recent News</h3>
("¦list of links"¦)

Just some quick analysis here, if you haven’t read Eric’s post. Eric states himself that the heading order is “off” (h1-h4-h2-h2-h3) – but I think most would agree that the structure used makes sense. There are very legitimate reasons for this markup. First, the label for the form is in an h4 element so it will show up in the document outline (as it should) and is easily navigable for screen reader users or others that navigate via headings. It is marked up as an h4 – implying that it is less important that the two main sections of the page in question, and it is source ordered to be near the top – useful for all users, regardless of the device they are using, be it cell phone, PDA, desktop user agent with or without assistive technology.

What about the future?

Eric also points to the elements available to us in XHTML 2 — <section> element and the <h> element. In essence the W3C is telling us that heading hierarchy is to be determined by context and where the <h> element is in the document hierarchy. In theory this seems like quite a rational approach, and I’m sure many developers are looking for that level of semantic connection between a heading and all of the contents found within that “section”. Many of us are already doing that anyway — we’re just using divs with appropriate names.

So what about the code from DevEdge in XHTML 2? What would it look like? What happens when the source order conflicts with the hierarchical structure of the document? Let’s try it:

<section>
	<h><a href="/" target="_top"><span>Netscape</span> DevEdge</a></h>
  <section>
    <section>
      <section>
        <form action="/search/app/" id="srch" method="get">
        <h><label for="search-input">Search</label></h>
        ("¦inputs"¦)
        </form>
      </section>
    </section>
    <h>Netscape 7.1 is now available</h>
    ("¦paragraph text"¦)
    <h>The DevEdge RSS-News Ticker Toolbar</h>  
    ("¦paragraph text"¦)
    <section>
      <h>Recent News</h>
      ("¦list of links"¦)
    </section>
   </section>
</section>

Code bloat. Meaningless <section> elements added just to impose the correct hierarchical structure? Adding meaningless wrapper divs upon wrapper divs is frowned upon in our current practice. Why would adding nested sections within nested sections to provide the appropriate level of semantic structure be any different?

It may make sense for the content of an article or a resource or blog post or whatever to have a linear structure, but we can’t necessarily force linear structure on the rest of the site wrapped around that content.

Give us some options

Why not create a new attribute for the <section> element then? Call it level, call it whatever you want… This would allow for documents to have both implicitly and explicitly defined structures. If the “level” is not defined, the structure is determined completely by nesting. If levels are defined, then we mix the two — we remove the explicitly defined levels from the linear flow and place them accordingly. You know, kind of like absolutely positioned elements are removed from the regular document flow, we could absolutely position sections within the document hierarchy for outlining purposes.

<section> 
	<h><a href="/" target="_top"><span>Netscape</span> DevEdge</a></h>
  <section level="4">
        <form action="/search/app/" id="srch" method="get">
        <h><label for="search-input">Search</label></h>
        ("¦inputs"¦)
        </form>
  </section>
   <section>
    <h>Netscape 7.1 is now available</h>
    ("¦paragraph text"¦)
    <h>The DevEdge RSS-News Ticker Toolbar</h>  
    ("¦paragraph text"¦)
    <section>
      <h>Recent News</h>
      ("¦list of links"¦)
    </section>
   </section>
</section>

Document outline creators, other user agents, whatever, can then respect source order and we won’t all get stuck worrying about how exactly our documents look in a Document Outline Extension (albeit a very cool tool!), because we’ve defined precisely the hierarchical structure that we intend.

Admittedly, I’m examining this through the lens of current techniques and practices and what “works” in today’s user agents, but clearly we need to deal with this sooner rather than later… Either that, or we don’t ever move to XHTML 2, because at the end of the day, I’ll have to side with source order as being more important.

Other Related Posts:

• Headings defining document structure, from Richard Rutter
• About the hierarchy thing, from Anne van Kesteren
• Headding for Trouble, from Andy Budd
• Yet Another Post About Headings, from Mike Papageorge