On 10/10/2011 4:55 PM, Erik Arvidsson wrote:
Splitting this up into two different things is great.
Allowing attaching an alternative shadow tree through CSS but
disabling any JS to be run seems like the right thing to do.
I'm also in favor of the "is" attribute. Even though I think that
<x-foo> is more readable than<div is="foo"> it is hard to argue about
the issues regarding parsing and fallback behavior. The "is" attribute
also provides a better behavior for common cases such as when you want
to extend<select> and<button>.
erik
This seems to be the same tact that ARIA 1.0 went with to describe new
attributes.
I'd like to know what your definition of the word "is" is.
Will I be writing the following:
<div is="button" role="button">
Will it be shorter:
<div is="button">
If it's shorter, it seems my shadow tree should have role="button" on
the appropriate element.
Is that conducive to your definition of "is"?
As far as I can tell, the "is" operates well with ARIA; if the author
has their own roles, they can specify them within the shadow dom,
otherwise, the role is borrowed from the element.
If "is" is adopted, it seems relevant to include a specific mapping
between "is" and "role" for ARIA consumers.
I'd like to see "is" as an attribute that applies to other families
supported by HTML5: SVG may benefit.
That is, it may be a deserving first-class attribute. It seems to
signify that the shadow dom is supported, just as role signifies that
ARIA is supported, and "id" works with the ever-handy DOM getElementById.
-Charles
