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

I'm still wondering whether there really is a holy grail problem to be solved by inheritance though.  I think that something like:

`customElements.define('my-row', class implements [{...}, {...}, imported_custom_behavior])` might be more approriate.  The various behaviors / features should be easy to polyfill.

In order for the browser to know that `<my-row>` is a `<tr>` so that it can fall back to it, it has to be aware of and process the javascript 'manifest' for that element.  The fallback 'driver' might be the wrong goal here and IIUC that is what @rniwa objection was in the first place.  Once something falls back, it can no longer participate in the type of communication that custom elements perform.  

For example if a user clicks a `<magic-button>` that is supposed to, among other things, sort a `<sortable-table>`, but all of that communication is broken because these two components fell back then it seems the  entire user experience is broken, so should we really be driving towards an API that allows us to fallback?  At the very least there should be a holy grail scenario that is solved by this.

So one user experience / developer story concern is that driving towards being able to fallback has the potential for disastrous quality issues.  The other concern is modifier attributes.  For example `<magic-button small>`, should be a small magic button.  If that falls back does it somehow turn into a small `<button>`?  It's possible to expend a massive amount of effort on this stuff, but are we really getting something valuable in the end?

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

Received on Wednesday, 8 March 2017 18:43:53 UTC