Enforce same parameters for attachShadow on declarative shadow root #1246

mfreed7 · 2024-01-16T21:55:45Z

Per the discussion at #1235, this PR changes the behavior when calling attachShadow() on a node with an existing declarative shadow root. Now, if the mode does not match between the arguments to attachShadow() and the existing root, throw an exception. Prior behavior was to silently return the declarative root as-is, with mismatched modes.

See also, whatwg/html#10069.

@emilio @annevk @rniwa

Closes #1235

At least two implementers are interested (and none opposed):
- Chromium (me)
- WebKit sounds supportive
Tests are written and can be reviewed and commented upon at:
- https://wpt.fyi/results/shadow-dom/declarative/declarative-shadow-dom-repeats.html
Implementation bugs are filed:
- Chromium: https://crbug.com/1379513
- Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1876885
- WebKit: https://bugs.webkit.org/show_bug.cgi?id=268208
MDN issue is filed: There have been a few changes to declarative shadow DOM mdn/content#32289
The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

Preview | Diff

Two changes: 1. If two declarative shadow roots are included within a single host element, only the *first* one will remain. This is a change in behavior from before, but reached consensus [1] and hopefully won't be a breaking change for anyone. 2. If attachShadow() is used on an existing declarative shadow root, and the parameters (e.g. shadow root type, etc.) do not match, an exception is thrown. This, also, is a breaking change, but hopefully not one that gets hit. See also [1]. See [2] and [3] for the corresponding spec PRs. [1] whatwg/dom#1235 [2] whatwg/html#10069 [3] whatwg/dom#1246 Bug: 1379513,1042130 Change-Id: Ia81088227797013f9f62f5ac90f76898663b0bc4

Two changes: 1. If two declarative shadow roots are included within a single host element, only the *first* one will remain. This is a change in behavior from before, but reached consensus [1] and hopefully won't be a breaking change for anyone. 2. If attachShadow() is used on an existing declarative shadow root, and the parameters (e.g. shadow root type, etc.) do not match, an exception is thrown. This, also, is a breaking change, but hopefully not one that gets hit. See also [1]. See [2] and [3] for the corresponding spec PRs. [1] whatwg/dom#1235 [2] whatwg/html#10069 [3] whatwg/dom#1246 Bug: 1379513,1042130 Change-Id: Ia81088227797013f9f62f5ac90f76898663b0bc4 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5191750 Commit-Queue: Mason Freed <masonf@chromium.org> Auto-Submit: Mason Freed <masonf@chromium.org> Commit-Queue: David Baron <dbaron@chromium.org> Reviewed-by: David Baron <dbaron@chromium.org> Cr-Commit-Position: refs/heads/main@{#1249214}

dom.bs

annevk · 2024-01-22T08:30:54Z

@mfreed7 you also need to restore the PR template as this is a normative change and thus we need to go through all the checkboxes.

…mismatched imperative ones, a=testonly Automatic update from web-platform-tests Disallow multiple declarative roots and mismatched imperative ones Two changes: 1. If two declarative shadow roots are included within a single host element, only the *first* one will remain. This is a change in behavior from before, but reached consensus [1] and hopefully won't be a breaking change for anyone. 2. If attachShadow() is used on an existing declarative shadow root, and the parameters (e.g. shadow root type, etc.) do not match, an exception is thrown. This, also, is a breaking change, but hopefully not one that gets hit. See also [1]. See [2] and [3] for the corresponding spec PRs. [1] whatwg/dom#1235 [2] whatwg/html#10069 [3] whatwg/dom#1246 Bug: 1379513,1042130 Change-Id: Ia81088227797013f9f62f5ac90f76898663b0bc4 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5191750 Commit-Queue: Mason Freed <masonf@chromium.org> Auto-Submit: Mason Freed <masonf@chromium.org> Commit-Queue: David Baron <dbaron@chromium.org> Reviewed-by: David Baron <dbaron@chromium.org> Cr-Commit-Position: refs/heads/main@{#1249214} -- wpt-commits: f18d8f8009c9256d24aad9439e00324d8eaff385 wpt-pr: 43958

