[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 #18 from Scott Miles <sjmiles@chromium.org> ---
I land in the same place that Daniel does, but I'm hoping there is a middle
ground.

I understand the need to allow for common semantic information, but ultimately
I believe the syntactical cruft of 'is' attribute or '<input/x-fancy>' is too
much to bear.

A simple argument is that only a small fraction of custom elements will
actually match any standard semantics. The majority will extend either 'div' or
'span'. A look at any major website will reveal how much <div class='xxx'> is
in use today. This may be considered a flaw, but custom elements is not the
right place to solve it.

It seems worth noting that there is confusion in the discussion about the
nature of 'semantic'. I believe the argument is about machine-readable
semantics. IOW, how can a user-agent do things like auto-filling forms if the
form elements are custom? This is not the same as developer or human-readable
semantics, which tend to argue the other way (i.e. a human will understand what
x-slideshow means). 

As I mentioned I expect the majority of custom elements will not extend
highly-semantic elements. Extending structural elements like <section> or
<article> doesn't make a great deal of sense. Extending <input> or <select> per
se is also impractical, although custom elements may commonly facade the APIs
of those elements, which is a gray area.

Would it be possible to invert the problem? Instead of saying all custom
elements must have a standard tag name with attached customization info, could
we instead allow optional semantic markers? For example with an 'as' attribute,
<x-fancy-input as='input'>? Maybe this is a big conceptual change, but this
kind of solution at least would put the work where it's needed.

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

Received on Wednesday, 2 January 2013 19:00:00 UTC