[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 #15 from Ian 'Hixie' Hickson <ian@hixie.ch> ---
(In reply to comment #9)
> 
> 1) What prevents the developer, or would even dissuade them, from using
> normal, semantic elements *inside* their components?

Generally speaking, I wouldn't expect there to _be_ semantics that make sense
inside a component. Consider for example if the author is making a telephone
text field where as you type it fills the template in (something done a lot
these days with hacky JavaScript and underscores, in a rather painful fashion).
What semantics would you expect to see inside the component? It's all pixels at
that point. (Which is fine.) The semantic is "this is a text field", and that's
at the level of the whole component, not the insides.

Don't forget that sometimes the component won't be used. Just like how JS is
sometimes disabled, and CSS sometimes not used, components will sometimes not
be used. Whether this is because it's a legacy UA, or a simple spider, or an
accessibility tool that only looks at the outer DOM — HTML should still work.


> 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?

I'm not especially concerned about people making new widgets to replace <nav>.
Such widgets would almost certainly just be presentational things and should be
bound via CSS anyway, it's a non-issue.

It's the components that introduce widget variants, and so forth, that I'm more
worried about. There's no "role" that defines an <input type=text>. <input
type=text> has all kinds of complicated behaviours like caret placement,
spelling checking, form submission, etc, which a component will need to provide
but which a <div> does not provide.


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

role="" is not magic fairy dust that makes everything work. It's a very coarse
mechanism to label elements with how they should be reported in screen readers,
essentially; it doesn't _do_ anything. Just because you mark something as a
checkbox with role="" doesn't mean it's an accessible checkbox. You still have
to implement all the key handling and form submission and mouse handling and so
on.


> 4) Why are you assuming the browser will act on <nav is="x-supernav"> as if
> it hails from the nav element's prototype?

I don't think I do assume that.


> 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...

Not sure what you mean here.


> > (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.

I'm not saying it's crucial. I'm just saying that the video doesn't support the
point that it was cited to support in the comments above.


> 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

That doesn't achieve the Web Components requirements as far as I can tell (e.g.
the node changes identity).


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

Not sure what you mean.


> 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.

I've proposed an alternative to an attribute.

I don't mind what the syntax is. My desire is just that Web Components layer on
top of HTML semantics rather than being a sibling in the architectural cake.

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

Received on Sunday, 30 December 2012 18:52:39 UTC