Per the discussion at whatwg#1235, this PR changes the behavior when calling `attachShadow()` on a node with an existing declarative shadow root. Now, if the parameters do not match between the arguments to `attachShadow()` and the existing root, throw an exception. Prior behavior was to silently return the declarative root as-is, with mismatched parameters.

mfreed7 · 2024-01-27T01:40:27Z

@mfreed7 you also need to restore the PR template as this is a normative change and thus we need to go through all the checkboxes.

Done

annevk

Thanks this looks good.

@emilio could you double check this is what you had in mind?

dom.bs

emilio

Yeah this sounds about what I meant. Thanks Mason!

mfreed7 · 2024-01-29T23:17:57Z

Yeah this sounds about what I meant. Thanks Mason!

Just pointing out this comment: whatwg/html#10107 (comment)

Should we perhaps only throw exceptions if the attachShadow() parameters are explicitly passed? And not if the default values mismatch? I'm happy to modify this PR if there's agreement on that - it feels like a better way to go to me.

annevk · 2024-01-30T13:06:41Z

Let's work through that issue first.

dom.bs

See the discussion here: whatwg/html#10107 (comment) The new consensus is that the old behavior was likely web- incompatible, plus not very developer-desirable. The new behavior adds a `shadowrootclonable` attribute for declarative shadow dom to opt-in to clonable shadow roots. This is a slight behavior change from the existing shipped behavior, in that before the `clonable` concept was introduced, *any* declarative shadow root within a `<template>` would be cloned. Now, that behavior is opt in. So: old: <template> <div> <template shadowrootmode=open> I do NOT get cloned! </template> </div> </template> new: <template> <div> <template shadowrootmode=open shadowrootclonable> I get cloned! </template> </div> </template> See these three spec PRs: whatwg/dom#1246 whatwg/html#10069 whatwg/html#10117 Bug: 1510466 Change-Id: Ice7c7579094eb08b882c4bb44f93045f23b8f222

See the discussion here: whatwg/html#10107 (comment) The existing/old behavior was that all declarative shadow roots have their `clonable` bit set to true, so they automatically get cloned by `cloneNode()`. The new consensus is that this old behavior was likely web-incompatible because clones will just start getting shadow roots included. Plus it wasn't very developer-desirable. The new behavior adds a `shadowrootclonable` attribute for declarative shadow dom that allows a shadow root to opt-in to this behavior, but the default for all shadow roots will be `clonable=false`. This is a slight behavior change from the existing *shipped* behavior, in that before the `clonable` concept was introduced, *any* declarative shadow root within a `<template>` would be automatically cloned. Now, that behavior is opt in via `clonable`. So: pre-`clonable`: <template> <div> <template shadowrootmode=open> I get cloned! </template> </div> </template> <div> <template shadowrootmode=open> I do NOT get cloned! </template> </div> post-`clonable`, pre-this-CL: <template> <div> <template shadowrootmode=open> I get cloned! </template> </div> </template> <div> <template shadowrootmode=open> I ALSO get cloned! </template> </div> new as of this CL: <template> <div> <template shadowrootmode=open> I do NOT get cloned! </template> </div> <div> <template shadowrootmode=open shadowrootclonable> I DO get cloned! </template> </div> </template> <div> <template shadowrootmode=open> I do NOT get cloned! </template> </div> See these three spec PRs: whatwg/dom#1246 whatwg/html#10069 whatwg/html#10117 Bug: 1510466 Change-Id: Ice7c7579094eb08b882c4bb44f93045f23b8f222

See the discussion here: whatwg/html#10107 (comment) The existing *shipped* behavior (i.e. before the `clonable` concept was introduced) was that any declarative shadow root *within a `<template>`* would be automatically cloned, but no others. The semi-new behavior is the `clonable` bit concept, in which all declarative shadow roots have their `clonable` bit set to true, so they automatically get cloned by `cloneNode()`. That's regardless of whether they are inside or outside a template. The new consensus is that the "semi-new" clonable behavior is likely web-incompatible, because clones will just start getting shadow roots included. Plus it wasn't very developer-desirable. The new consensus is therefore to add a `shadowrootclonable` attribute for declarative shadow dom that allows a shadow root to opt-in to this behavior, but the default for all shadow roots will be `clonable=false`. This CL implements the new consensus behind the ShadowRootClonable flag. If the flag is false, the "shipped" behavior will be emulated via setting `clonable` in an equivalent way. See these three spec PRs: whatwg/dom#1246 whatwg/html#10069 whatwg/html#10117 Bug: 1510466 Change-Id: Ice7c7579094eb08b882c4bb44f93045f23b8f222

