RE: Minimum viable custom elements

I hope others can address the question of why custom element callbacks are useful, and meet the bar of being a feature we should add to the web platform (with all the UA-coordination that requires). I just wanted to interject into this <input> discussion.

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.

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

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.

Received on Wednesday, 4 February 2015 16:00:22 UTC