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 > (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) > Le 08/06/2023 à 18:36, Mason Freed a écrit : > > 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 > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EDOM> > > 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 > <https://chromestatus.com/features#tags:Template%20Instantiation>, DOM > Parts <https://chromestatus.com/features#tags:DOM%20Parts> > > 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 > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> > ? 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 > <https://chromestatus.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+unsubscr...@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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDj7PNv4z8Eh3KrOuSPM46SC0b7tCPZFG%2B3cQZrjNJC%3DHA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- 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+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDhKXHCqtAEHCmNX5CDUDtJeBF1ByC-7ZnrSGfR-9JKnwQ%40mail.gmail.com.
