[WICG/webcomponents] Idea: Alternative Ways to Control Registry Scoping (Issue #1058)

## Background

Recently, the community has been exploring practical uses of scoped element registries more. A number of situations have arisen that seem to indicate a potential deficiency in the current API surface. Some scenarios include:

* Setting `innerHTML` on a detached element, where a specific registry should apply.
* Integrating with a 3rd party framework (e.g. React) that creates elements without knowledge of the appropriate registry.
* Existing web components, libraries, and frameworks that don't/can't easily plumb through custom registries into their systems.

The consensus seems to be that none of these scenarios are blockers to the current proposal, but that they do represent key use cases that we should have a reasonable solution for.

## Strawman

One potential solution is to provide additional APIs that explicitly control the registry scope in which code runs. For example, we could add something like:

* `document.runWithScope(registry, callback)` - Synchronously invokes the callback, ensuring that all element creation and upgrades use the specified registry.
* `document.runWithoutScope(callback)` - Synchronously invokes the callback, ensuring that no element created will be upgraded, regardless of whether it is defined in the global registry.

## Request

I'd love to get feedback on the use cases and applicability of an API like this. Let's try to avoid bike shedding on the name and where the API lives (I'm not super happy with that myself actually). I think we can figure that out later if we determine first that we want something like this, how it would work, and whether it's feasible for browser implementors.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/1058
You are receiving this because you are subscribed to this thread.

Message ID: <WICG/webcomponents/issues/1058@github.com>

Received on Friday, 3 May 2024 17:52:55 UTC