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 article and section elements are redundant and, therefore, that the article element should be dropped.
article and section are identical except that article allows a pubdate attribute. We would suggest that article be dropped and section be adapted to allow an optional pubdate attribute or, even better, more explicit metadata.
The article and section elements are not identical according the to HTML5 draft specification. Here is what it says about the section element as of 13 September 2009:
The section element 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 article element:
The article element represents a section of a page that consists of a composition that forms an independent part of a document, page, application, or site.
An 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 article and section 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 section element. This generic element serves only to thematically group content. That grouping may occur at the document level, within an independent article, or within a footer.
The 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 up with 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 HTML5.
What may be needed is a stronger clarification and definition of the article element to minimise the potential for this distinction to be overlooked and to highlight the differences from a generic document section.
The hgroup element is a relatively recent addition to the draft specification. It is defined as serving a fairly specific purpose:
The hgroup element represents the heading of a section. The element is used to group a set of h1–h6 elements 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 hgroup element:
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 hgroup is clumsy and likely to be misused. Rather than wrap an h1 and its h2 subtitle in hgroup to 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 hgroup element. The hgroup element 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.
The hgroup itself acts as heading content while a boolean attribute would act only to remove headings from the outline. The hgroup element 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 subheadings.
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 nav elements, 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 aside 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 fieldset, figure or 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 details and figure – 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 advantage.
I have discussed my reasons for disagreeing with certain feedback on the HTML5 draft specification. I have yet to be convinced that the article, hgroup, or aside elements should be dropped from the specification because it seems to me that they have necessary uses and advantages over alternatives.