ISSUE-91 Change Proposal

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
specific 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, limited rationale 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. Sidebar in
print and sidebar in web are 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.

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 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 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 be used as a sidebar, which
further weakens its usefulness, and the original semantics. 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...

Received on Wednesday, 31 March 2010 12:48:53 UTC