See the discussion here: whatwg/html#10107 (comment) The existing *shipped* behavior (i.e. before the `clonable` concept was introduced) was that any declarative shadow root *within a `<template>`* would be automatically cloned, but no others. The semi-new behavior is the `clonable` bit concept, in which all declarative shadow roots have their `clonable` bit set to true, so they automatically get cloned by `cloneNode()`. That's regardless of whether they are inside or outside a template. The new consensus is that the "semi-new" clonable behavior is likely web-incompatible, because clones will just start getting shadow roots included. Plus it wasn't very developer-desirable. The new consensus is therefore to add a `shadowrootclonable` attribute for declarative shadow dom that allows a shadow root to opt-in to this behavior, but the default for all shadow roots will be `clonable=false`. This CL implements the new consensus behind the ShadowRootClonable flag. If the flag is false, the "shipped" behavior will be emulated via setting `clonable` in an equivalent way. See these three spec PRs: whatwg/dom#1246 whatwg/html#10069 whatwg/html#10117 Bug: 1510466 Change-Id: Ice7c7579094eb08b882c4bb44f93045f23b8f222 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5260748 Reviewed-by: David Baron <dbaron@chromium.org> Auto-Submit: Mason Freed <masonf@chromium.org> Commit-Queue: Mason Freed <masonf@chromium.org> Cr-Commit-Position: refs/heads/main@{#1258910}

petervanderbeken · 2024-02-12T10:31:09Z

dom.bs

+     <li><p><var>currentShadowRoot</var>'s <a for=ShadowRoot>declarative</a> is false,
+
+     <li><p><var>currentShadowRoot</var>'s <a for=ShadowRoot>mode</a> does not match
+     <var>mode</var>, or


Is there something missing here, or should the trailing or be removed?

It should move up one bullet point I think.

Fixed. I removed the , or because I couldn't find other examples. For example, https://dom.spec.whatwg.org/#retarget just has the bullet list of options. LMK if that's the wrong conclusion to reach.

I pushed a fix for this (Domenic established a pattern to follow for new constructs) and also for the note we identified in the original issue as well as some wrapping nits.

annevk · 2024-02-13T12:26:58Z

dom.bs

+     <li><p><var>currentShadowRoot</var>'s <a for=ShadowRoot>declarative</a> is false,
+
+     <li><p><var>currentShadowRoot</var>'s <a for=ShadowRoot>mode</a> does not match
+     <var>mode</var>, or


It should move up one bullet point I think.

dom.bs

annevk · 2024-02-13T12:28:57Z

dom.bs

@@ -4502,6 +4502,8 @@ dom-Range-extractContents, dom-Range-cloneContents -->
  <a for=ShadowRoot>clonable</a> is true:

  <ol>
+   <li><p>Assert: <var>copy</var> is not a <a for=Element>shadow host</a>.


(It's weird that this has for=Element, but that's a pre-existing issue.)

Want me to change something?

If you want to take it on, it should be a separate PR making it a standalone term that doesn't belong to Element.

annevk

I'll merge this ~24h from now unless anyone has any further feedback.

