W3C home > Mailing lists > Public > public-html@w3.org > September 2009

Re: Implementor feedback on new elements in HTML5

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 1 Sep 2009 09:43:06 -0500
Message-ID: <dd0fbad0909010743s4fc73a1dje5249ee6edb3740b@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: HTMLWG WG <public-html@w3.org>
On Mon, Aug 31, 2009 at 11:46 PM, Maciej Stachowiak<mjs@apple.com> wrote:
> - Sectioning elements: <section>, <article>, <aside>, <hgroup>, <header>,
> <footer>, <nav>
>   These seem useful - they give a way to represent the semantics of many Web
> pages nicely, and could work well with accessibility features for navigating
> around the page, as well as other clever ways of processing Web content.
> They are also trivial to implement (I already did <nav>). We're fairly
> interested in doing the rest of these. There was some concern expressed that
> these were less valuable than elements that actually "do something".

We had a big discussion about these yesterday on #whatwg while
explaining the semantics of these elements to someone new.
Surprisingly, we all seemed to agree on a few salient points:

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.  I think it's probably
common enough to fall on the "new element" side of the cut-off.
However, the name is just a no-go.  It will *constantly* be confusing
from both ends - tons of people will see "footer" and think "stuff I
put at the end of the section" (a perfect parallel to <header>) and
violate the content model with "fat footers" and such, while from the
other side people will put their article metainfo at the top of the
article (just below the heading is common) and feel reluctant to use
<footer> since it's at the top.

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.

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".  So, like
<footer>, this element is going to be a never-ending headache as
authors who don't read specs (that is, 99.9% of them) use it in a way
that "feels" right based on the name, but violates the intended
semantics.

I also recommend renaming this element, but I'm not sure what would be
an appropriate name.  <rel>?  <tangent>?  I'm sure this has been gone
over multiple times, but the name <aside> is simply *not* acceptable
under the principle of least surprise.  If kept as it is it *will* be
misused.

> - <time>
>   It seems useful for use cases like Microformats to have a clean,
> unambiguous way to represent a specific time. It seems odd that there are
> ways to get Date objects to represent the date, time and time zone
> separately, but no way to get a Date representing the combination of
> date/time/timezone. Wouldn't the latter be a common use case, and doesn't
> the JavaScript Date object give sufficient APIs to unpack a Date into its
> components as needed?

Wow, I didn't notice that until just now.  That sort of sucks.

I'm using <time> right now in my applications, and just parsing the
@datetime into a Date directly.  I definitely use it as a full
date+time.

The Javascript Date object kind of sucks (I've been forced to
basically rewrite its entire interface into something that actually
matches javascript style for *multiple* projects), but yeah, the tools
are definitely there to unpack a full datetime into a date or time as
appropriate fairly easily.

> - New interactive controls: <meter>, <progress>
>   These elements seem useful and a good idea. These controls are useful in
> native UI and often get hand-rolled by JavaScript libraries. We would like
> to expose a default native look, but with full author stylability for these.
> The only odd requirement is the use of inline text content in the elements
> to represent the state of the control. Specifying inline textContent may be
> a clever way to pass the initial state, but it seems very clunk as an
> interface for dynamically updating the state of the progress bar. Using the
> max and value IDL attributes of <progress> seems like it would be much
> easier for authors, and it seems like a problem that these only reflect the
> markup attributes and not the full state of the control (if the state is
> currently defined by text content). Likewise for the 6 attributes on
> <meter>. Assembling up to 6 numbers into a textContent string, which then
> does not cause the convenient DOM attributes to update, seems very clinky.

Possible idea: if some of the attributes were missing, thus requiring
the algorithm for extracting numbers from a string to be run, could
the textContent then be dynamically updated whenever the IDL
attributes are changed?  The basic idea is that if you're setting up a
correspondence between the attributes and the textContent, they should
achieve a complete coupling.

> - new <input> element types
>   These seem generally useful, and we already have some implemented to
> various extents (search, range, email, url tel). The only concern is the
> sheer number of date and time controls. 6 of the 13 new input types are for
> dates or times. Are there real use cases for all 6? Do all 6 exhaustively
> cover the types of time and date input you may want to do in forms? Two
> further points came up in the discussion here:
>     (a) Is it problematic to implement these without a lot of specialized
> UI, for cases such as "email" or "tel"?

I think it's fine for simple types like email and tel to have little
or even no UI outside of the error reporting.

~TJ
Received on Tuesday, 1 September 2009 14:44:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:47 GMT