Re: [w3c/webcomponents] Repurposing the is="" attribute to allow multiple behaviors to be attached to a given element (#662)

I really like the concept of such components, which are just adding functionality on top of existing elements, by plugging in into CEReactions, It would allow enhancing problematic native elements like `<tr>`, elements with specific parsing context `<template>`, and do more progressive enhancement.

-----
However speaking of details in encapsulation and conflicts resolution, I'm thinking about simpler and maybe more naive approach. 
I, as a developer, use Custom Elements to enrich the functionality of actual elements, not their properties (like `someElement.components.['audio-player']`). To react to element changes and manipulating a separated object, `addEventListener` and few additional Events should do the job. What I like the most about CE is that I work on the exact element, its properties, and attributes which are exposed as for any other native element. (For a `<button>` element you do `element.checkValidity()` not `element.button.checkValidity()` that's why I'd like to be able to do the same for `<tr is="foo-button">`)



Then to answer @rniwa 

> One major challenge there is defining which one wins when the two define conflicting behaviors and properties.

What if those components/mixins have access directly to the element instance, but the order of names in `is`  value matters? That will be ordered list of mixins, and CEReactions would be called in that order. Then it's the responsibility of the author that mixes many behaviors, to mix such ones and in such order, they would not collide.

If both mixins are defining a property setter with the same name, it will result in `TypeError` as it is in a regular case.
I would expect, some good practices would evolve around, for example, to check for existence of `.shadowRoot` before attaching one, or to prefix custom event names.


Even, if we limit ourselves to the case of only one component mixed by `is` to avoid collisions between mixins as described above, I believe the idea of enhancing the native element without actually extending its class, just by plugging into the CEReactions is worth keeping.

We would have "autonomous custom elements" that does `class MyElement extends HTMLElement {connectedCallback:/*...*/}`, and "custom element enhancements"  that  does just define `{connectedCallback:/*...*/}` which is plugged in via `is` (or other) attribute

The definition of such custom enhancement does not have to specify what it would extend, or it could be just an optional feature.

Then consistently we could have "enhanced autonomous custom element".

Like:
```html
<third-party-element is="my-enhancement">
```
```js
customElements.define('third-party-element', class ThirdPartyElm extends HTMLElement{connectedCallback:/*...*/});
// ...
customElements.defineEnhancement('my-enhancement', {connectedCallback:/*...*/});
```

-- 
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/662#issuecomment-327486953