Re: [w3c/webcomponents] [idea] Allow custom element naming on a per-shadow-root basis. (#488)

I've had a rough proposal for scoped custom element definitions that associated floating around the Polymer team for a little while, and I was just pinged that @Jamesernator had a very similar idea :)

I put my doc up in a gist: https://gist.github.com/justinfagnani/d67d5a5175ec220e1f3768ec67a056bc

I've floated it casually past a few browser implementers, and so far it seem like they don't see a critical show stopper in it. It would need a lot more scrutiny obviously.

The summary of the proposal is:
  * `CustomElementRegistry` becomes constructible and can inherit definitions from a parent registry.
  * `Element.prototype.attachShadow()` accepts a registry to use instead of the global registry.
  * `ShadowRoot` gains DOM creation APIs like `createElement()` and `importNode()` which can be used instead of `document.createElement()` to use scoped registries.
  * Elements remember their scope, so `innerHTML` creates DOM in the element's scope, and `attachShadow()` can use its element's scope by default.

This proposal requires that at least some DOM creation code be updated to use `ShadowRoot`s (or the result of `getRootNode()`) instead of `Document`s for imperative DOM creation, so there may be some upgrade difficulties when mixing new scope-aware code and old scope-unaware code.

I think this concern might be mitigated by being able to upgrade frameworks and template libraries, and by the global registry still being the default registry. Using scoping wouldn't necessarily require that _all_ DOM creation code in an app use the scoped API, just the code that's needed to work within a scope.

-- 
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/488#issuecomment-350077473