Re: Minimum viable custom elements

> On Feb 4, 2015, at 7:59 AM, Domenic Denicola <d@domenic.me> wrote:
> 
> In IRC Anne and I were briefly discussing how type="" is the is="" of Web Applications 1.0. That is, <input type="date"> is similar to <img is="x-gif"> or similar---it has a reasonable fallback behavior, but in reality it is a completely different control than the local name indicates.
> 
> For <input type> this is accomplished with an ever-growing base class with an internal mode switch that makes its various properties/methods meaningful, whereas for is="" you get a tidier inheritance hierarchy with the applicable properties and methods confined to the specific element and not impacting all others with the same local name. I.e., is="" is type="" done right.

While disallowing the type of an element to be changed after the fact as done in "is" attribute is a step forward, it's not the only problem "type" attribute poses.  The biggest problem with "type" attribute is not that it shares the same interface across all types but that it violates the fundamental design principle of SGML/XML languages: the name of an element uniquely identifies its semantics.

> The fact that type="" exists and doesn't fit with the is="" paradigm is unfortunate. But I don't think we'd be better off trying to somehow generalize the type="" paradigm, or pretend it is any good.

I agree "type" attribute is bad but that doesn't make "is" attribute any better.

> What is our advice to authors, then---they should modify HTMLImgElement.prototype with x-gif-related properties and methods, that only work if type="x-gif" is present? That seems to be the road that this thread is heading down.

This is precisely why we shouldn't be introducing "is" attribute.  Changing the interface of an element based on a pretense of an attribute is extremely weird.  That's like a class changing its concrete class at runtime based on the value of its member variable.

> You could imagine plans to try to rationalize type="" on top of is="" (or, perhaps better, deprecate <input type=""> in favor of <control is=""> or something). But those seem pretty speculative.

"is" can't rationalize "type" because Web compatibility requires that authors can change "type" at any time.

- R. Niwa

Received on Wednesday, 4 February 2015 16:43:26 UTC