[webkit-dev] Implementation thoughts on HTML5 elements
tkent at chromium.org
Fri Dec 25 09:39:49 PST 2009
I made a master bug of HTML5, like HTML5 Forms already has.
[Bug 32934] Master bug of HTML5 features
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
> - Elements requiring changes to <legend> parsing: <figure>, <details>
> These elements seem quite useful, but they will be unusable on the
> Web until all browsers are updated to change how they parse <legend> and
> 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>
> 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
> are hesitant to implement the new elements until either the <legend>
> issue is widely fixed or HTML5 uses some element other than <legend> for
> 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
> 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>
> 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
> components as needed?
> - New interactive controls: <meter>, <progress>
> These elements seem useful and a good idea. These controls are useful in
> to expose a default native look, but with full author stylability for
> 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
> 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
> 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
> 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
> do true combo boxes, including ones with a dynamic source of filled-in
> - <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
> 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
Software Engineer, Google
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev