In the last few months there has been increased discussion about some of the new elements that have been introduced in the HTML5 draft specification. This entry is primarily a counter argument to some of the comments that I disagree with.
The most recent and high-profile comments in regard to parts of the HTML5 specification come from The HTML5 Super Friends in an article entitled Guide to HTML5 Hiccups. It lays out their concerns with the HTML5 draft specification as it stood at the time of its writing and I am largely going to focus on the issues they have discussed.
The first argument that I disagree with is that the
elements are redundant and, therefore, that the
article element should be
sectionare identical except that
pubdateattribute. We would suggest that
articlebe dropped and
sectionbe adapted to allow an optional
pubdateattribute or, even better, more explicit metadata.
section elements are not identical according the to HTML5
draft specification. Here is what it says about the
element as of
13 September 2009:
sectionelement represents a generic document or application section. A section, in this context, is a thematic grouping of content, typically with a heading, possibly with a footer.
Now contrast that with what it says about the the
articleelement represents a section of a page that consists of a composition that forms an independent part of a document, page, application, or site.
article element is “independent” in the sense that its contents could
stand alone, for example in syndication, or as a interchangeable component on a
user-configurable portal page.
That is a clear distinction that resists the reading of
being “identical”. The
article element has a specific purpose: to mark parts
of a document that form an independent composition that may be appropriate for
syndication. It is a special kind of sectioning element that performs an
essential role that is lacking in the semantics of the generic
element. This generic element serves only to thematically group content. That
grouping may occur at the document level, within an independent
article element has unique semantics and practical use. There is a
fundamental conceptual difference between stand-alone compositions and sections
of compositions, documents, or pages and this difference should be recognised
and catered for in the specification. Websites regularly employ microformats
and you don’t have to look far to see independent compositions currently marked
class="hentry" or find links to individual blog comments and twitter
updates. There is clearly a need for an easy way to define independent
compositions and that is met with the introduction of the
article element in
What may be needed is a stronger clarification and definition of the
element to minimise the potential for this distinction to be overlooked and to
highlight the differences from a generic document section.
hgroup element is a relatively recent addition to the draft
specification. It is defined as serving a fairly specific purpose:
hgroupelement represents the heading of a section. The element is used to group a set of
h6elements when the heading has multiple levels, such as subheadings, alternative titles, or taglines.
The element works to associate headings together so that the highest ranked
heading descendant (if present) of the
hgroup element is used as its text in
document outlines and summary. Other heading descendants are treated as
subheadings and are left out of outlines.
The HTML5 Super Friends have this to say about the
We don’t see the added value of this element and would instead add a boolean attribute to the heading element which allows content authors to specify if that particular heading should be included in the outline.
Bruce Lawson has similar concerns and proposes another alternative – removing the need for a wrapping element and defining a new element specifically for marking up subtitles:
I agree that
hgroupis clumsy and likely to be misused. Rather than wrap an
hgroupto keep the subtitle out of the outlining algorithm, I would prefer to use
<header> <h1>My blog</h1> <subtitle>My wit and wisdom</subtitle> </header>
as I think that;s easier to understand than a heading-that’s-not-a-heading, and it removes a wrapping element.
I disagree with these criticisms of the
hgroup element and consider the
proposed alternatives to be more problematic, less intuitive, less flexible,
and further removed from the way in which authors currently markup subheadings.
The way that many authors are currently marking up subheadings is by using headings of various ranks and in various orders depending on whether the subheading or qualifying heading needs to appear above or below the main page heading. A subheading is still, conceptually, a heading of sorts and it cannot be accurately marked up with a paragraph or any other currently available element.
Allowing the addition of a boolean attribute to heading elements has several problems.
A boolean attribute may be less intuitive for authors than the
hgroupelement relies upon and produces an association between all the headings it contains. Since headings and subheadings occur together and derive their meaning from each other, it is semantic to wrap these headings in an element. We know that the highest ranked heading contains the string to be used in the outline and that the other headings serve as ranked subheadings to this primary heading. A boolean attribute is only associated with the element that it is a part of. We can create no association between the element and adjacent elements. This is related to the next issue.
hgroupitself acts as heading content while a boolean attribute would act only to remove headings from the outline. The
hgroupelement only removes the descendant headings that are those not of the highest rank. The boolean attribute shifts the burden onto the author to decide which headings should be marked for removal from the outline, rather than providing an element to wrap a collection of headings without authors having to be concerned with (or aware of) issues of outlining.
What about Bruce Lawson’s idea for a
subtitle element? I believe that,
irrespective of the what this element were actually called, it suffers from
similar problems to the idea of using a boolean attribute. There is nothing to
prevent the use of a
subtitle element away from a heading, it creates no
association with other elements, and it does not allow for ranking of
One of my key points in relation to criticism of the
hgroup element is that
subheadings draw their meaning from context. A subheading (as opposed to a
section heading) is only a sub-heading if it is associated with a higher
ranking heading. Remove the higher ranking heading and what was once a
subheading is likely to be understood as a heading.
The strength of the
hgroup element over the two alternative suggestions I
have referenced is that it is the only proposal that defines a subheading as
contextual. I think that it is the most intuitive proposal (although perhaps
none of them are particularly inuitive) – the name of the element is
self-descriptive and encapsulates the contextual relationship and adjacent
positioning of its child elements — and matches most closely with the way
that subheadings are currently marked up on many websites.
The HTML5 Super Friends are of the opinion that the
aside element is not
worth including in the specification:
The use cases for aside are too limited to warrant its inclusion in the specification. We were also concerned about potentially duplicating content within an aside.
However, the specification itself provides some fairly compelling uses for the element:
The element can be used for typographical effects like pull quotes or sidebars, for advertising, for groups of
navelements, and for other content that is considered separate from the main content of the page.
Authors might use the
aside element for their blogrolls, for marking up
adverts ranging from google ads on blogs to large banners on enterprise
websites, for expanding on themes within an article or providing an extended
definition of a term, for pull quotes, and anything else “tangentially
related to the content around the aside element, and which could be considered
separate from that content”.
Most of these uses would not involve duplication of content. Using the
element for pull quotes would produce some instances of content duplication.
However, this is not really a problem for users who are used to content being
duplicated in this way in newspapers and magazines. It would not take much for
search engines to adapt to deal with short amounts of duplicate content
contained within an
aside either. While I appreciate the point about
duplicate content I’m not yet convinced that it is actually problematic.
The current specification defines the
legend element as providing an
explanatory caption for the contents of its parent element. The parent element
may be a
details element. However, Remy
Sharp‘s article entitled legend not such a legend
anymore shows why it
is not practical to use
legend for the new elements
because it is not backwards compatible with current browsers and effectively
unusable outside of a
fieldset because of the inability to style the element.
In this case, forging a new element is most appropriate rather than trying to
use an element like
label which will only create confusion with little
I have discussed my reasons for disagreeing with certain feedback on the HTML5
draft specification. I have yet to be convinced that the
aside elements should be dropped from the specification because it seems
to me that they have necessary uses and advantages over alternatives.