Intent to Prototype: DOM Parts

[Mason Freed]

Contact emails

mas...@chromium.org

Explainer

https://github.com/tbondwilkinson/dom-parts#readme

Specification

None

Summary

In many applications and frameworks, JavaScript code needs to locate and mutate a set of "nodes of interest." The current methodology for finding "nodes of interest" is either a full DOM tree walk or DOM queries, and for updating either that walk is repeated or the "nodes of interest" are then retained in JavaScript data structures or as properties on the DOM objects. There are two major drawbacks to these solutions: 1. DOM mutating methods like clone() are not aware of in-memory references to cloned nodes or special JavaScript properties. They can only clone the HTML content itself. 2. The DOM walks for locating nodes often occur immediately after the browser has already performed that same DOM walk, for example during HTML rendering of the document or <template> nodes. The DOM Parts API is intended to assist in locating, storing, and updating these nodes with new primitives that identify nodes and ranges of nodes at parse time and an imperative API to retrieve, walk, and update these nodes.

Blink component

Blink>DOM

Motivation

See the overall description of the feature for the general motivation. The perceived benefits of such an API are enhanced speed and reduced JS code size for framework code.

Initial public proposal

https://github.com/WICG/webcomponents/issues/990

Search tags

Template Instantiation, DOM Parts

TAG review

TAG review status

Pending

Risks

Interoperability and Compatibility

Gecko: No signal

WebKit: No signal

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?

Debuggability

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

No

Flag name

Requires code in //chrome?

False

Tracking bug

https://crbug.com/1453291

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5199708301033472

Links to previous Intent discussions

This intent message was generated by Chrome Platform Status.

[Frédéric Wang]

Hi Mason,

I have been reviewing the trusted type sinks and I see that Chromium accepts TrustedScript for ChildNodePart.replaceChildren(): https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/dom/child_node_part.idl;l=14;drc=bc57da7a7232ad70c10ff8a9254c99ce7b71868e but that's not mentioned on https://github.com/tbondwilkinson/dom-parts?tab=readme-ov-file#details and commit message at https://chromium-review.googlesource.com/c/chromium/src/+/4681916 does not provide any explanation?

Is it intentional? Is there any spec links where that's being discussed?

(Note that ParentNode/ChildNode have similar APIs and Chromium accept Trusted types for them, but that's actually not aligned with the DOM spec. IIUC, these are from a legacy proposal and should really be unshipped: https://dom.spec.whatwg.org/#ref-for-dom-parentnode-replacechildren and https://dom.spec.whatwg.org/#ref-for-dom-childnode-replacewith ; since DOM part is still in experimental state, it should probably be fine to just remove Trusted Type arguments, unless that was something done on purpose of course)

--
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%3DNeDj7PNv4z8Eh3KrOuSPM46SC0b7tCPZFG%2B3cQZrjNJC%3DHA%40mail.gmail.com.

[Mason Freed]

On Mon, Jan 6, 2025 at 6:18 AM Frédéric Wang <fw...@igalia.com> wrote:

Hi Mason,

I have been reviewing the trusted type sinks and I see that Chromium accepts TrustedScript for ChildNodePart.replaceChildren(): https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/dom/child_node_part.idl;l=14;drc=bc57da7a7232ad70c10ff8a9254c99ce7b71868e but that's not mentioned on https://github.com/tbondwilkinson/dom-parts?tab=readme-ov-file#details and commit message at https://chromium-review.googlesource.com/c/chromium/src/+/4681916 does not provide any explanation?

Is it intentional? Is there any spec links where that's being discussed?

Nope - not intentional. Or at least, I would be happy to remove TrustedScript from that IDL, as I don't think it'll break anything. The DOM Parts API is still very much a prototype, and as such, doesn't have a spec. But I'll put up a CL to remove that today.

Thanks,

Mason