Shadow DOM v1: Browser Support, Modes, Slots

What is Shadow DOM v1?

Shadow DOM v1 is the second-generation Shadow DOM specification, part of the Web Components family in the W3C and WHATWG DOM Standard. A developer calls element.attachShadow({mode: 'open'}) to attach a sealed DOM tree to a host element. The tree has its own markup and CSS that the outer page cannot reach.

Which browsers does Shadow DOM v1 support?

Every major modern browser supports Shadow DOM v1 by default. Internet Explorer is the only one that never did.

What are the key features of Shadow DOM v1?

Shadow DOM v1 ships nine encapsulation features that the v0 draft either did not have or shaped differently. They are the foundation that Lit, Stencil, Salesforce LWC, and many other component frameworks build on.

• attachShadow with mode: The host calls element.attachShadow({mode: 'open' | 'closed'}). Mode is required, which makes the access policy explicit.
• Open and closed shadow roots: Open mode exposes the root through host.shadowRoot. Closed mode hides it from external scripts so only the code that attached it keeps the reference.
• Slot composition: The <slot> element accepts light DOM children from the host and projects them into the shadow tree. Named slots use the slot attribute; the default slot catches the rest.
• slotchange event: A slot fires slotchange at the end of a microtask when its assigned nodes change, so a component can react to host content updates without a MutationObserver.
• CSS scoping: Outer page selectors do not cross the shadow boundary, and inner styles do not leak out. The :host, :host(), and ::slotted() pseudo-classes give controlled hooks for styling the host and projected children.
• CSS custom properties cross the boundary: Custom properties declared on the host are inherited inside the shadow tree, so a parent page can theme a component without piercing its DOM.
• Constructable stylesheets and adoptedStyleSheets: A shadow root can share a single CSSStyleSheet across many instances through shadowRoot.adoptedStyleSheets, which is faster than re-parsing inline <style> blocks per instance.
• Retargeted events: Events that bubble out of a shadow tree have their target retargeted to the host, while event.composedPath() still exposes the full path for components that opt in.
• Declarative Shadow DOM: The <template shadowrootmode> attribute lets servers send shadow trees as HTML, so server-rendered Web Components hydrate without JavaScript. Chrome 90+, Edge 90+, Firefox 123+, and Safari 16.4+ support it.

How do you check if a browser supports Shadow DOM v1?

Shadow DOM v1 support depends on a single API: Element.attachShadow. Three quick checks cover most production needs.

• Run a one-line console test: Press F12, open the Console tab, and paste typeof Element.prototype.attachShadow === "function". It returns true if Shadow DOM v1 works.
• Try a real attach: In the same console, run document.createElement("div").attachShadow({mode: 'open'}). A returned ShadowRoot object confirms the API is live; an exception means the browser does not support it.
• Detect the slot element: Run "slot" in document.createElement("div"). The slot mechanism is the v1 distribution model; a true result means the browser ships v1, not v0.
• Probe declarative Shadow DOM separately: Run HTMLTemplateElement.prototype.hasOwnProperty("shadowRootMode"). The v1 API can ship before declarative shadow DOM does, so this catches the common gap on older Firefox.
• Load a polyfill where needed: If any of the checks return false, load github.com/webcomponents/polyfills with the webcomponents-bundle.js entry. The polyfill stamps a JavaScript-only attachShadow into the prototype.

These checks each run on one browser at a time. To validate Shadow DOM v1 across every browser and OS combination your users have, TestMu AI gives you 3,000+ real browsers and devices to run the same checks on.

What are the known issues with Shadow DOM v1?

Shadow DOM v1 is one specification, but the encapsulation rules surface real cross-browser quirks. Here is what to watch for and how to handle each one.

• Global CSS does not cross the boundary: Bootstrap, Tailwind utility classes, and reset stylesheets in the page head do not apply inside a shadow root. How to handle it: Pass tokens through CSS custom properties on the host, or use shadowRoot.adoptedStyleSheets to share a constructable stylesheet across components.
• document.querySelector cannot pierce the shadow root: A regular document.querySelector("button") ignores buttons inside any shadow tree. Test frameworks need a piercing API. How to handle it: In my experience this is the single biggest cross-browser pitfall when retrofitting tests onto a Web Components codebase. Selenium 4's getShadowRoot(), Playwright's default selectors, and Cypress's cy.shadow() each pierce differently, so pick one tool per repo.
• Focus and selection cross the boundary in browser-specific ways: Tab order travels into shadow trees in Chrome and Edge; older Firefox skipped some shadow children for a few releases after Firefox 63. document.activeElement retargets to the host, not the focused node inside. How to handle it: Walk document.activeElement.shadowRoot.activeElement recursively when you need the deepest focus, and test tab order on every target browser.
• Closed mode is not a security boundary: A closed root hides shadowRoot from outside JavaScript, but the same-realm code can still reach internals through event paths and attached references. How to handle it: Treat closed mode as a developer hint, not a sandbox. The web.dev Shadow DOM v1 guide explicitly recommends open mode.
• Accessibility tools need extra plumbing: Some screen readers historically had partial support for content inside shadow trees, especially when using ARIA references like aria-labelledby across the boundary. How to handle it: Keep ARIA attributes on light DOM children where possible and use the ElementInternals API to expose role, value, and validation to assistive tech.
• Form controls inside a shadow root: A <form> in the page head does not pick up a custom <input> defined inside a shadow tree without help. How to handle it: Use ElementInternals.setFormValue() with form-associated custom elements (Chrome 77+, Safari 16.4+, Firefox 98+) so the host element participates in the outer form.

Citations

All Shadow DOM v1 version numbers and platform notes in this guide come from these primary sources:

• WHATWG DOM Standard - Shadow trees: dom.spec.whatwg.org/#shadow-trees
• MDN Web Docs - Using shadow DOM: developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_shadow_DOM
• MDN Web Docs - Element.attachShadow(): developer.mozilla.org/en-US/docs/Web/API/Element/attachShadow
• MDN Web Docs - ShadowRoot: developer.mozilla.org/en-US/docs/Web/API/ShadowRoot
• web.dev - Shadow DOM v1: Self-Contained Web Components: web.dev/articles/shadowdom-v1
• Chrome Platform Status - Shadow DOM v1: chromestatus.com/feature/4667415417847808
• WebKit - Introducing Web Components in Safari 10: webkit.org/blog/4096/introducing-shadow-dom-api
• Mozilla Hacks - Web Components in Firefox 63: hacks.mozilla.org/2018/10/firefox-63-tricks-and-treats
• Wikipedia - Web Components: en.wikipedia.org/wiki/Web_Components
• web.dev - Declarative Shadow DOM: web.dev/articles/declarative-shadow-dom
• MDN Web Docs - HTMLTemplateElement.shadowRootMode: developer.mozilla.org/en-US/docs/Web/API/HTMLTemplateElement/shadowRootMode
• Polymer Project - Web Components v0 deprecations: polymer-project.org/blog/2018-10-02-webcomponents-v0-deprecations
• WebComponents Polyfills: github.com/webcomponents/polyfills
• Hayato Ito - What's New in Shadow DOM v1 (by examples): hayatoito.github.io/2016/shadowdomv1