Feature request: support extending native elements with controller decorator

[HipsterBrown]

First off, I'm really enjoying this library, so thanks for sharing it! It's been a great transition into custom elements from Stimulus development.

In some recent work, I wanted to extend a native element, HTMLAnchorElement in this case, when building my catalyst-controlled custom element. I ran into a roadblock when using the @controller decorator because it doesn't have a way to specify the extends option.

This could be done manually by the author:

@controller({ extends: 'a' })
class CustomLinkElement extends HTMLAnchorElement {
}

Or inferred by the library code when defining the element:

const ElementMap = {
  'HTMLAnchorElement': 'a',
 ...etc
};

// register.ts
let extends = ElementMap[Object.getPrototypeOf(classObject).name];
window.customElements.define(name, classObject, { extends });

I like the ability extend native elements in order to limit the extraneous markup to add functionality, but I understand if this feels out of scope for a stimulus-type replacement.

[koddsson]

I understand if this feels out of scope for a stimulus-type replacement.

It's probably not strictly out of scope, but we have some we don't extend any built-in elements in our codebases for a few reasons that are documented in this eslint rule. The takeaways are:

• As new features get added to HTML elements, custom elements that extend those built-in elements need to adopt those new features which can cause complications especially with regards to cross-browser support.
• Safari doesn't support and doesn't plan on supporting extending from other elements than HTMLElement.
  The is="" attribute is confusing? Maybe we should encourage only ES6 class-based extension. WICG/webcomponents#509 (comment)

For those reasons, I don't see us adding support for extending built-in elements at this time.

[HipsterBrown]

@koddsson Thanks for the explanation. I wasn't aware of the Safari support issue. 👍