Implementor feedback on new elements in HTML5

The following feedback is strictly with my chair hat off. In this  
message I'm trying to represent the views of Apple and also the  
broader WebKit community.

Recently at Apple we've been considering our plans to implement new  
HTML elements from HTML5, and have some comments on the new elements.  
We've also shared these comments with the WebKit community[1] and have  
updated our feedback accordingly.

----------

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

- <dialog> element
   This essentially gives the same behavior as <dl> but with  
appropriate semantics for logs of conversations. It seems useful and  
easy to implement.

- Elements requiring changes to <legend> parsing: <figure>, <details>
   These elements seem quite useful, but they will be unusable on the  
public Web until all browsers are updated to change how they parse  
<legend> and the new versions are widely adopted. Pretty much all  
current browsers do something idiosyncratic when parsing a <legend>  
element outside of a <fieldset>, which makes it impossible to make  
<figure> or <details> degrade gracefully via script or style. We are  
hesitant to implement elements that authors would feel they are unable  
to use, or to lead authors astray, so we are hesitant to implement the  
new elements until either the <legend> parsing issue is widely fixed  
or HTML5 uses some element other than <legend> for the caption on  
these elements. We will consider fixing our parsing of <legend>  
outside <fieldset> soon, so that we're not the blocker. But it seems  
like it would be easier to change the elements that carry the label/ 
caption.

- New media elements: <audio>, <video>
   We love these and have them implemented. We don't see any major  
implementation issues in the current spec.

- <canvas>
    We like this and we have it implemented. We don't see any major  
implementation issues in the current spec.

- Newly standard legacy elements: <keygen>, <embed>
   We had these for a long time before they were in HTML5. It seems  
like a good idea to cover them in the spec, even though they are kind  
of crufty.

- <mark>
   The basic idea for this element seems good, but the suggested UI  
for exposing it does not seem to entirely match the use cases, and may  
not be practical to deploy. Having tick marks in the scrollbar for  
every <mark>, and UI to cycle between them, seems too heavyweight for  
some of the suggested uses. We are interested in implementing the  
basics of <mark> soon, but probably not the requirements.

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

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

- Ruby elements: <ruby>, <rp>, <rt>
   We think these are useful. Chromium engineers are actively working  
on the WebKit implementation and some initial patches have landed.

- <datalist>
   Work on this is in progress. We think it is a good idea to offer a  
way to do true combo boxes, including ones with a dynamic source of  
filled-in values.

- <output>
   This seems relatively simple to implement and worth implementing.

- 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"?
     (b) For the various date controls, our primary concern is whether  
they map well to the important use cases. The people working on  
implementation do not think there is much incremental cost to each  
additional date control, once the basics are implemented.

- <menu>
   The list form of a menu seems straightforward enough, it is good to  
have a list type specifically for popup menus. The toolbar form does  
not seem fully baked. First, it seems weird to think of a toolbar as a  
kind of menu. Second, the rendering is too inflexible and  
underspecified for the real Web content authoring use cases for  
toolbars. And finally, an important point of toolbars in many  
applications is that they can embed custom controls in a flexible  
layout that also includes some standard buttons, but <menu  
type="toolbar"> does not seem flexible enough to handle this. The  
context menu form does seem genuinely useful. But it also seems like a  
lot of complexity for the somewhat marginal case of overriding the  
context menu. It seems like about a dozen different elements are  
allowed, all with different processing requirements. This seems like  
overkill for the use case of a context menu. It doesn't even make much  
semantic sense for a context menu to contain a button. Overall, it  
doesn't seem like the cases of menu list, toolbar and context menu  
really share enough behavior or appropriate content model to make them  
use the same element.

Overall, there was a lot of sentiment that Web developers need better  
built-in support for toolbars, context menus, and list-based hover  
menus. However, we were not comfortable with the complexity or the  
limitations of the design.

We're looking into whether we can propose some improvements in the  
near future.

- <command>
   It's unclear if this element is worth having without the use cases  
for toolbars or menus, and it also has 0 implementations so far and  
seems like it might not be fully baked.


Regards,
Maciej

[1] https://lists.webkit.org/pipermail/webkit-dev/2009-August/009583.html