[webkit-dev] Implementation thoughts on HTML5 elements

Wed Aug 26 00:21:17 PDT 2009

Likely the ones you considered "trivial". E.g., "nav".

- Leo

Maciej Stachowiak wrote:
>
> On Aug 26, 2009, at 12:04 AM, Leo Meyerovich wrote:
>
>> 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.
>
> Can you please clarify what features you have in mind? Most of the new 
> elements I mentioned do provide substantive functionality.
>
> Regards,
> Maciej
>
>>
>> - 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
>>>
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>