[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 #9 from Daniel Buchner <danieljb2@gmail.com> ---
(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.

1) What prevents the developer, or would even dissuade them, from using normal,
semantic elements *inside* their components?

2) The whole accessibility/browser/search engine issue being raised seems like
a boogieman --> Is role="navigation" not just as capable of expressing to
browsers, search engines, etc. these associations?

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

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, that
extend flow happens in the <element> declaration - so again, how is this a
concern when you have role=""?

5) If you are assuming that we should allow is="" to, by simple addition to the
element and magical inference, merge or inherit the custom element's defined
prototype, what happens when a developer sees that it is an attribute and
thinks they can throw it on any element they choose? I see a whole fun
Pandora's Box of unexpected behavior and bugs just lying in wait there...

> (Note that in the video above, the presenter says she wants to be able to
> change the binding live. She calls it "absolutely crucial". :-) )

What she doesn't realize, is that it isn't really "absolutely" crucial, and
even if it was, it doesn't mean we need to make this an attribute to do so.
There are other options (that are arguably more intuitive) to accomplish custom
element switching in a true custom tag world, here are a couple:

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

2) The developer can create the other type of custom element they want to
switch to, and drop the child elements into it.

I'd love to get some feedback to these possible solutions and questions,
because *every single developer* I've talked to (and we've gotten a *lot* of
feedback) have balked at the attribute route. I've heard it called: "unicorn
magic", "opaque", "massive inference", "a View Source headache" etc - and if we
don't have to go that route then I would strongly advise we avoid doing so.

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

Received on Wednesday, 19 December 2012 02:25:11 UTC