On Aug 26, 2009, at 12:21 AM, Leo Meyerovich wrote:
Likely the ones you considered "trivial". E.g., "nav".
You should probably give that feedback to one of the lists for
feedback on the HTML5 spec ([email protected] or [email protected]).
I don't think accessibility tools use "data mining" to infer these
sections of the document. They might have heuristics based on class
name or ARIA role. But it seems better to let the author say <nav>
instead of <div class="nav">. The specific elements chosen were based
on a wide survey of the most common class names on the Web, and align
with ARIA landmark roles. So I don't entirely agree with your
feedback, but I think you should bring it up in the appropriate forum.
- Maciej
- 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
[email protected] <mailto:[email protected]>
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
------------------------------------------------------------------------
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
