Re: Implementor feedback on new elements in HTML5

On Tue, Sep 1, 2009 at 3:54 PM, Lachlan Hunt<> wrote:
> Tab Atkins Jr. wrote:
>> 1.<footer>  is simply horribly named.  I like the semantics
>> (essentially, article metainfo), and would in practice often mark up
>> what<footer>  represents with a classed div...
>> My suggestion is to move the current semantics of<footer>  into an
>> element without a confusingly structural name - I suggest<info>  or
>> <articleinfo>.  Though something with "meta" in the name feels right,
>> most peopleThen make<footer>  into a genuinely structural element
>> identical to<header>, with the only difference between them being
>> where in the section they generally appear.  Yes, this feels wasteful
>> to have two identical elements differing only by their placement, but
>> if we're trying to capture common classnames here, the data is clear -
>> .header and .footer are *extremely* common.
> It is not necessary to add a new element.  All that needs to be done is to
> remove the restrictions on the footer element's content model, and allow the
> header and footer to be used for what they were designed to be used for, in
> ways that authors expect to be able to use them.

That's not sufficient; it only addresses the problem from *one* side -
authors using <footer> where they shouldn't.  It doesn't solve the
problem at the other side, where you have data that would very
obviously be marked up with <footer> if it was at the end of the
article, but instead it's being put at the beginning below the
heading.  I would personally be very reluctant to use <footer> near
the top of an element.

You either need a new element, or you need to declare that the current
<footer> semantics aren't actually valuable enough to capture.  What
you can't do is merely widen <footer>'s semantics, because that leaves
it still very asymmetrical with regards to <header>.

>> 2.<aside>  is similarly badly named.  The name itself and the
>> description of it as "sidebar" content apparently leads almost
>> everyone astray into thinking it's for the ubiquitous website sidebar.
>>  An informal survey showed that at least 3 people in that chat (me
>> included) immediately tried to misuse<aside>  in *precisely* this way
>> when we first heard of it, and when I discussed the issue with another
>> friend mid-chat his response was roughly "what's confusing about them?
>>  footer is for site footer and aside is for side panels".
> That is in fact correct.  One of the uses for aside is for the side bars.
>  In fact, <sidebar> was one of the names considered for the element when it
> was first discussed, and it's inclusion was based on the widespread use of
> class="sidebar".  In hindsight, we probably should have just called it that,
> but IIRC, the name was felt to be too presentational and so we went with
> aside, and extended it's purpose to both sidebars and the more generic forms
> of tangentially related sections.

This too doesn't feel right.  If <aside> is being used for a sidebar,
I'm not sure I feel right about using it for a pullquote that
stretches across my whole content column (differentiated from the
surrounding content by a border and a different font to make it clear
it's not meant to be read sequentially with the preceding and
following text).  It's no longer on the side.  It is still an "aside",
sure, but if I'm using this for sidebars too it feels like the "side"
part is being emphasized much more.

If the intent of the structural elements was to capture common class
names to make it easier and more obvious to author documents, then
<aside> is a failure if applied to both sidebars and
pullquotes/tangents/subtext/etc. (for the same reason that <footer> is
a failure if used for both "stuff that goes at the bottom of the
section" and "info about this article").  I don't believe that authors
use the same classes for both of these.  I'll end up still classing my
<aside> so I can tell apart the two cases, since they may both be
direct children of the article.


Received on Tuesday, 1 September 2009 21:46:05 UTC