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 <[email protected]> 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
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
--
TAMURA Kent
Software Engineer, Google
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
