Re: [webcomponents] [Custom Elements] the `extends` property cannot be replaced (#326)

I'd like to add more content/reasons/examples since I've had this conversation privately via email too.

I once demoed [an image with an src pointing to a static map](http://webreflection.github.io/document-register-element/test/examples/x-map.html).

That image was an `<img is="x-map">`, it was working on every browser available in planet earth by default, then for those browsers polyfilled via my [document-register-element](https://github.com/WebReflection/document-register-element), including IE8, the image was becoming a LeafLet map.

How would you style or search for an element that is a custom one?

In the image case `img[is=x-map], x-map` did a great job!

Was the image one of those cases where having `<x-map><img></x-map>` could have worked regardless?

Technically yes, practically why would we like an extra layer we don't even know how old quirky browsers could render by default (block? padding?)?
Why having indirection when registering 'x-map' as `'img'` extends is all it takes to have also a cleaner layout?

This img case without `extends` would be similarly cumbersome for `input`, `select`, `textarea`, `button` and all form elements and other nodes.

Do we really need an overblown DOM tree when we can simply register through the `extends` and address them  via `[is=x-thing]` ?

I think this would also be a very straight forward simplification:

  * we want our own full new thing? `prototype: HTMLNativeElement`
  * we want the previous one plus a native like appearance and behavior? `extends: 'native'`

Otherwise we need to also add listeners that inevitably have to bubble up, 'cause if we have an input component that doesn't directly trigger `input` events but only delegates, it also has to delegate back as well to the input, right?

But why would we like to increase complexity to create Custom Elements that could just work?

Back to my initial TR example, avoiding the usage of `innerHTML`, since that is not the real problem, check this example:

```html
<!DOCTYPE html>
<html>
  <head>
    <script>
    var XTR = document.registerElement('x-tr', {
      prototype: Object.create(HTMLTableRowElement.prototype)
    });
    </script>
  </head>
  <body>
    <table><x-tr><td>hello</td></x-tr></table>
  </body>
</html>
```
If above code would be everything I need in order to create tables with super-powered rows, there won't be any problem.

Unfortunately if we inspect the page layout ... this is what we are going to find there:

```
<!DOCTYPE html>
<html>
  <head>
    <script>
    var XTR = document.registerElement('x-tr', {
      prototype: Object.create(HTMLTableRowElement.prototype)
    });
    </script>
  </head>
  <body>
    <x-tr></x-tr> <!-- SEE THAT? THAT'S NOT WHAT WE WROTE! -->
    <table><tbody><tr><td>hello</td></tr></tbody></table>
</body></html>
```

In other words, the mechanism provided to create Custom Element completely destroyed a layout and its meant behavior. The app is doomed and nothing is even warning us about it.

Accordingly, the only way to make it work is using the alternative "need native-like behavior" formula based on `extends`. Following the tiny change full of win!

```html
<!DOCTYPE html>
<html>
  <head>
    <script>
    var XTR = document.registerElement('x-tr', {
      extends: 'tr',
      prototype: Object.create(HTMLTableRowElement.prototype)
    });
    </script>
  </head>
  <body>
    <table><tr is="x-tr"><td>hello</td></tr></table>
  </body>
</html>
```

Now we can use that row in every table we want, it will be compatible with years of styles and legacy based on tr and for modern browsers it will act like a super powered row.

How cool is that? And why shouldn't Custom Elements be this cool and powerful? Why would we like to limit them  instead of simply agreeing that if it's native like that's needed, then we need to use `extends` and if we want to be sure we select an expected component, `[is="x-name"],xname` is all we need to have it back either ways?

As summary, this is the reason I've filed this bug: AFAIK the `is` attribute is in danger, but I believe we are not really thinking through how many things will become impossible to achieve ... and I wonder for what counter-achievement ... one less attribute to check beside `class`, `id`, `style`, and others? Is that what is all this about or there is some problem I am not seeing? (if so please tell me more on `extends` and `is` side effects, thank you)

I hope now it's even cleaner what is the problem here, and why `extends` is the ideal solution.

Best Regards

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/326#issuecomment-142220244

Received on Tuesday, 22 September 2015 09:08:29 UTC