Summary
Summary: Remove the aside element.
Rationale
Originally, my request for the aside element was to tighten its focus, and clean up the allowable content and usage. As I discovered with the figure element, though, covered in the Issue 90 change proposal, the more I looked at the element the harder time I had finding a good, solid reason for it to exist. Evidently, neither can the HTML5 editor, if one goes by the rationale he provided for rejecting my request to clarify the semantics, and structure, of the element:
Rationale: Concurred without counter-arguments above. As Shelley says, the draft was updated based on feedback from Web developers. Given that Web developers are the people who will be using this technology, that seems wise, and not at all something to be ashamed of.
If the element is so unimportant that the editor can’t provide a rationale other than a vague “web developers” want it, in the bug associated with it, then it is too unimportant to keep in the specification. However, the editor’s hubris aside, there is nothing “semantic” about the aside element, nor is there anything really useful about having the element. Consider its definition:
The aside element represents a section of a page that consists of content that is tangentially related to the content around the aside element, and which could be considered separate from that content. Such sections are often represented as sidebars in printed typography.
There’s a reason in the print world why sidebars are separate elements: they trigger different typesetting. There’s also a reason why sidebars are many times published slightly out of context of their use: they are large, and typographically, not always easy to fit into the text where they would be most appropriately placed. Tangential placement has meaning in the print world, but less so on the web, where everything can be tangentially related to everything else via a link or happenstance physical proximity because of web page design.
It’s a confusing element, too. Because of the use of “sidebar” in the definition, people are assuming that the aside element is really a sidebar element, as sidebar is known in the web context. They’re two separate things, though, regardless of name used. A sidebar in the web world should more properly be another section element, as the main column is a section, or perhaps a div element. Frankly, I’m not sold on the usefulness of section, either, but that’s outside of the scope of this change proposal.
The HTML5 editor did not intend aside to be a sidebar element[2], as sidebar is known on the web. What was the original intent, though, is lost in the confusion surrounding the element[3]. For instance, folks have had a hard time differentiating it from figure[4], because both sound almost identical, except that figure had a caption. Semantic markup should not be causing such confusion. That it does implies that people don’t understand the purpose for this element.
The key to understanding whether aside is useful or not is to ask ourselves what it provides from a web perspective that can’t be met by other elements (in combination with semantic markup, such as RDFa, Microformats, or Microdata, ARIA, or CSS). If the material in the aside is supposedly material that can be removed from the document, document in this case being some form of article, from a web perspective, this is material that is not contained as a child of the article element. If it is to be tangentially related, the article and the sidebar could share a parent element, or be tangentially related via a link.
Again, repeating what I stated earlier, we’re not faced with the same restrictions as the print world, where even tangentially related material has to be included within the actual document, itself. We can put material anywhere on the web, and tangentially relate it to the article with a link. If the aside is equivalent to a print world sidebar, then it could be just as easily moved to another section in the same web page, or even another web page and linked. We don’t need a special purpose element in the web world, because we’re not facing the same constraints as the print world.
Now, evidently the aside element can now be used as a sidebar, which further weakens its usefulness. How is the typical sidebar content we see on the web even tangentially related to the existing document? Other than a link to the document may or may not exist in the sidebar? Or do we even know what “document” is, in this case? Is the web page the document? Or only a specific article within a section within the web page? Again, what has meaning in the print world does not necessarily carry over easily into the web.
A semantically meaningful element should be one that, when a person first sees its description, he or she goes, “I can use this. I have needed this.” I’ve not seen this in response to the aside element, except when people are defending it’s existence in the HTML5 specification. The statements such as “I need this, I can use this”, should come first, before the element is defined, not after.
I’m not sure who first asked for the element, I haven’t been able to trace its roots. Regardless, I’ve not seen many in the web design and development world jump up and down with joy for its existence, primarily because most people are still scratching their head over it, wondering what it is, and why they should use it. The aside element has been a point of confusion in the past, and is still a point of confusion now, and will not somehow become magically less confusing in the future[5][6][7][8].
The HTML5 so-called Superfriends wrote a manifesto of support for HTML5, which also included the following[7]:
We are excited about the the ability in HTML5 to scope headings via the section element. This proposes a significant improvement in fluidity of content reuse and eases the burden of creating mashups….We would like to encourage spec authors to be conservative in including new tags, and only do so when they[sic] addition of the tag allows for significant gains in functionality. (emphasis mine)
There is a cost associated with every new element, attribute, and specification change. The cost is to browser developers, but in the case of an element like aside, more so to HTML editors, Content Management Systems, and other tools that now have to incorporate support for yet another new element. The cost is also to web designers and developers, trying to figure out what to use, and when.
If we’re truly concerned about helping web developers, we’re not doing so by introducing confusing elements. If it’s not semantically meaningful, or structurally useful, it should be removed.
Details
Based on the March 4th publication of the HTML5 specification, remove Section 4.4.5, on the aside element, and any other reference in the specification to the aside element.
A better approach would be to use existing elements, such as a div element, style it with CSS, and attach semantics using ARIA, RDFa, Microformats, or Microdata. After all, we now have four different ways we can apply semantics to a web page—we don’t need to create single purposed elements, too.
Impact
Positive
Removing the aside element removes a element that has generated confusion since its first release—a confusion that doesn’t seem to lessen over time. The element provides little in the way of semantics, because it’s more or less based on a construct from the print world, and doesn’t really have much application in a web environment. Structurally, it provides nothing useful.
Removing the element reduces the confusion, but is also a cost saver in the future for HTML tool builders. Though browsers can more or less treat aside like a div element, HTML editors and other tools cannot. If there was a genuine purpose for the existence of the element, the cost would be justified. But the element’s definition is now so general that we might as well consider it a synonym for the div element.
Negative
Removing the element will require Editor time.
References
[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=8447
[2] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-November/017596…
[3] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-October/023435….
[4] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-June/020267.html
[5] http://html5doctor.com/understanding-aside/
[6] http://html5doctor.com/aside-revisited/
[7] http://www.zeldman.com/superfriends/guide/
[8] http://www.webmonkey.com/2010/02/building_web_pages_with_html_5/#.3Casid…