Re: HTML5 feedback from prominent designers

Shelley Powers wrote:
> Zeldman:
>
> http://www.zeldman.com/2009/08/31/loving-html5/

There was quite a lot of good feedback in that page, most of which I 
agree with.  I will just address a couple of points, though.

> Footer
>
> We are concerned that the footer element as defined is more
> restrictive than the header element. It violates the “Principle of
> least surprise”—people will see the footer element and “know what
> it’s about” use it for the footer of the page not footers of
> sections.
> ...
> A distribution of how deeply nested nodes are that contain the
> footer class/ID. Our hypothesis is that footer is much more
> frequently a very near child of the body element, which would
> indicate that content authors consider the footer to be a
> template-level element rather than a meta-data container for deeply
> nested sections.

The way header and footer are designed to be used, does allow for 
authors to use them in this way.  It's what it was largely designed for. 
  It was just made to apply to its section to give authors more 
flexibility with how they can use the elements, rather than attempting 
to restrict it to just being used in a way that only applied to the 
whole body.  I agree with the problems with its content model being too 
restrictive, and that should be fixed as described.

> hgroup
>
> We don’t see the added value of this element and would instead add a
> boolean attribute to the heading element which allows content authors
> to specify if that particular heading should be included in the
> outline.

I personally don't agree with the inclusion of this element.  It is a 
poorly conceived and completely unnecessary element designed to replace 
some of the functionality of header when it's definition was adjusted. 
However, this addition was entirely unnecessary, and its purpose can and 
still should be fulfilled by the header element, and the outline 
algorithm should be reverted so that the header element takes part in it 
like it did in an older draft.

The "Little Green Guys With Guns" example in the spec illustrating 
multiple headings within the header is not right.  The two h2's should 
not be within the header element, and should be separate, nested 
sections of their own.  It should be adjusted to the following (changed 
marked with "XXX"):

<body>
  <header>
   <h1>Little Green Guys With Guns</h1>
   <nav>
    <ul>
     <li><a href="/games">Games</a> |
     <li><a href="/forum">Forum</a> |
     <li><a href="/download">Download</a>
    </ul>
   </nav>
  </header> <!-- XXX End tag inserted here -->

  <h2>Important News</h2> <!-- this starts a second subsection -->
   <!-- this is part of the subsection entitled "Important News" -->
   <p>To play today's games you will need to update your client.</p>

  <h2>Games</h2> <!-- this starts a third subsection -->
  <!-- XXX </header> End tag removed from here -->
  <p>You have three active games:</p>
  <!-- this is still part of the subsection entitled "Games" -->
  ...

(It's would also be reasonable to include <section> elements around each 
of the subsections beginning with <h2>, but using implied sections is 
acceptable and often more convenient)

> 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.

> Figure
>
> We suggest that, by default, UAs render figure width no wider than
> the video, image, or canvas that it contains...

I agree with this.  One way to achieve this is to make the default 
styling for figure be:

figure { display: inline-block; }

I've also previously wrote some CSS using display: table; instead, which 
would give a similar result, but which had some nice benefits for the 
caption with the use of caption-side.  However, I think using 
inline-block is probably a better choice for default styling.

http://lists.w3.org/Archives/Public/public-html/2007Sep/0375.html

> Progress and Meter
>
> The only obvious difference in these two elements is that meter
> contains a start value. Are they perhaps different visual displays of
> the same information?

The easiest way to illustrate the difference is to think of how 
equivalent native controls are in applications on various platforms. 
For example, compare and contrast how the Progress Indictors and Level 
Indicators are used in Mac OS X.

Progress Indicators:
http://developer.apple.com/mac/library/documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGControls/XHIGControls.html#//apple_ref/doc/uid/TP30000359-TPXREF106

Level Indicators:
http://developer.apple.com/mac/library/documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGControls/XHIGControls.html#//apple_ref/doc/uid/TP30000359-DontLinkElementID_74

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

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