Thursday, November 6th, 2008

HTML 5: The Section Element

Category: HTML, Standards

Mark Pilgrim kicked off a series of posts that keep track of the goings on in HTML 5, and has now created the first article in a new series: The Road to HTML 5 – Episode 1: the section element.

The Road to HTML 5 will go into detail on a particular feature of HTML 5 rather than a broad look on waht has happened that week:

The element of the day is the <section> element.

The section element represents a generic document or application section. A section, in this context, is a thematic grouping of content, typically with a header, possibly with a footer. Examples of sections would be chapters, the various tabbed pages in a tabbed dialog box, or the numbered sections of a thesis. A Web site’s home page could be split into sections for an introduction, news items, contact information.

Discussion of sections and headers dates back several years. In November 2004, Ian Hickson wrote:

Basically I want three things:

  1. It has to be possible to take existing markup (which correctly uses <h1><h6>) and wrap the sections up with <section> (and the other new section elements) and have it be correct markup. Basically, allowing authors to replace <div class="section"> with <section>, <div class="post"> with <article>, etc.
  2. It has to be possible to write new documents that use the section elements and have the headers be automatically styled to the right depth (and maybe automatically numbered, with appropriate CSS), and yet still be readable in legacy UAs, without having to think about old UAs. Basically, the header element has to be header-like in old browsers.
  3. It shouldn’t be too easy to end up with meaningless markup when doing either of the above. So a random <h4> in the middle of an <h2> and an <h3> has to be defined as meaning _something_.

At the moment what I’m thinking of doing is this (most of these ideas are in the draft at the moment, but mostly in contradictory ways):

The section elements would be:

<body> <section> <article> <navigation> <sidebar>

The header elements would be:

<header> <h1> <h2> <h3> <h4> <h5> <h6>

<h1> gives the heading of the current section.

<header> wraps block-level content to mark the whole thing as a header, so that you can have, e.g., subtitles, or “Welcome to” paragraphs before a header, or “Presented by” kind of information. <header> is equivalent to an <h1>. The first highest-level header in the <header> is the “title” of the section for outlining purposes.

<h2> to <h6> are subsection headings when used in <body>, and equivalent to <h1> when used in one of the section elements.

<h1> automatically sizes to fit the current nesting depth. This could be a problem in CSS since CSS can’t handle this kind of thing well — it has no “or” operator at the simple selector level.

<h2><h6> keep their legacy renderings for compatibility.

Posted by Dion Almaer at 9:31 am

2.7 rating from 24 votes


Comments feed TrackBack URI

Y not just use divs?

Comment by theKryz — November 6, 2008

Use of the new tags would carry greater meaning for the content then a div with a class. It would also unify how people use the tags. When we get sections, some one could use JS to query out all the sections from a page, where as now they would have to guess what class was used to define a section on that particular site, and hope that the creators used the same class for all sections.

Comment by jonhartmann — November 6, 2008

Because HTML 5 is evolutionary and not revolutionary…

Comment by TNO — November 6, 2008

Divs are semantically meaningless (by design). Sections are not.

If you’re asking why not use divs in place of semantically meaningful sections, the question then becomes “why not use only divs and spans?”

Comment by eyelidlessness — November 6, 2008

You forgot a pretty big part of the post: IE’s custom element support sucks in IE = unworkable back-compatibility = this probably isn’t going to work. Will this mean the end of all new block-level elements proposed or am I missing something?

Comment by mrclay — November 6, 2008

Issues like this are the reason xsl + xml was invented. Define your own syntax and your own semantics….

Comment by TNO — November 7, 2008

@TNO: The purpose of a broader set of universal semantics is for interoperability. It is sensible to say “I want to get all <section> elements from this HTTP response”, while it is useless to say “I want to get all elements with classes like ‘section’, ‘psuedo-namespace-section’, ‘arbitrary-section-name’ and so on.”
The semantics added to HTML5 are important because they specify semantics for concepts in almost universal use with an almost endless list of semantic variation.

Comment by eyelidlessness — November 7, 2008

Almost seems like a fruitless labor for these uber dudes. HTML5 has been “in development” for about one million years now (literally). In the mean time, there is already RDF, microformats, etc… as well as great services like

By the time HTML5 is out/adopted the world will have already made the move to other more powerful semantic engines. And no, there will never be just ONE.

Anyway, keep up the great work. Don’t think I’m not happy that HTML5 is being worked on, it’s just really NOT going to be a big deal, especially at the rate at which progress is being made.

Comment by RyanGahl — November 7, 2008

I was responding to mrclay’s issue with backwards compatibility. But since you brought it up, I have no issue with the semantics added by HTML5, but the fact remains that its based on current uses and which way the wind blows that will inevitably lead to migration tax further down the road (hence my referring to it as being evolutionary and not revolutionary like xml)

Comment by TNO — November 7, 2008

Actually, this is an element I really missed. So in my opinion sections may become very useful. I totally agree, that using divs everywhere, would remove the semantic of HTML. It’s an application of XML, not the other way round.

Comment by blindgaenger — March 20, 2009

Leave a comment

You must be logged in to post a comment.