Re: [w3c/webcomponents] The is="" attribute is confusing? Maybe we should encourage only ES6 class-based extension. (#509)

Oh, I misunderstood subclasses of native element subclasses to mean subclasses of user-defined subclasses. My mistake.


So I guess the answer to my (admittedly mostly rhetorical) questions really are "don't use custom elements". That's worse than I thought. In that case I'd like to rebut some of the points made by the anti-is side, from my point of view as a developer. 

> The `is=""` API can be confusing

I've never heard of anyone who found it confusing. The intent of it is clear. Besides, if we bikeshedded every confusing part of the web until everything was perfect we wouldn't have browsers at all.

> subclassing ... often leads to a violation of the Liskov substitution principle

Things breaking because of an update to a superclass's implementation happens is a fact of life. It should be avoided wherever possible, but eliminating subclassing altogether is not the answer. The possibility of a hypothetical input type being added is not worth throwing away all the possible custom input types developers could be making. Don't throw the baby out with the bathwater

> none of the builtin elements are designed to be subclassed

I can say from experience that whether they were designed for it or not, subclassing native elements works very well. While there may be limitations when extending inputs, for example, it's easy to work within those limitations.

> 
I don't get why people keep making claims that is= improves accessibility. It simply doesn't except the very simple scenario in which the entire UI of the builtin form control is preserved (e.g. just adding JS methods).

I think you're assuming that preserving the builtin UI isn't exactly what a lot of devs are doing. Look at Polymer's [iron-input](https://elements.polymer-project.org/elements/iron-input). No crazy shadow DOM stuff, just key bindings and a validator but that alone is very powerful. I've extended `HTMLInputElement` in my own applications to build things that are very complex, but thanks to custom elements I can just add `is="whatever-input"` to another input so they are also portable.

One might suggest that instead of extending native elements, we should create some kind of wrapper or bind events when the document loads or something, but custom elements v1 works with elements created with `document.createElement`, appended to another element as HTML, rendered as the HTML in the first request streams in, or any other way elements get created, without requiring any extra JS. If WebKit decides not to implement `is=`, thereby making progressively enhanced native elements impossible and forcing developers to write more code, people are just going to keep using the polyfill.

I'm just a lowly webdev so while I have opinions about the big-picture future-of-the-platform stuff I'll leave that to you folks. I hope you'll consider my perspective when implementing (or not implementing) the spec.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/509#issuecomment-256528988