https://bugs.webkit.org/show_bug.cgi?id=269361 Reviewed by Ryosuke Niwa. This makes the following changes: - Adds the new shadowrootclonable attribute to opt into a declarative shadow root being clonable. - As a result, declarative shadow roots are no longer clonable by default. Web developers will have to explicitly opt in. - When attachShadow() is called on a shadow host with an existing declarative tree, throw if mode is a mismatch. - In attachShadow() throw first for mode being set to "user-agent" as this is to be caught by the binding layer in theory. - And finally, only attach a declarative shadow root successfully for the first template element. New tests are upstreamed here: web-platform-tests/wpt#44568 Specification changes are here (not all have landed yet as various nits are still being addressed, but all have agreement): - whatwg/html#10117 - whatwg/html#10069 - whatwg/dom#1246 * LayoutTests/imported/w3c/web-platform-tests/scroll-animations/css/scroll-timeline-name-shadow.html: * LayoutTests/imported/w3c/web-platform-tests/scroll-animations/css/view-timeline-name-shadow.html: * LayoutTests/imported/w3c/web-platform-tests/shadow-dom/declarative/declarative-shadow-dom-attachment-expected.txt: * LayoutTests/imported/w3c/web-platform-tests/shadow-dom/declarative/declarative-shadow-dom-basic-expected.txt: * LayoutTests/imported/w3c/web-platform-tests/shadow-dom/declarative/declarative-shadow-dom-repeats-2-expected.txt: Added. * LayoutTests/imported/w3c/web-platform-tests/shadow-dom/declarative/declarative-shadow-dom-repeats-2.html: Added. * LayoutTests/imported/w3c/web-platform-tests/shadow-dom/declarative/declarative-shadow-dom-repeats-expected.txt: * LayoutTests/imported/w3c/web-platform-tests/shadow-dom/declarative/declarative-shadow-dom-repeats.html: * LayoutTests/imported/w3c/web-platform-tests/shadow-dom/declarative/w3c-import.log: * LayoutTests/imported/w3c/web-platform-tests/shadow-dom/shadow-root-clonable-expected.txt: * Source/WebCore/dom/Element.cpp: * Source/WebCore/dom/Element.h: * Source/WebCore/html/HTMLAttributeNames.in: * Source/WebCore/html/HTMLTemplateElement.cpp: (WebCore::HTMLTemplateElement::attachAsDeclarativeShadowRootIfNeeded): * Source/WebCore/html/parser/HTMLConstructionSite.cpp: (WebCore::HTMLConstructionSite::insertHTMLTemplateElement): Canonical link: https://commits.webkit.org/274727@main

…re opt-in, a=testonly Automatic update from web-platform-tests Change the behavior of clonable to be more opt-in See the discussion here: whatwg/html#10107 (comment) The existing *shipped* behavior (i.e. before the `clonable` concept was introduced) was that any declarative shadow root *within a `<template>`* would be automatically cloned, but no others. The semi-new behavior is the `clonable` bit concept, in which all declarative shadow roots have their `clonable` bit set to true, so they automatically get cloned by `cloneNode()`. That's regardless of whether they are inside or outside a template. The new consensus is that the "semi-new" clonable behavior is likely web-incompatible, because clones will just start getting shadow roots included. Plus it wasn't very developer-desirable. The new consensus is therefore to add a `shadowrootclonable` attribute for declarative shadow dom that allows a shadow root to opt-in to this behavior, but the default for all shadow roots will be `clonable=false`. This CL implements the new consensus behind the ShadowRootClonable flag. If the flag is false, the "shipped" behavior will be emulated via setting `clonable` in an equivalent way. See these three spec PRs: whatwg/dom#1246 whatwg/html#10069 whatwg/html#10117 Bug: 1510466 Change-Id: Ice7c7579094eb08b882c4bb44f93045f23b8f222 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5260748 Reviewed-by: David Baron <dbaron@chromium.org> Auto-Submit: Mason Freed <masonf@chromium.org> Commit-Queue: Mason Freed <masonf@chromium.org> Cr-Commit-Position: refs/heads/main@{#1258910} -- wpt-commits: 33d11f1db34802fda00e64ddeb0b7ef040cf65be wpt-pr: 44369

