![]() For (), the context node and root are the same. The context node is the node that hosts the element creation API that was invoked, such as (), or. If the root has a CustomElementRegistry, use that registry to look up the definition, otherwise use the global objects CustomElementRegistry object. The registry is found by getting the context node's root. That process needs to take a context node that is used to look up the definition. Finding a custom element definitionīecause there is no longer a single global custom element registry, when creating elements, the steps to look up a custom element definition need to be updated to be able to find the correct registry. These APIs work the same as their Document equivalents, but use scoped registries instead of the global registry. ![]() In order to support scoped registries we add new scoped APIs, that were previously only available on Document, to ShadowRoot: The scoped APIs have an associated Node that can be used to look up a CustomElementRegistry and thus a scoped definition. Import Scoped element creation APIsĮlement creation APIs, like createElement() and innerHTML can be grouped into global API (those on Document or Window) and scoped APIs (those on HTMLElement and ShadowRoot). This proposal allows user code to create new instances of CustomElementRegistry: This approach also allows for a nice API by extending the DocumentOrShadowRoot interface and ShadowRoot#attachShadow(). Rather than invent a new scoping primitive to the DOM, it is natural to extend the shadow root scoping responsibilities to include custom element registrations. The globally shared custom element registry, however, requires coordination so that multiple scopes on a page agree on the registrations. The goal is to allow scopes to function without required coordination with other scopes. Shadow roots provide an encapsulation mechanism for isolating a DOM tree's, nodes, styles, and events from other scopes. Why use shadow roots as registration scopes? Internal implementation elements: A component may have private internal elements that it needs to register, but would prefer not to leak to the external environment.Third-party, CDN-hosted libraries: Libraries like social-media share buttons and embeds, maps and documentation viewers, etc., can vend complex UI widgets that may need to register many elements, and they should not be using up a global namespace that they don't fully control.In addition to library duplication, there are other common use-cases for scopes: If this DOM is created with custom elements, they will need to be registered and could conflict with the page's scripts. Browser Extensions: Many browser extensions create DOM to be displayed in the main page.If the application and plug-in use the same component, they will have contention for the tag name. The application and plug-ins will typically be built and distributed independently. Applications with plug-in architectures: Some applications that allow plug-ins will run plug-ins in the main window.This makes library duplication in production common. Large, complex applications: These can have components authored by different teams, with loose coordination between them, built and deployed to production at different times.Thus an application may contain multiple definitions of a tag name from the same library, but at different versions. Any sized applications using npm: NPM may install multiple versions of a library if it can't find a single version that satisfies version constraints (and it many cases where it could, but doesn't because of its lack of a version constraint solver).This can happen for many reasons, but there are a few application/library types where this is common: Multiple versions of a library is a common source of this problem. If more than one library (or more than one instance of a library) tries to define the same tag name, the application will fail. These libraries must currently contend for the global shared resource that is the CustomElementRegistry. It's quite common for web applications to contain libraries from multiple sources, whether from different teams, vendors, package managers, etc. ![]() Why do developers need scoped custom element registries? This proposal is focused on the MVP to provide encapsulation for element definitions, and it could be extended in the future if needed to provide more versatility. New element construction APIs are added to ShadowRoot to allow element creation to be associated with a scope. Potentially custom elements created within a scope use the registry for that scope to perform upgrades. This is accomplished by allowing user code to create multiple custom element registries and associate them with shadow roots that function as scopes for element creation and custom element definitions. This proposal allows for multiple custom element definitions for a single tag name to exist within a page.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |