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

@matthewrobb Registration was implied. I'm trying to not constrain myself by what browsers can currently do. We're discussing ideals, right?

The reason I propose this is that - other than limitations due to the way browsers may implement them - it makes zero sense to me why there's a double standard between built-ins and custom elements. There's no tangible benefit to this. At the end of the day, they're all just elements that have different levels of prototype chains stemming from the common `HTMLElement` constructor. They all follow the same core semantics, so why are there two different sets of rules for them?

My ideal would be taking the example from https://www.w3.org/TR/custom-elements/#custom-elements-customized-builtin-example:

```html
<script>
  class PlasticButton extends HTMLButtonElement {}
  customElements.define('plastic-button', PlasticButton, { extends: 'button' });
</script>
<button is="plastic-button">Click Me!</button>
```

And being able to do something like the following instead:

```html
<script>
  class PlasticButton extends HTMLButtonElement {}
  customElements.define('plastic-button', PlasticButton);
</script>
<plastic-button>Click Me!</plastic-button>
```

Though, it's not much more concise, that is secondary to consistency, predictability and extensibility, IMO. Ideally a browser would know that your plastic button derives from the built-in button and you get form participation and accessibility for free. If browsers fixed the q / blockquote deriving from the quote constructor issue (and possibly others), then we can get all the information we need from the super class.

I just thought I'd give my 2c in terms of ideals. Digressing, I get that ideals aren't reality and that we have to make compromises. I'd be more than happy using both `extends` and `is` if browser vendors could compromise here.

At the end of the day, we need to be able to do:

- Custom table rows, list items etc
- Custom elements that have inputs in shadow roots (currently they don't serialise on submit)
- Custom elements that have reset / submit buttons in shadow roots (currently they don't do anything)

Surely I've missed something, but these aren't just contrived use cases. Every single item in that list contributed to reasons we stopped using web components for our component library. At the end of the day, we just wanted a solution regardless of if it was ideal or not. It should add weight to this that I'm the author, and still a maintainer of, the second most popular web component library out there.

We need to look at the big picture here. If people can't do what they need to do with web components they're going to turn to something else, even if it's a divergent solution. Web components were introduced in 2011. At the time of this writing, that's six years ago. How much of this time has been spent arguing about `is`? In just this issue, that's 9 months developers have been without a solution to solve some of the more difficult use cases that they want a solution for.


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