[Bug 18669] Switch from is= to <tag if a decision has been reached among implementers

https://www.w3.org/Bugs/Public/show_bug.cgi?id=18669

--- Comment #23 from Henri Sivonen <hsivonen@iki.fi> ---
(In reply to comment #0)
> It would appear a consensus of at least two implementing groups have agreed
> that it will be custom elements (tags, not attributes).

Who are the two groups?

(In reply to comment #7)
> 1) In terms of developer ergonomics, for both conceptual understanding and
> in practical use, it is much easier to deal with and "x-modal" tag vs a
> random tag with is="x-modal" applied.

Note that if is="" is used, there is no need for the x-. You could just say
is="modal".

As far as conceptual understanding goes, developers already need to understand
<input type="foo">.

> 4) Developers worth their salt will assume prototypical inheritance from the
> tag on which the is="" attribute is applied - this is a head-fake for
> developers. The extends linkage is created in the Custom Element definition,
> and if we use attributes, a developer will be left to wonder what mix of
> prototype they are being dealing with.

So why wouldn't we make the custom element inherit from the element designated
by the tag name in terms of the APIs available?

> To mitigate semantic concerns of some who favor the is="" attribute, I would
> point developers at role="" for accessibility and semantic expression.

There is a crucial distinction: role="" is understood by the user agent while
the user agent has no clue of the semantics of is="".

(In reply to comment #8)
> I'd be fine with not using an attribute if we have some other solution. My
> concern is that people will abandon the use of semantic HTML in favour of
> Web components, in much the same way that they used <font> or <div
> style="">s. This hurts accessibility, it hurts search engines, it hurts
> maintainability, and it hurts backwards-compatibility (graceful
> degradation). I would like to avoid this by requiring that authors use
> regular HTML elements that they then _augment_ using Web components.

I have this concern, too, at least for document-oriented Web content. It's
unclear to me how much of a lost cause Gmail is. That is, if it is practical to
try to redeem Gmail from the land of <span role=button class=foo> to <input
type=button is=foo>.

> One way to do that is an is="" attribute on creation. Another is new syntax,
> e.g.:
> 
>    <select/map>
> 
> ...where "select" is the HTML semantic, and "map" is the component. (This
> would parse as <select map=""> in legacy UAs, but in new UAs we could make
> it something special that doesn't use attributes.)

I think we shouldn't go crazy with parser changes like that. (I'm generally
worried that people get too eager to change the parser these days.)

To point out just one problem with your proposal, the component part could
collide with an HTML built-in attribute in legacy browsers, and it would be in
elegant to rely on authors to avoid such collisions. To avoid collisions, you
could reintroduce the x- convention and write <select/x-map>. But once you go
there, you might as well write <select x-map> to get the same result in legacy
browsers. Once you get there, we might as well not make parser changes and are
back to using attributes—but using attribute names instead of values. <select
x-map> has at least slightly nicer to look at than <select is=map> and a lot
nicer than <select is="x-map">.

Additionally, even though XML is not fashionable right now, I think we should
avoid burning bridges with XML with gratuitous incompatibility on the DOM
level—in this case non-NCName element names. Let's not forget that we all also
implement XHTML and the rise of HTML5 has been made less scary to XML-minded
people by promoting the use of an HTML parser at the start of an XML pipeline.
And more important than making HTML less scary politically, leveraging XML
machinery for non-browser HTML processing makes a lot of technical sense.
(That's how Validator.nu works.) Let's not pulled the rug from under all that.

(In reply to comment #9)
> 1) What prevents the developer, or would even dissuade them, from using
> normal, semantic elements *inside* their components?

What's the expected accessibility exposure model for Web Components? Is the
component's (shadow?) tree supposed to be exposed to accessibility APIs are
not? (For XBL2, the answer was not, which might be affecting people's
presuppositions when discussing this.)

> 3) If a developer uses role="", how is graceful degradation affected?

If degradation is in the attribute, it's easier to leave the degradation out.

If you have <nav x-supernav> or <nav is=supernav>, you have to have some
elements name there, so you might as well use the right one.

If you have <x-supernav role=navigation>, it's much easier to forget or
optimize out the role part.

> 4) Why are you assuming the browser will act on <nav is="x-supernav"> as if
> it hails from the nav element's prototype? The generated custom element
> prototype does not inherit the prototype of the element that is="" is
> applied to

Why not?

> 1) We already have a document method perfect for this case:
> document.renameNode -
> http://www.w3.org/TR/DOM-Level-3-Core/core.html#Document3-renameNode

As Anne pointed out, we don't really have document.renameNode().

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 8 January 2013 08:45:12 UTC