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

@oleersoy the `is="enriched-element"` has different use cases than `<custom-element>`. If you want to have exactly same native behaviour and extend it on top, you need the `is` attribute through the builtins extend way. **There are no valid and universally compatible alternatives** to this approach, so it's a matter of _when_ rather than _if_ these are needed.

`template`, `th`, `tr`, `body`, `head`, `html` are just few examples where you simply cannot use a custom tag with same/needed element inside because the result would be breaking for the surrounding HTML or the page itself.

`a`, `button`, `input`, `iframe`, `form` are, on the other hand, things well handled and known by browsers and bring in a lot of things automatically. In these cases you can wrap these native builtins around through redundant, not needed, verbose HTML, or create them at runtime (and once) on `connectedCallback` losing completely graceful enhancement.

A `canvas-3d` could be created with both approaches, but if you put a `canvas` inside a `canvas-3d` you are still in redundant-land but it's not such big deal since `canvas` is not much accessible 
anyway. Everything else with builtins special meanings **is** problematic to reimplement.

Last, but not least, if you have a custom element that doesn't need to extend any special functionality beside what `HTMLElement` provides already, you'd go with the regular extend through the tag name and basic definition.

Most of the time, that's all you need but as you can see, developers can, and will, use Custom Elements in various ways.

I hope I've clarified most common use cases.



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