[webkit-dev] Implementation thoughts on HTML5 elements

[TAMURA, Kent]

I made a master bug of HTML5, like HTML5 Forms already has.

[Bug 32934] Master bug of HTML5 features
https://bugs.webkit.org/show_bug.cgi?id=32934


On Wed, Aug 26, 2009 at 15:21, Maciej Stachowiak <mjs at apple.com> 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:

> ----------

> - 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
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev




-- 
TAMURA Kent
Software Engineer, Google



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091226/ca4318ed/attachment.html>