[scoped-elements] align API more with CustomElementsRegistry proposal

As the use of the scoped-elements experiment is in full force in Lion (https://github.com/ing-bank/lion/pull/599), we see some developer questions/discussions about the use of classnames instead of tagnames. We also see that the CustomElementsRegistry proposal is getting an official explainer by Justin. (https://github.com/w3c/webcomponents/pull/865)

Here, I’d like to propose some changes to scoped-elements in order to align more to the “current” target.

• only allow scoped elements within shadow roots
• abstract away the use of the versioned tagnames by:
  • polyfilling the most used API’s: shadowRoot.querySelector, shadowRoot.querySelectorAll, styles (this could use the same algorithm as the template transformation)
  • adding support for the proposed shadowRoot.createElement(), shadowRoot.createElementNS(), shadowRoot.importNode()

The benefits I see from this:

• the use of tag name within code would be still allowed (no big refactors for users)
• migration to the new CustomElementsRegistry will be possible by only updating ScopedElementsMixin (when creating the shadowRoot, you’ll be able to pass the a CustomElementsRegistry object with the element’s scopedElements `)
• there might be some possibility to hide the usage of the ScopedElementsMixin in a build step (by analyzing the imports and rewriting them and creating a scopedElements property) Gut feeling says it might be error prone, though.

Let me know what you think: @manolakis, @LarsDenBakker, @daKmoR , @jorenbroekema

[LarsDenBakker]

Until scoped custom element registry becomes a web standard, I don’t think we should be going anywhere near anything resembling a polyfill. We’ve had too many bad experiences with that in the web component ecosystem. So overwriting built-in functions is definitely something I think we shouldn’t do.

The goal for scoped elements is to solve only the problem of using multiple versions of a web component on a page, in the lightest way possible with the most minimal impact on DX and performance. (it’s quite a DX improvement actually in my opinion).

Of course if we can align as much as possible to how it might eventually look like, that would be ideal. That way the transition will be easier. It’s also important that whatever we do, multiple implementations can coexist on the page. This way a migration away from scoped element doesn’t need to be a big bang.

I’m also hoping that if we get native support for scoped custom element registries, we would be able to use this under the hood in the scoped elements library. By keeping the library simple and focused, this should be possible.

Finally I think we should be clear in our documentation that the scoped elements project is not suitable for every kind of application, it should only be used when using multiple versions is a dealbreak for your project.

[stale[bot]]

Hey there, it’s me again! I am going close this issue to help our maintainers focus on the current development roadmap instead. If the issue mentioned is still a concern, please open a new ticket and mention this old one. Cheers and thanks for using Open Web Components!