Idea: offer multiple ways for injecting widgets, like an `HTMLElement` subclass or an `element-name`?

[JulianCataldo]

This lib should be agnostic. Actually a lit html (TemplateResult<1>) is preferred because it makes it easier to deal with accessibility issues with vendor custom elements that associate in the same form, as soon as they share the same DOM sub-tree.

However, passing a "true", well scoped custom element should be offered as a way to provide to the JSFE API.

• When using createRenderRoot with light dom with a LitElement.
• When using a vanilla HTMLElement with a this.innerHTML.
• When the user is aware of cross DOM-tree concerns and know how to deal with them (FACE, custom internals and other specs I'm not familiar with yet).

That raise a couple of issues, especially on the initial props. definition phase. With a template factory function, it's simple to type and to require props.
But with the custom element, it's up to the user to enforce props. to be defined on first init with defensive assertion and a template fallback.

Also, is it preferable to use a subclass of an HTMLElement or doing document.createElement('user-provided-element')?

[JulianCataldo]

I think using slots is the path forward. Currently experimenting with them, and it will make the library framework agnostic regarding widget creation.
That would require some kind of external store, though. Probably backed by TC39 signals.