Re: ISSUE-91 Change Proposal

Thanks for providing a Change Proposal for this issue! The chairs  are  
reviewing Change Proposals to ensure that they meet the required  
structure. Here is our feedback on this Change Proposal (actually the  
version subsequently uploaded to the wiki):

(1) This Change Proposal includes all of the required sections with  
appropriate content. The Rationale and Details sections seem sufficient.

We believe this Change Proposal is well-formed and ready for  
consideration by the Working Group.

Regards,
Maciej

On Mar 31, 2010, at 5:48 AM, Shelley Powers wrote:

> 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 Tuesday, 6 April 2010 20:21:20 UTC