[webkit-dev] Implementation thoughts on HTML5 elements

Wed Aug 26 00:04:05 PDT 2009

These are unnecessary features wrt accessiblity tools and search 
engines; data mining techniques can easily handle them already. More 
strongly, for legacy and advanced UI reasons, the data mining should 
happen anyways, further questioning their merit. That's been my 
experience in this area (from the analysis side). Features that provide 
actual functionality would seem more pressing.

- Leo

Maciej Stachowiak wrote:
>
> On Aug 25, 2009, at 11:21 PM, Maciej Stachowiak wrote:
>
>> Hi everyone,
>>
>> Recently at Apple we've been considering our plans to implement new 
>> HTML elements from HTML5. I'd like to share our thoughts with the 
>> WebKit community and see if we are in sync before passing this on to 
>> the HTML Working Group. Does anyone have thoughts to add to the below:
>>
>> ----------
>
> I realized I forgot to cover <command> and <menu>.
>
> - <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.
>
> - <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.
>
>>
>> - 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.
>>
>> - <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, though, so that we're not the blocker.
>>
>> - New media elements: <audio>, <video>
>>   We love these and have them implemented. We don't see any 
>> implementation issues in the current spec.
>>
>> - <canvas>
>>    We like this and we have it implemented. We don't see any 
>> 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.
>>
>> - <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. Google 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?
>>
>>
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org <mailto:webkit-dev at lists.webkit.org>
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>   