Intent to Ship: Declarative shadow DOM serialization

[Mason Freed]

Contact emails

mas...@chromium.org

Explainer

https://github.com/whatwg/html/issues/8867#issuecomment-1856696628

Specification

https://html.spec.whatwg.org/#dom-element-gethtml

Summary

The prototype implementation (which was shipped in 2020 and then shape-changed in 2023) contained a method called `getInnerHTML()` that could be used to serialize DOM trees containing shadow roots. That part of the prototype was not standardized with the rest of declarative shadow dom, and only recently has it reached spec consensus (https://github.com/whatwg/html/issues/8867). As part of that consensus, the shape of the getInnerHTML API changed. This feature represents the desire to ship the new, agreed-upon shape, which is: - getHTML({serializableShadowRoots:bool, shadowRoots:[roots]}).

Blink component

Blink>DOM>ShadowDOM

Search tags

getHTML, declarative shadow dom

TAG review

None

TAG review status

Pending

Risks

Interoperability and Compatibility

This is a new feature, so there should be no compat risks. And the spec PRs got comments and support from multiple implementers, so I would expect support coming soon from other browsers.

Gecko: Positive (https://github.com/whatwg/html/pull/10139#pullrequestreview-1966263347)

WebKit: Neutral (https://github.com/whatwg/html/pull/10139) General comments from annevk@ seem supportive, but no LGTM directly.

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

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

Flag name on chrome://flags

ElementGetHTML

Finch feature name

ElementGetHTML

Requires code in //chrome?

False

Tracking bug

https://crbug.com/41490936

Estimated milestones

DevTrial on desktop

125

DevTrial on Android

125

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5102952270528512?gate=5177496192679936

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDjRLRyHkgo%3DwTF76uj5rA46xafYsEmh4G_m%2BAcXTUev%3Dw%40mail.gmail.com

This intent message was generated by Chrome Platform Status.

[Alex Russell]

Drive-by API design comments:

Was this run past the TAG? Did they ask this is not adding a way to return a stream? And was there a discussion of a setter API that supports streams? It would be disappointing if we added new surface of this sort without resolving the core data type issues.

Best,

Alex

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDgOWWoodXvvk7qYTNFMFhsbDxebc%3Dw%3D50nuq6y5jNhNag%40mail.gmail.com.

[Vladimir Levin]

On Thu, Apr 4, 2024 at 6:54 PM Mason Freed <mas...@chromium.org> wrote:

Contact emails

mas...@chromium.org

Explainer

https://github.com/whatwg/html/issues/8867#issuecomment-1856696628

Specification

https://html.spec.whatwg.org/#dom-element-gethtml

Summary

The prototype implementation (which was shipped in 2020 and then shape-changed in 2023) contained a method called `getInnerHTML()` that could be used to serialize DOM trees containing shadow roots. That part of the prototype was not standardized with the rest of declarative shadow dom, and only recently has it reached spec consensus (https://github.com/whatwg/html/issues/8867). As part of that consensus, the shape of the getInnerHTML API changed. This feature represents the desire to ship the new, agreed-upon shape, which is: - getHTML({serializableShadowRoots:bool, shadowRoots:[roots]}).

I think this is the case, but just to clarify: this is shipping a new function and not renaming/updating the previously shipped one, right? So, at least for the time being, there will be two similar functions shipped

 

--

[Mason Freed]

Thanks for the comments!

On Fri, Apr 5, 2024 at 8:26 AM Vladimir Levin <vmp...@chromium.org> wrote:

I think this is the case, but just to clarify: this is shipping a new function and not renaming/updating the previously shipped one, right? So, at least for the time being, there will be two similar functions shipped 

That's correct. This intent ships `getHTML()`. And then (after some time) this other intent will be used to remove the old `getInnerHTML()` function. But as you said, I'd like the new one to be available for at least a few milestones to give folks time to migrate.

On Thu, Apr 4, 2024 at 9:27 PM Alex Russell <sligh...@chromium.org> wrote:

Drive-by API design comments:

Was this run past the TAG? Did they ask this is not adding a way to return a stream? And was there a discussion of a setter API that supports streams? It would be disappointing if we added new surface of this sort without resolving the core data type issues.

So yes, the original declarative shadow DOM feature was submitted for TAG review, and its explainer had a section about `getInnerHTML()` which is basically the same except for the name. The TAG review itself has quite a bit of discussion about `getInnerHTML` and serialization (starting roughly here) and doesn't bring up the stream-based API you mention here, which is too bad.

The original feature shipped in 2020 and this intent represents the penultimate of a series of about eight chromestatus entries over 4.5 years to finally get it standardized. I'm really hoping we can tackle stream based serialization as a separate effort. :-)

Thanks,

Mason

 

Best,

Alex

[Alex Russell]

Ok, so Chris reminded me that we'd already shipped a setter via `setHTMLUnsafe()` and that Mozilla has an intent out for this new version of the getter, which suggests to me that we should, indeed, handle the streams thing separately.

LGTM1.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Daniel Bratell]

LGTM2

/Daniel

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c4c21d51-25d6-405b-acb9-e34486e85b08n%40chromium.org.

[Mike Taylor]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cb174c34-f230-4aa5-9846-bbeba980958f%40sarasas.se.

[Mason Freed]

Thank you all!

Mason

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDgOWWoodXvvk7qYTNFMFhsbDxebc%3Dw%3D50nuq6y5jNhNag%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c4c21d51-25d6-405b-acb9-e34486e85b08n%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.