Re: HTML5 feedback from prominent designers

Lachlan Hunt wrote:

>> Aside
>>
>> 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.
> 
> It's not clear how the aside element is too limited, although it's clear 
> from other recent e-mails that it's definition, and its intended purpose 
> for sidebars, is not at all clear.  This should be fixed by adjusting 
> the definition in the spec and including more examples showing how to 
> use it as a sidebar, rather than dropping it.

It seems clear that people (myself included) don't make the "a sidebar 
is to <body> as a pullout is to <article>" logical leap that forms the 
premise of using a single element for both functions. In the first, 
"sidebar" case <aside> is being used for stuff other than the main 
content of the page; site fluff like blog rolls, archive links, tag 
lists, and so on. In the latter case it is being used for actual page 
content; things like the quote box and the "606 Debate" box at [1] or 
the sidenote in [2] (to be clear: those examples don't use <aside> but 
they could). In both cases those pages also have sidebars but the type 
of content they contain is markedly different to that of their pullouts 
so it is highly non-obvious that they would be marked up in the same 
way. Nor is it obvious that UAs would treat the two cases similarly, 
something designed to strip away all the extraneous material from a page 
whilst leaving the content (e.g. [3]) would want to remove sidebars 
whilst leaving pullouts (although possibly rearraging them).

I don't think any amount of spec massage in the form of different 
wording or more examples is going to correct the design flaw that has 
become evident here. I think that <aside> for pullouts and footnotes is 
a great idea that has obvious associated UA behaviour.

If people want an analogue of <header> that means "sidebar" that also 
seems fine. Indeed, as a general point coming out of these 
conversations, people seem to design pages by going "this is header 
content, this is footer content, this is the main body and this is the 
sidebar". Then they look for elements to fill those roles and, failing 
that, use <div>+class. What one site places in a header another might 
place in a footer and a third might place in a sidebar so the way that 
<header>, <footer> and <sidebar> elements would be used in practice is 
likely to be almost indistinguishable content-wise. Trying to fight the 
way that people actually work for semantic purity seems unlikely to 
work. Perhaps we should embrace the improvements in source code clarity 
offered by making these elements purely "structural" with similar 
content models and semantics rather than trying to forcibly apply 
unwanted distinctions between them.

[1] http://news.bbc.co.uk/sport2/hi/tennis/8229377.stm
[2] 
http://www.quirksmode.org/blog/archives/2009/04/making_time_saf.html#link16
[3] http://lab.arc90.com/experiments/readability/

Received on Wednesday, 2 September 2009 10:59:49 UTC