Welcome to a new semi-regular column, "The Road to HTML 5," where I'll try to explain some of the new elements, attributes, and other features in the upcoming HTML 5 specification.
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:
- It has to be possible to take existing markup (which correctly uses
- 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.
- It shouldn't be too easy to end up with meaningless markup when doing either of the above. So a random
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:
The header elements would be:
Further discussion:
Fast-forward to modern times. Using the <section> element instead of, say, <div class="section">, seems like a no-brainer. Unfortunately, there's a catch. (Hey, it's the web; there's always a catch.) Not all modern browsers recognize the <section> element, which means that they fall back to their default handling of unknown elements.
A long digression into browsers' handling of unknown elements
Every browser has a master list of HTML elements that it supports. For example, Mozilla Firefox's list is stored in nsElementTable.cpp. Elements not in this list are treated as "unknown elements." There are two fundamental problems with unknown elements:
- How should the element be styled? By default,
<p> has spacing on the top and bottom, <blockquote> is indented with a left margin, and <h1> is displayed in a larger font.
- What should the element's DOM look like? Mozilla's
nsElementTable.cpp includes information about what kinds of other elements each element can contain. If you include markup like <p><p>, the second paragraph element implicitly closes the first one, so the elements end up as siblings, not parent-and-child. But if you write <p><span>, the span does not close the paragraph, because Firefox knows that <p> is a block element that can contain the inline element <span>. So the <span> ends up as a child of the <p> in the DOM.
Different browsers answer these questions in different ways. (Shocking, I know.) Of the major browsers, Microsoft Internet Explorer's answer to both questions is the most problematic.
The first question should be relatively simple to answer: don't give any special styling to unknown elements. Just let them inherit whatever CSS properties are in effect wherever they appear on the page, and let the page author specify all styling with CSS. Unfortunately, Internet Explorer does not allow styling on unknown elements. For example, if you had this markup:
<style type="text/css">
section { border: 1px solid red }
</style>
...
<section>
<h1>Welcome to Initech</h1>
<p>This is our <span>home page</span>.</p>
</section>
Internet Explorer (up to and including IE8 beta 2) will not put a red border around the section.
The second problem is the DOM that browsers create when they encounter unknown elements. Again, the most problematic browser is Internet Explorer. If IE doesn't explicitly recognize the element name, it will insert the element into the DOM as an empty node with no children. All the elements that you would expect to be direct children of the unknown element will actually be inserted as siblings instead. I've posted an ASCII graph that illustrates this mismatch.
Sjoerd Visscher discovered a workaround for this problem: after you create a dummy element with that name, IE will recognize the element enough to let you style it with CSS. You can put the script in the <head> of your page, and there is no need to ever insert it into the DOM. Simply creating the element once (per page) is enough to teach IE to style the element it doesn't recognize. Sample code and markup:
<html>
<head>
<style type="text/css">
section { display: block; border: 1px solid red }
</style>
<script type="text/javascript">
document.createElement("section");
</script>
</head>
<body>
<section>
<h1>Welcome to Initech</h1>
<p>This is our <span>home page</span>.</p>
</section>
</body>
</html>
This hack works in IE 6, IE 7, and IE 8 beta 1, but it doesn't work in IE 8 beta 2. (bug report, test case) The purpose of this illustration is not to blame IE; there's no specification that says what the DOM ought to look like in this case, so IE's handling of the "unknown element" problem is not any more or less correct than any other browser. With the createElement workaround, you can use the <section> element (or any other new HTML 5 element) in all browsers except IE 8 beta 2. I am not aware of any workaround for this problem.
And in conclusion
The <section> element is a very straightforward HTML 5 feature that you can't actually use yet.
