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

> @trusktr However, how would that work when loading in a browser without custom-elements support, say elinks?

Browsers just need to be updated. You can detect user agent and send different HTML. You can send basic HTML and replace it with custom elements if API is available. People do this now with mobile vs desktop vs no-js. Single page apps won't even work without JS, and most people today making new apps want to make single page apps.

I think it is better to fix inheritance first (all native element classes map to exactly one native element name, then custom elements can extend from those native classes to inherit native behavior properly), then after that I can imagine a better is="" design if vendors decide to support fallbacks (f.e. elinks). But let's fix the first problem first, and let's not rely on is="" for what should simply work with inheritance (input, tr, quote elements, etc). I do see that is="" can be good for fallback cases, but the current way that inheritance works with is="" is ugly. Basically, I feel that is="" was made to solve inheritance problems, not for fallback. Let's move inheritance stuff to JS, then we can add a completely new and better-designed is="" that doesn't have to do at all with inheritance and who's purpose is strictly for fallbacks. I would support is="" if it was strictly for the fallback purpose, but currently it is designed for inheritance purposes (read [this](https://w3c.github.io/webcomponents/spec/custom/#custom-elements-customized-builtin-example), [this](https://developer.mozilla.org/en-US/docs/Web/Web_Components/Custom_Elements), and [this](http://goo.gl/YrsddY)) and some people happen to have noticed its potential for fallbacks.

Let's fix inheritance, then possibly as is="" under a whole new light.

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