…re opt-in, a=testonly Automatic update from web-platform-tests Change the behavior of clonable to be more opt-in See the discussion here: whatwg/html#10107 (comment) The existing *shipped* behavior (i.e. before the `clonable` concept was introduced) was that any declarative shadow root *within a `<template>`* would be automatically cloned, but no others. The semi-new behavior is the `clonable` bit concept, in which all declarative shadow roots have their `clonable` bit set to true, so they automatically get cloned by `cloneNode()`. That's regardless of whether they are inside or outside a template. The new consensus is that the "semi-new" clonable behavior is likely web-incompatible, because clones will just start getting shadow roots included. Plus it wasn't very developer-desirable. The new consensus is therefore to add a `shadowrootclonable` attribute for declarative shadow dom that allows a shadow root to opt-in to this behavior, but the default for all shadow roots will be `clonable=false`. This CL implements the new consensus behind the ShadowRootClonable flag. If the flag is false, the "shipped" behavior will be emulated via setting `clonable` in an equivalent way. See these three spec PRs: whatwg/dom#1246 whatwg/html#10069 whatwg/html#10117 Bug: 1510466 Change-Id: Ice7c7579094eb08b882c4bb44f93045f23b8f222 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5260748 Reviewed-by: David Baron <dbaronchromium.org> Auto-Submit: Mason Freed <masonfchromium.org> Commit-Queue: Mason Freed <masonfchromium.org> Cr-Commit-Position: refs/heads/main{#1258910} -- wpt-commits: 33d11f1db34802fda00e64ddeb0b7ef040cf65be wpt-pr: 44369 UltraBlame original commit: 7d4902dfa32c013568c445861c332c29e4c1134f

See the discussion here: whatwg/html#10107 (comment) The existing *shipped* behavior (i.e. before the `clonable` concept was introduced) was that any declarative shadow root *within a `<template>`* would be automatically cloned, but no others. The semi-new behavior is the `clonable` bit concept, in which all declarative shadow roots have their `clonable` bit set to true, so they automatically get cloned by `cloneNode()`. That's regardless of whether they are inside or outside a template. The new consensus is that the "semi-new" clonable behavior is likely web-incompatible, because clones will just start getting shadow roots included. Plus it wasn't very developer-desirable. The new consensus is therefore to add a `shadowrootclonable` attribute for declarative shadow dom that allows a shadow root to opt-in to this behavior, but the default for all shadow roots will be `clonable=false`. This CL implements the new consensus behind the ShadowRootClonable flag. If the flag is false, the "shipped" behavior will be emulated via setting `clonable` in an equivalent way. See these three spec PRs: whatwg/dom#1246 whatwg/html#10069 whatwg/html#10117 Bug: 1510466 Change-Id: Ice7c7579094eb08b882c4bb44f93045f23b8f222 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5260748 Reviewed-by: David Baron <dbaron@chromium.org> Auto-Submit: Mason Freed <masonf@chromium.org> Commit-Queue: Mason Freed <masonf@chromium.org> Cr-Commit-Position: refs/heads/main@{#1258910}

…re opt-in, a=testonly Automatic update from web-platform-tests Change the behavior of clonable to be more opt-in See the discussion here: whatwg/html#10107 (comment) The existing *shipped* behavior (i.e. before the `clonable` concept was introduced) was that any declarative shadow root *within a `<template>`* would be automatically cloned, but no others. The semi-new behavior is the `clonable` bit concept, in which all declarative shadow roots have their `clonable` bit set to true, so they automatically get cloned by `cloneNode()`. That's regardless of whether they are inside or outside a template. The new consensus is that the "semi-new" clonable behavior is likely web-incompatible, because clones will just start getting shadow roots included. Plus it wasn't very developer-desirable. The new consensus is therefore to add a `shadowrootclonable` attribute for declarative shadow dom that allows a shadow root to opt-in to this behavior, but the default for all shadow roots will be `clonable=false`. This CL implements the new consensus behind the ShadowRootClonable flag. If the flag is false, the "shipped" behavior will be emulated via setting `clonable` in an equivalent way. See these three spec PRs: whatwg/dom#1246 whatwg/html#10069 whatwg/html#10117 Bug: 1510466 Change-Id: Ice7c7579094eb08b882c4bb44f93045f23b8f222 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5260748 Reviewed-by: David Baron <dbaronchromium.org> Auto-Submit: Mason Freed <masonfchromium.org> Commit-Queue: Mason Freed <masonfchromium.org> Cr-Commit-Position: refs/heads/main{#1258910} -- wpt-commits: 33d11f1db34802fda00e64ddeb0b7ef040cf65be wpt-pr: 44369 UltraBlame original commit: 7d4902dfa32c013568c445861c332c29e4c1134f

