[webkit-dev] Implementation thoughts on HTML5 elements

Wed Aug 26 00:17:05 PDT 2009

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