[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 #7 from Daniel Buchner <danieljb2@gmail.com> ---
For the identification and parsing of Custom Elements I strongly favor the use
of tag names vs an attribute, such as is="", for the following reasons:

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.

2) To use an attribute to signify the prototypical identity of an element is an
unexpected inference laced with vagary, it introduces a whole host of other
problems, as 3, 4, and 5 will highlight in detail.

3) Developers assume attribute values to be mutable, and that they have an
effect when changed. Though you may be able to cite one-off cases where this is
not the case, the common paradigm developers are used to would make this
instance of a secretly locked, immutable attribute value, arguably one of the
most convoluted APIs ever produced.

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.

5) What happens when a developer uses removeAttribute() understandably
believing removal of the is="" attribute restores the target element's
prototype to whatever tag it was applied to? No other attribute I am aware of
leaves such a strong, secretive, lasting effect on an element.

To mitigate semantic concerns of some who favor the is="" attribute, I would
point developers at role="" for accessibility and semantic expression.
Additionally, the Custom Element API already has the extend concept baked in,
which allows custom tags to inherit the prototypes of existing, semantic
elements.

Using an attribute for this would be an ***extremely poor API choice***. It
opens the door to countless gotchas and landmines developers will never expect.
Honestly, after taking stock of the pros/cons at play in this decision, I don't
see how anyone would think using an attribute for this purpose is a good idea.

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

Received on Sunday, 16 December 2012 22:49:40 UTC