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

@WebReflection there's a lot here, it's tough to respond to so much in a concise way so I'll try to ask questions/make comments in a sensible manner.

To the best of my understanding, it was agreed to postpone form of extension to v2 because the issues raised were pretty myriad and after literally years of discussion there wasn't headway on getting agreement that enough of them were solved.  On the other hand, there was much closer agreement on things that *could* get into v1 within a reasonable time frame and move efforts forward making a whole bunch of new things possible.  There are also corresponding efforts in other areas which potentially change the inputs to the discussion about how to solve bits of it.  I honestly don't know that anyone has or is willing to take a really hard dive into *all* of the notes from emails/ml threads/discourse/tweets/etc and document them - I know a few efforts were made, but they all seem incomplete to me.  In any case, the point is that when you say it's "in danger" it's not like everyone has given up on it completely.  Note also that anything that you've done to-date could still effecti
 vely con
 tinue to work with minimal tweak because you have an emulation that you feel is reasonable.

More specifically to your points/examples - they seem actually quite different to me.. It's hard to discuss this without knowing what you would do if you had shadow dom on your side, but I'll try:  In the leaflet map example you say "this image is a map" - but it's actually only briefly an image, the image is actually destroyed and replaced with an x-map which is no longer an image.  ATs don't understand it as an image, but it will be understood in terms of the x-map which is a composed thing full of native elements.   Further, the APIs for images don't automatically make sense (how would this deal with alt, sizes, src-set, how would CSS deal with heights, etc, the events don't map and so on - images don't have children but x-map does...plus you have to understand both states for querying and styling and so on).  So what you've solved nicely there is progressive enhancement I think - but the wrapper could do that as well without the distortions of claiming to be something it 
 isn't - 
 instead it could decorate input or fallback.  All of these (I think) represent _some_ of the common questions/solutions raised with is on most elements (especially some of the most common ones like buttons and inputs).

If I'm being honest, I don't think this is as strong a case as your tables one - or infact - anything which requires a special context.  Here's why that one doesn't particularly bother me so much though - If you put a <td>foo</td> (or several other tags) in the body of a page, it'll parse to plain text.  If you create one with createelement you can append it in weird places sometimes, but it won't work.  In some cases, fixups happen, in some cases, not.  The same limitations hold/affect on innerHTML, document fragments and so on.   These elements are weird and without some way to tap into the parser it seems to me they'd always have the kind of problems like above (that's not something special to custom elements, it applies to regular html as well).  FWIW though, in your final example it does seem to me you could use the wrapper approach there as well with a little more indirection - effectively decorate to bestow upon a standard table that any standard row becomes a super-ro
 w.  Yes,
  it's imperfect, but it's imperfect in a not-actually-different-than-the-existing-platform kind of way that (I think) everyone hopes to solve better in the future.

Still, if there were agreement that this is especially a problem for contextual element - I wonder if it is possible to consider some way to solve this much more focused problem in a simpler way fairly early?





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