…re opt-in, a=testonly Automatic update from web-platform-tests Change the behavior of clonable to be more opt-in See the discussion here: whatwg/html#10107 (comment) The existing *shipped* behavior (i.e. before the `clonable` concept was introduced) was that any declarative shadow root *within a `<template>`* would be automatically cloned, but no others. The semi-new behavior is the `clonable` bit concept, in which all declarative shadow roots have their `clonable` bit set to true, so they automatically get cloned by `cloneNode()`. That's regardless of whether they are inside or outside a template. The new consensus is that the "semi-new" clonable behavior is likely web-incompatible, because clones will just start getting shadow roots included. Plus it wasn't very developer-desirable. The new consensus is therefore to add a `shadowrootclonable` attribute for declarative shadow dom that allows a shadow root to opt-in to this behavior, but the default for all shadow roots will be `clonable=false`. This CL implements the new consensus behind the ShadowRootClonable flag. If the flag is false, the "shipped" behavior will be emulated via setting `clonable` in an equivalent way. See these three spec PRs: whatwg/dom#1246 whatwg/html#10069 whatwg/html#10117 Bug: 1510466 Change-Id: Ice7c7579094eb08b882c4bb44f93045f23b8f222 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5260748 Reviewed-by: David Baron <dbaron@chromium.org> Auto-Submit: Mason Freed <masonf@chromium.org> Commit-Queue: Mason Freed <masonf@chromium.org> Cr-Commit-Position: refs/heads/main@{#1258910} -- wpt-commits: 33d11f1db34802fda00e64ddeb0b7ef040cf65be wpt-pr: 44369

Two changes: 1. If two declarative shadow roots are included within a single host element, only the *first* one will remain. This is a change in behavior from before, but reached consensus [1] and hopefully won't be a breaking change for anyone. 2. If attachShadow() is used on an existing declarative shadow root, and the parameters (e.g. shadow root type, etc.) do not match, an exception is thrown. This, also, is a breaking change, but hopefully not one that gets hit. See also [1]. See [2] and [3] for the corresponding spec PRs. [1] whatwg/dom#1235 [2] whatwg/html#10069 [3] whatwg/dom#1246 Bug: 1379513,1042130 Change-Id: Ia81088227797013f9f62f5ac90f76898663b0bc4 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5191750 Commit-Queue: Mason Freed <masonf@chromium.org> Auto-Submit: Mason Freed <masonf@chromium.org> Commit-Queue: David Baron <dbaron@chromium.org> Reviewed-by: David Baron <dbaron@chromium.org> Cr-Commit-Position: refs/heads/main@{#1249214}

See the discussion here: whatwg/html#10107 (comment) The existing *shipped* behavior (i.e. before the `clonable` concept was introduced) was that any declarative shadow root *within a `<template>`* would be automatically cloned, but no others. The semi-new behavior is the `clonable` bit concept, in which all declarative shadow roots have their `clonable` bit set to true, so they automatically get cloned by `cloneNode()`. That's regardless of whether they are inside or outside a template. The new consensus is that the "semi-new" clonable behavior is likely web-incompatible, because clones will just start getting shadow roots included. Plus it wasn't very developer-desirable. The new consensus is therefore to add a `shadowrootclonable` attribute for declarative shadow dom that allows a shadow root to opt-in to this behavior, but the default for all shadow roots will be `clonable=false`. This CL implements the new consensus behind the ShadowRootClonable flag. If the flag is false, the "shipped" behavior will be emulated via setting `clonable` in an equivalent way. See these three spec PRs: whatwg/dom#1246 whatwg/html#10069 whatwg/html#10117 Bug: 1510466 Change-Id: Ice7c7579094eb08b882c4bb44f93045f23b8f222 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5260748 Reviewed-by: David Baron <dbaron@chromium.org> Auto-Submit: Mason Freed <masonf@chromium.org> Commit-Queue: Mason Freed <masonf@chromium.org> Cr-Commit-Position: refs/heads/main@{#1258910}

mfreed7 mentioned this pull request Jan 16, 2024

Modify the logic for double-declarative shadow root attachment whatwg/html#10069

Merged

5 tasks

chromium-wpt-export-bot mentioned this pull request Jan 16, 2024

