Declarative Shadow DOM

Describe the bug

I would like to have the ability to use declarative shadow DOM (without custom elements) within Solid components just to get style scoping. It doesn't work and I get the error Uncaught TypeError: Cannot read properties of null (reading 'nextSibling')

Your Example Website or App

https://codesandbox.io/p/sandbox/awesome-sky-8fp8z5

Steps to Reproduce the Bug or Issue

export default function ShadowTest() {
  return (
    <div>
      <template shadowrootmode="open">
        <p>This is in the shadow DOM</p>
        <slot>
          <p>This is in the light DOM</p>
          <button>Light button</button>
        </slot>
        <button>Shadow button</button>
      </template>
    </div>
  );
}

Expected behavior

It should render a shadow tree.

Screenshots or Videos

No response

Platform

OS: all
Browser: Chrome + Safari (Firefox hasn't shipped support for it yet)

Additional context

No response

As a test I just tried in Chrome:

const d = document.createElement("div")
d.innerHTML = `<div>
      <template shadowrootmode="open">
        <p>This is in the shadow DOM</p>
        <slot>
          <p>This is in the light DOM</p>
          <button>Light button</button>
        </slot>
        <button>Shadow button</button>
      </template>
    </div>`

And I got:

Found declarative shadowrootmode attribute on a template, but declarative Shadow DOM has not been enabled by includeShadowRoots.

I was just trying to figure out what the parsing would look like for this. I think it might start with identifying with template elements we need to walk into .content before continuing into firstChild/nextSibling. That would probably fix the error assuming that it stays in the DOM like that and doesn't get swallowed. Does the template element actually have active nodes in this scenario? Most template elements contain only inert nodes.

This section of this article might answer that

This functionality is already present for Portals using the useShadow prop.

Is it possible to expand this functionality to a generic utility component, eg something like <Shadow> ?

A simple workaround is to make a <ShadowRoot> component, and then create the shadow root with JavaScript in there, then finally pass props.children along.

Something like the following (I wrote it quickly, didn't test it, but it shows idea):

function ShadowRoot(props) {
  let div

  onMount(() => {
    const root = div.attachShadow(...)
    render(props.children, root) // or similar
  })

  return <div ref={div}></div>
}

function UsageExample() {
  return <ShadowRoot>
    <div>hello<div>
    <style>{`
      /* scoped style */
      div { background: blue }
    `}</style>
  </ShadowRoot>
}

But this is not compatible with SSR, it creates a new root, and contexts won't automatically flow into the new root, etc. Other than that it has worked great in some places where I used it.

Declarative shadow roots will be, and that'll be really nice! Every framework that doesn't have scoped styles out of the box is gonna now have scoped styles out of the box, with the same sorts of patterns as custom elements.

Revisiting this. innerHTML doesn't play nicely with declarative shadow DOM. When you inject HTML containing <template shadowrootmode="open"> into the page with innerHTML, it remains just a template, whereas it's meant to instantly become shadow DOM. innerHTML doesn't understand shadowrootmode.

There is a new setHTMLUnsafe method (supported in all browsers) and getHTML method (supported only in Chrome 125) that together act as a declarative shadow DOM friendly alternative to innerHTML.

The documentation for all of this is currently pretty terrible so I wrote about it here: https://fullystacked.net/innerhtml-alternatives/

This would epic to have it working. Combine it with solidjs/solid-router#459 and we can get awesome power of Solid.js together with Server Actions and Server Rendering. ❤️

This seems to work well:

/**
 * A declarative shadow root component
 *
 * Hooks into SolidJS' Portal's `useShadow` prop
 * to handle shadow DOM and the component lifecycle
 */
const ShadowRoot: ParentComponent = (props) => {
  let div: HTMLDivElement;
  return (
    <div ref={div!}>
      <Portal mount={div!} useShadow={true}>
        {props.children}
      </Portal>
    </div>
  );
};

@ivancuric

@ivancuric worked for me!
Additionally, here is how you can add styles to the shadow root if you are using vite, this worked for me on solidStart:

import styles from "~/styling/sheets.css?inline";

const getStyles = query(async () => {
  "use server"
  return styles
}, "getStyles")



const ShadowRoot: ParentComponent = (props) => {
  let div: HTMLDivElement;
  const css = createAsync(() => getStyles());
  return (
    <div ref={div!}>
      <Portal mount={div!} useShadow={true}>
        <style>{css()}</style>
        {props.children}
      </Portal>
    </div>
  );
};

Per:

https://stackoverflow.com/a/78244034/2446144

A little janky at load time because ShadowRoot does not render on the server, obviously

It needs to call getStyles like that, using the css import directly on the client-side results in errors due to server-side deps

Issue with lightningcss dependency in Vite 5.0 affecting Serverless deployment - Missing ../pkg parcel-bundler/lightningcss#701 (comment)

I'm not really clear what you all are talking about in regards to portals here. Yes portals in 1.0 can use the shadow DOM, but declarative shadow DOM is a very different thing.

I'm not really clear what you all are talking about in regards to portals here. Yes portals in 1.0 can use the shadow DOM, but declarative shadow DOM is a very different thing.

The Portals are simply a workaround for Declarative Shadow DOM (DSD) not working, where Portal imperatively creates the shadow root while the user writes declarative JSX.

The intent is that we can use shadow DOM in a Solid component by writing declarative markup (obviously we can do it imperatively and abstract it as in my example), but Portals just happen to be an existing API that can be used declaratively (but doing so is not compatible with SSR).

Native support for <template shadowrootmode> can be compatible with SSR because the server simply sends the markup to the client. Solid would need to be aware of it to take it into consideration during hydration.

I don't think users care if DSD actually works, what they want is simply to use Shadow DOM declaratively and it also work with SSR. How Solid does that (DSD or not) is inconsequential to the need:

the feature can be an implementation detail behind a built-in <ShadowRoot> component,
or Portal shadow roots could have SSR support added to them,
or Solid could map <template shadowrootmode> directly in the JSX to imperative ShadowRoot-creating code without DSD,
or Solid could use native parsing (f.e. setHTMLUnsafe) to use native DSD

and only the end result would matter: support for native slots and native style scoping in Solid components, with or without SSR.

Navigation Menu

Repository navigation

Declarative Shadow DOM #1834

Describe the bug

Your Example Website or App

Steps to Reproduce the Bug or Issue

Expected behavior

Screenshots or Videos

Platform

Additional context

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Declarative Shadow DOM #1834

Description

Describe the bug

Your Example Website or App

Steps to Reproduce the Bug or Issue

Expected behavior

Screenshots or Videos

Platform

Additional context

Activity

ryansolid commented on Aug 1, 2023

o-t-w commented on Aug 2, 2023

ivancuric commented on Aug 3, 2023

trusktr commented on Aug 9, 2023

o-t-w commented on May 8, 2024

o-t-w commented on May 8, 2024

BleedingDev commented on Jun 3, 2024

ivancuric commented on Jul 11, 2024

Sleepful commented on Jun 7, 2025

ryansolid commented on Apr 14, 2026

trusktr commented on Oct 17, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions