Declarative Shadow DOM

[mfreed7]

Description

Declarative Shadow DOM is a declarative API that allows the creation of shadow roots using only HTML and no Javascript. This API allows Web Components that use Shadow DOM to make use of Server-Side Rendering (SSR), to get rendered content on screen quickly without requiring Javascript for shadow root attachment.

Specification

whatwg/html#5465

Open Issues

whatwg/dom#831

Tests

https://wpt.fyi/results/shadow-dom/declarative?label=master&label=experimental&aligned&view=subtest

Current Implementations

• Blink
• Gecko
• WebKit

Standards Positions

This is implemented and shipped in Blink, and WebKit. Gecko is positive and implementing.

Browser bug reports

https://crbug.com/1379513

Developer discussions

No response

Polls & Surveys

No response

Existing Usage

https://chromestatus.com/metrics/feature/timeline/popularity/3196

Workarounds

No response

Accessibility Impact

No response

Privacy Impact

No response

Other

No response

[foolip]

For survey data and web developer demand, in preliminary results from State of HTML 2023, Declarative Shadow DOM was a common response to the freeform question "Which existing HTML features or browser APIs are you unable to use because of browser differences or lack of support?"

[foolip]

Shadow DOM, ElementInternals and Custom Elements were also a somewhat common responses.

[mbrodesser-Igalia]

Be aware that Selection (https://developer.mozilla.org/en-US/docs/Web/API/Selection) works differently in Gecko/Firefox than in other engines, since Gecko supports multiple ranges. Existing issues like https://bugzilla.mozilla.org/show_bug.cgi?id=1455893 in Gecko might become more relevant. They're potentially time-consuming to fix.

[foolip]

From State of HTML preliminary results, Declarative Shadow DOM was among the features that respondents expressed the most interest for. Note that this wasn't freeform, it's based on the features the survey asked about experience and sentiment for.

[gsnedders]

What's the status of https://github.com/web-platform-tests/wpt/blob/master/shadow-dom/declarative/getinnerhtml.tentative.html? The test links to whatwg/dom#831, but as Declarative Shadow DOM landed there's no getInnerHTML, and there doesn't seem to be any open issue asking for it to be added.

On the face of it, we should replace that test with a historical test that getInnerHTML isn't supported.

[mfreed7]

What's the status of https://github.com/web-platform-tests/wpt/blob/master/shadow-dom/declarative/getinnerhtml.tentative.html? The test links to whatwg/dom#831, but as Declarative Shadow DOM landed there's no getInnerHTML, and there doesn't seem to be any open issue asking for it to be added.

On the face of it, we should replace that test with a historical test that getInnerHTML isn't supported.

whatwg/html#8867 is the issue discussing getInnerHTML.

[gsnedders]

What's the status of https://github.com/web-platform-tests/wpt/blob/master/shadow-dom/declarative/getinnerhtml.tentative.html? The test links to whatwg/dom#831, but as Declarative Shadow DOM landed there's no getInnerHTML, and there doesn't seem to be any open issue asking for it to be added.
On the face of it, we should replace that test with a historical test that getInnerHTML isn't supported.

whatwg/html#8867 is the issue discussing getInnerHTML.

Ah, okay, so it's an ongoing open issue; I'd clearly misunderstood (and somehow failed to find that issue!).

[gsnedders]

Several of the tests (/shadow-dom/declarative/declarative-shadow-dom-attachment.html, /shadow-dom/declarative/declarative-shadow-dom-basic.html) rely on Element.prototype.setHTMLUnsafe and Document.prototype.parseHTMLUnsafe.

This probably isn't really part of Declarative Shadow DOM, and there's no good reason for the tests to rely on these; the tests were only changed to rely on these functions in web-platform-tests/wpt#41704, which effectively reduced test coverage of Declarative Shadow DOM for Firefox and Safari (as they now all fail before running the actual test).

See web-platform-tests/wpt#43202 to partially revert that.

[mfreed7]

Several of the tests (/shadow-dom/declarative/declarative-shadow-dom-attachment.html, /shadow-dom/declarative/declarative-shadow-dom-basic.html) rely on Element.prototype.setHTMLUnsafe and Document.prototype.parseHTMLUnsafe.

This probably isn't really part of Declarative Shadow DOM, and there's no good reason for the tests to rely on these; the tests were only changed to rely on these functions in web-platform-tests/wpt#41704, which effectively reduced test coverage of Declarative Shadow DOM for Firefox and Safari (as they now all fail before running the actual test).

See web-platform-tests/wpt#43202 to partially revert that.

I'm ok with doing that, but it'll take (a lot!) more work. You'll have to manually recursively traverse into shadow roots and serialize the whole tree yourself.

This is precisely why I really wanted to get setHTMLUnsafe and parseHTMLUnsafe landed in the spec before we landed declarative shadow DOM. It's basically required to use the feature. I'd consider them dependent features.

[dandclark]

This proposal has been accepted as part of Interop 2024! On behalf of the entire Interop team, thank you for proposing it. You’ll be able to track progress on this topic throughout the year via the Interop 2024 dashboard.