Disallow multiple declarative roots and mismatched imperative ones web-platform-tests/wpt#43958

Merged

mfreed7 mentioned this pull request Jan 18, 2024

Should attachShadow throw or override when an existing declarative shadow root doesn't match? #1235

Closed

annevk reviewed Jan 22, 2024

View reviewed changes

dom.bs Outdated Show resolved Hide resolved

dom.bs Outdated Show resolved Hide resolved

dom.bs Outdated Show resolved Hide resolved

Mason Freed added 3 commits January 26, 2024 17:23

Just assert that a cloned node is not a shadow host

cbad36e

Address comments

13198db

mfreed7 force-pushed the attach_shadow branch from ffca69f to 13198db Compare January 27, 2024 01:34

annevk reviewed Jan 29, 2024

View reviewed changes

dom.bs Outdated Show resolved Hide resolved

dom.bs Outdated Show resolved Hide resolved

dom.bs Outdated Show resolved Hide resolved

emilio approved these changes Jan 29, 2024

View reviewed changes

Address comments

1c63c4f

emilio mentioned this pull request Jan 29, 2024

Should there be an opt-out for declarative shadow roots having clonable=true? whatwg/html#10107

Closed

Fix slotAssignment to be a string

149f31c

mfreed7 commented Feb 2, 2024

View reviewed changes

dom.bs Show resolved Hide resolved

chromium-wpt-export-bot mentioned this pull request Feb 2, 2024

Change the behavior of clonable to be more opt-in web-platform-tests/wpt#44369

Merged

Remove checks except for mode

1c0b37c

petervanderbeken reviewed Feb 12, 2024

View reviewed changes

annevk reviewed Feb 13, 2024

View reviewed changes

annevk mentioned this pull request Feb 14, 2024

Add shadowrootclonable and align with declarative shadow root changes WebKit/WebKit#24412

Merged

Address comments

16dcb39

nits

30a0f3b

annevk approved these changes Feb 15, 2024

View reviewed changes

annevk added the topic: shadow Relates to shadow trees (as defined in DOM) label Feb 16, 2024

annevk merged commit 73995b1 into whatwg:main Feb 16, 2024
2 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Enforce same parameters for attachShadow on declarative shadow root #1246

Enforce same parameters for attachShadow on declarative shadow root #1246

mfreed7 commented Jan 16, 2024 •

edited by pr-preview bot

annevk commented Jan 22, 2024

mfreed7 commented Jan 27, 2024

annevk left a comment

emilio left a comment

mfreed7 commented Jan 29, 2024

annevk commented Jan 30, 2024

petervanderbeken Feb 12, 2024

annevk Feb 13, 2024

mfreed7 Feb 15, 2024

annevk Feb 15, 2024 •

edited

annevk Feb 13, 2024

annevk Feb 13, 2024

mfreed7 Feb 15, 2024

annevk Feb 15, 2024

annevk left a comment

Enforce same parameters for attachShadow on declarative shadow root #1246

Enforce same parameters for attachShadow on declarative shadow root #1246

Conversation

mfreed7 commented Jan 16, 2024 • edited by pr-preview bot

annevk commented Jan 22, 2024

mfreed7 commented Jan 27, 2024

annevk left a comment

Choose a reason for hiding this comment

emilio left a comment

Choose a reason for hiding this comment

mfreed7 commented Jan 29, 2024

annevk commented Jan 30, 2024

petervanderbeken Feb 12, 2024

Choose a reason for hiding this comment

annevk Feb 13, 2024

Choose a reason for hiding this comment

mfreed7 Feb 15, 2024

Choose a reason for hiding this comment

annevk Feb 15, 2024 • edited

Choose a reason for hiding this comment

annevk Feb 13, 2024

Choose a reason for hiding this comment

annevk Feb 13, 2024

Choose a reason for hiding this comment

mfreed7 Feb 15, 2024

Choose a reason for hiding this comment

annevk Feb 15, 2024

Choose a reason for hiding this comment

annevk left a comment

Choose a reason for hiding this comment

mfreed7 commented Jan 16, 2024 •

edited by pr-preview bot

annevk Feb 15, 2024 •

edited