Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add declarative Shadow DOM features #892

Merged
merged 3 commits into from
Oct 29, 2023
Merged

Conversation

mfreed7
Copy link
Contributor

@mfreed7 mfreed7 commented Sep 15, 2020

The explainer for this feature is here: https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md
The issue discussion is here: #831
There is a corresponding Pull Request for the HTML spec that goes along with this PR.

Note, due to some local branch issues, this is a duplicate of PR 858. Please see that PR for more history and review comments here. In particular, the last comment there is from me - it is my belief that I've addressed all of the outstanding comments.

Closes #1137.


Preview | Diff

@mfreed7 mfreed7 mentioned this pull request Oct 5, 2020
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Nov 4, 2020
This CL implements most of the suggestions from [1], which effectively
block declarative Shadow DOM from being used by any fragment parser
entry point, unless an explicit opt-in is toggled.

The opt-ins include:
 - DOMParser.allowDeclarativeShadowDom = true;
 - HTMLTemplateElement.allowDeclarativeShadowDom = true;
 - XMLHttpRequest.allowDeclarativeShadowDom = true;
 - DocumentFragment.allowDeclarativeShadowDom = true;
 - Document.allowDeclarativeShadowDom = true; // For innerHTML
 - A new <iframe> sandbox flag: allow-declarative-shadow-dom

This mitigates the potential client-side XSS sanitizer bypass detailed
in the explainer and at [1]. Assuming these changes are functional,
and mitigate the issue, this new behavior will be folded into the
spec PRs at [2] and [3]. But given the security implications of the
existing code, I'd like to get this landed first.

[1] whatwg/dom#912 (comment)
[2] whatwg/html#5465
[3] whatwg/dom#892

Bug: 1042130
Change-Id: I088f28f63078a0d26e354a4442494c0132b47ffc
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Nov 5, 2020
This CL implements most of the suggestions from [1], which effectively
block declarative Shadow DOM from being used by any fragment parser
entry point, unless an explicit opt-in is toggled.

The opt-ins include:
 - DOMParser.allowDeclarativeShadowDom = true;
 - HTMLTemplateElement.allowDeclarativeShadowDom = true;
 - XMLHttpRequest.allowDeclarativeShadowDom = true;
 - DocumentFragment.allowDeclarativeShadowDom = true;
 - Document.allowDeclarativeShadowDom = true; // For innerHTML
 - A new <iframe> sandbox flag: allow-declarative-shadow-dom

This mitigates the potential client-side XSS sanitizer bypass detailed
in the explainer and at [1]. Assuming these changes are functional,
and mitigate the issue, this new behavior will be folded into the
spec PRs at [2] and [3]. But given the security implications of the
existing code, I'd like to get this landed first.

[1] whatwg/dom#912 (comment)
[2] whatwg/html#5465
[3] whatwg/dom#892

Bug: 1042130
Change-Id: I088f28f63078a0d26e354a4442494c0132b47ffc
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Nov 5, 2020
This CL implements most of the suggestions from [1], which effectively
block declarative Shadow DOM from being used by any fragment parser
entry point, unless an explicit opt-in is toggled.

The opt-ins include:
 - DOMParser.allowDeclarativeShadowDom = true;
 - HTMLTemplateElement.allowDeclarativeShadowDom = true;
 - XMLHttpRequest.allowDeclarativeShadowDom = true;
 - DocumentFragment.allowDeclarativeShadowDom = true;
 - Document.allowDeclarativeShadowDom = true; // For innerHTML
 - A new <iframe> sandbox flag: allow-declarative-shadow-dom

This mitigates the potential client-side XSS sanitizer bypass detailed
in the explainer and at [1]. Assuming these changes are functional,
and mitigate the issue, this new behavior will be folded into the
spec PRs at [2] and [3]. But given the security implications of the
existing code, I'd like to get this landed first.

[1] whatwg/dom#912 (comment)
[2] whatwg/html#5465
[3] whatwg/dom#892

Bug: 1042130
Change-Id: I088f28f63078a0d26e354a4442494c0132b47ffc
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Nov 5, 2020
This CL implements most of the suggestions from [1], which effectively
block declarative Shadow DOM from being used by any fragment parser
entry point, unless an explicit opt-in is toggled.

The opt-ins include:
 - DOMParser.allowDeclarativeShadowDom = true;
 - HTMLTemplateElement.allowDeclarativeShadowDom = true;
 - XMLHttpRequest.allowDeclarativeShadowDom = true;
 - DocumentFragment.allowDeclarativeShadowDom = true;
 - Document.allowDeclarativeShadowDom = true; // For innerHTML
 - A new <iframe> sandbox flag: allow-declarative-shadow-dom

This mitigates the potential client-side XSS sanitizer bypass detailed
in the explainer and at [1]. Assuming these changes are functional,
and mitigate the issue, this new behavior will be folded into the
spec PRs at [2] and [3]. But given the security implications of the
existing code, I'd like to get this landed first.

[1] whatwg/dom#912 (comment)
[2] whatwg/html#5465
[3] whatwg/dom#892

Bug: 1042130
Change-Id: I088f28f63078a0d26e354a4442494c0132b47ffc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2513525
Commit-Queue: Mason Freed <masonfreed@chromium.org>
Reviewed-by: Kouhei Ueno <kouhei@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#824591}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Nov 5, 2020
This CL implements most of the suggestions from [1], which effectively
block declarative Shadow DOM from being used by any fragment parser
entry point, unless an explicit opt-in is toggled.

The opt-ins include:
 - DOMParser.allowDeclarativeShadowDom = true;
 - HTMLTemplateElement.allowDeclarativeShadowDom = true;
 - XMLHttpRequest.allowDeclarativeShadowDom = true;
 - DocumentFragment.allowDeclarativeShadowDom = true;
 - Document.allowDeclarativeShadowDom = true; // For innerHTML
 - A new <iframe> sandbox flag: allow-declarative-shadow-dom

This mitigates the potential client-side XSS sanitizer bypass detailed
in the explainer and at [1]. Assuming these changes are functional,
and mitigate the issue, this new behavior will be folded into the
spec PRs at [2] and [3]. But given the security implications of the
existing code, I'd like to get this landed first.

[1] whatwg/dom#912 (comment)
[2] whatwg/html#5465
[3] whatwg/dom#892

Bug: 1042130
Change-Id: I088f28f63078a0d26e354a4442494c0132b47ffc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2513525
Commit-Queue: Mason Freed <masonfreed@chromium.org>
Reviewed-by: Kouhei Ueno <kouhei@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#824591}
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this pull request Nov 7, 2020
…arsing to be opt-in, a=testonly

Automatic update from web-platform-tests
Change declarative Shadow DOM fragment parsing to be opt-in

This CL implements most of the suggestions from [1], which effectively
block declarative Shadow DOM from being used by any fragment parser
entry point, unless an explicit opt-in is toggled.

The opt-ins include:
 - DOMParser.allowDeclarativeShadowDom = true;
 - HTMLTemplateElement.allowDeclarativeShadowDom = true;
 - XMLHttpRequest.allowDeclarativeShadowDom = true;
 - DocumentFragment.allowDeclarativeShadowDom = true;
 - Document.allowDeclarativeShadowDom = true; // For innerHTML
 - A new <iframe> sandbox flag: allow-declarative-shadow-dom

This mitigates the potential client-side XSS sanitizer bypass detailed
in the explainer and at [1]. Assuming these changes are functional,
and mitigate the issue, this new behavior will be folded into the
spec PRs at [2] and [3]. But given the security implications of the
existing code, I'd like to get this landed first.

[1] whatwg/dom#912 (comment)
[2] whatwg/html#5465
[3] whatwg/dom#892

Bug: 1042130
Change-Id: I088f28f63078a0d26e354a4442494c0132b47ffc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2513525
Commit-Queue: Mason Freed <masonfreed@chromium.org>
Reviewed-by: Kouhei Ueno <kouhei@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#824591}

--

wpt-commits: b13461b9a46b46eb1b092a58bde2b10418e7a73d
wpt-pr: 26398
sidvishnoi pushed a commit to sidvishnoi/gecko-webmonetization that referenced this pull request Nov 10, 2020
…arsing to be opt-in, a=testonly

Automatic update from web-platform-tests
Change declarative Shadow DOM fragment parsing to be opt-in

This CL implements most of the suggestions from [1], which effectively
block declarative Shadow DOM from being used by any fragment parser
entry point, unless an explicit opt-in is toggled.

The opt-ins include:
 - DOMParser.allowDeclarativeShadowDom = true;
 - HTMLTemplateElement.allowDeclarativeShadowDom = true;
 - XMLHttpRequest.allowDeclarativeShadowDom = true;
 - DocumentFragment.allowDeclarativeShadowDom = true;
 - Document.allowDeclarativeShadowDom = true; // For innerHTML
 - A new <iframe> sandbox flag: allow-declarative-shadow-dom

This mitigates the potential client-side XSS sanitizer bypass detailed
in the explainer and at [1]. Assuming these changes are functional,
and mitigate the issue, this new behavior will be folded into the
spec PRs at [2] and [3]. But given the security implications of the
existing code, I'd like to get this landed first.

[1] whatwg/dom#912 (comment)
[2] whatwg/html#5465
[3] whatwg/dom#892

Bug: 1042130
Change-Id: I088f28f63078a0d26e354a4442494c0132b47ffc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2513525
Commit-Queue: Mason Freed <masonfreed@chromium.org>
Reviewed-by: Kouhei Ueno <kouhei@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#824591}

--

wpt-commits: b13461b9a46b46eb1b092a58bde2b10418e7a73d
wpt-pr: 26398
@mfreed7
Copy link
Contributor Author

mfreed7 commented Nov 24, 2020

This PR has been updated to include the "opt-in" mechanics described in #912. The changes I made here roughly match the current implementation of Chromium, so I'm hoping they're functional. But comments appreciated.

Here, I am unable to figure out how to get the "magic" {{include shadow roots state}} to link over to the equivalent section of HTML. I get a build error there. I cannot find where in dom.bs these strings are defined.

dom.bs Outdated Show resolved Hide resolved
@annevk
Copy link
Member

annevk commented Dec 3, 2020

As for the build error, once HTML is indexed by Shepherd you should be able to cross-reference, but that does mean broken builds until that happens unfortunately. We don't have a good workaround. (One of the nice things about Bikeshed is that it doesn't need a full local index of terms defined elsewhere.)

@mfreed7
Copy link
Contributor Author

mfreed7 commented Dec 4, 2020

As for the build error, once HTML is indexed by Shepherd you should be able to cross-reference, but that does mean broken builds until that happens unfortunately. We don't have a good workaround. (One of the nice things about Bikeshed is that it doesn't need a full local index of terms defined elsewhere.)

Ahh ok, that makes sense. Thanks.

Base automatically changed from master to main January 15, 2021 07:32
dom.bs Outdated Show resolved Hide resolved
@vekunz
Copy link

vekunz commented Feb 14, 2022

Is there still progress here or is the topic dead?

@mfreed7
Copy link
Contributor Author

mfreed7 commented Mar 26, 2022

Is there still progress here or is the topic dead?

This feature is fully shipped on chromium browsers. The other implementers are waiting for production performance data, to help convince them that SSR (and DSD) offers actual performance benefits on real sites. That’s despite recent blog posts that seem to have a different view:

We also continue to see room for improving or adding primitives that provide declarative alternatives for situations that currently require JavaScript, such as…

This feature is not dead.

@annevk
Copy link
Member

annevk commented Apr 4, 2022

@mfreed7 I think that's a mischaracterization of Mozilla's views and seems somewhat unwarranted? We've been plenty supportive of exploring declarative web components. We're just not quite convinced of declarative shadow trees in isolation.

@mfreed7
Copy link
Contributor Author

mfreed7 commented Apr 5, 2022

@mfreed7 I think that's a mischaracterization of Mozilla's views and seems somewhat unwarranted? We've been plenty supportive of exploring declarative web components. We're just not quite convinced of declarative shadow trees in isolation.

I’m sorry you feel that way! I honestly didn’t mean to mischaracterize anything. (The link to your blog post might not have been fair, I suppose, though it is a very public blog post.) But I’ve been working for ~a year trying to gather production performance data on this feature precisely because I thought this was Mozilla’s view. E.g. see the latest comment from @smaug---- on the issue thread, which is talking about performance concerns related to (declarative/all) shadow roots. Since declarative custom elements (which are vaporware at this point) would almost surely build on top of declarative shadow dom, I would think those concerns are shared, no?

@mfreed7
Copy link
Contributor Author

mfreed7 commented Oct 4, 2023

This needed rebasing due to #1200.

Gah, sorry! I read the above comment as "This needs rebasing..." so I just went for it. I didn't notice that you also pushed some things to my branch. Glad you got it back - thanks. And sorry for the trouble.

@mfreed7
Copy link
Contributor Author

mfreed7 commented Oct 4, 2023

Wait what? Shit. I did the work to rebase. Your subsequent force push overwrote a number of fixes: https://github.com/whatwg/dom/compare/17ede93b019cb319c9b786dfce950c2ba17ec3c3..f01b44dd4d6e88d39216a36c4cb47d58125301d2.

All of these changes look good, much appreciated.

annevk pushed a commit to whatwg/html that referenced this pull request Oct 29, 2023
A longer explanation of this feature can be found at https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md. It was originally discussed in whatwg/dom#831.

Corresponding DOM PR: whatwg/dom#892.

Tests: shadow-dom/declarative in WPT with web-platform-tests/wpt#42833 being the latest PR as of this commit.

Closes #7069.
@annevk annevk merged commit ca756e0 into whatwg:main Oct 29, 2023
3 checks passed
@annevk annevk added topic: nodes topic: shadow Relates to shadow trees (as defined in DOM) and removed do not merge yet Pull request must not be merged per rationale in comment labels Oct 29, 2023
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Jan 26, 2024
This landed in the latest declarative shadow dom spec PR:

  whatwg/dom#892

and was discussed here:

  whatwg/dom#1137

This CL adds support for that, behind a new ShadowRootClonable
flag. There was already a very basic test, but I added a few
more cases.

This should be fairly web compatible, but there is a risk since with
this feature enabled, declarative shadow roots in the main document
(as opposed to in a <template> element) will now be cloned. I will
launch this feature carefully.

Fixed: 1510466
Change-Id: Ie25b72f369ca0542555f91010b0f22d295403728
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Jan 26, 2024
This landed in the latest declarative shadow dom spec PR:

  whatwg/dom#892

and was discussed here:

  whatwg/dom#1137

This CL adds support for that, behind a new ShadowRootClonable
flag. There was already a very basic test, but I added a few
more cases.

This should be fairly web compatible, but there is a risk since with
this feature enabled, declarative shadow roots in the main document
(as opposed to in a <template> element) will now be cloned. I will
launch this feature carefully.

Fixed: 1510466
Change-Id: Ie25b72f369ca0542555f91010b0f22d295403728
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Jan 26, 2024
This landed in the latest declarative shadow dom spec PR:

  whatwg/dom#892

and was discussed here:

  whatwg/dom#1137

This CL adds support for that, behind a new ShadowRootClonable
flag. There was already a very basic test, but I added a few
more cases.

This should be fairly web compatible, but there is a risk since with
this feature enabled, declarative shadow roots in the main document
(as opposed to in a <template> element) will now be cloned. I will
launch this feature carefully.

Fixed: 1510466
Change-Id: Ie25b72f369ca0542555f91010b0f22d295403728
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Jan 26, 2024
This landed in the latest declarative shadow dom spec PR:

  whatwg/dom#892

and was discussed here:

  whatwg/dom#1137

This CL adds support for that, behind a new ShadowRootClonable
flag. There was already a very basic test, but I added a few
more cases.

This should be fairly web compatible, but there is a risk since with
this feature enabled, declarative shadow roots in the main document
(as opposed to in a <template> element) will now be cloned. I will
launch this feature carefully. Safari has already shipped, and Gecko
has implemented this and plans to ship soon.

Fixed: 1510466
Change-Id: Ie25b72f369ca0542555f91010b0f22d295403728
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Jan 26, 2024
This landed in the latest declarative shadow dom spec PR:

  whatwg/dom#892

and was discussed here:

  whatwg/dom#1137

This CL adds support for that, behind a new ShadowRootClonable
flag. There was already a very basic test, but I added a few
more cases.

This should be fairly web compatible, but there is a risk since with
this feature enabled, declarative shadow roots in the main document
(as opposed to in a <template> element) will now be cloned. I will
launch this feature carefully. Safari has already shipped, and Gecko
has implemented this and plans to ship soon.

Fixed: 1510466
Change-Id: Ie25b72f369ca0542555f91010b0f22d295403728
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Jan 26, 2024
This landed in the these two spec PRs:

  whatwg/dom#892
  whatwg/dom#1237

and was discussed here:

  whatwg/dom#1137
  whatwg/dom#1236

This CL adds support for clonable, behind a new ShadowRootClonable
flag. There was already a very basic test, but I added a few
more cases.

This should be fairly web compatible, but there is a risk since with
this feature enabled, declarative shadow roots in the main document
(as opposed to in a <template> element) will now be cloned. I will
launch this feature carefully. Safari has already shipped, and Gecko
has implemented this and plans to ship soon.

Fixed: 1510466
Change-Id: Ie25b72f369ca0542555f91010b0f22d295403728
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Jan 26, 2024
This landed in the these two spec PRs:

  whatwg/dom#892
  whatwg/dom#1237

and was discussed here:

  whatwg/dom#1137
  whatwg/dom#1236

This CL adds support for clonable, behind a new ShadowRootClonable
flag. There was already a very basic test, but I added a few
more cases.

This should be fairly web compatible, but there is a risk since with
this feature enabled, declarative shadow roots in the main document
(as opposed to in a <template> element) will now be cloned. I will
launch this feature carefully. Safari has already shipped, and Gecko
has implemented this and plans to ship soon.

Fixed: 1510466
Change-Id: Ie25b72f369ca0542555f91010b0f22d295403728
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Jan 26, 2024
This landed in the these two spec PRs:

  whatwg/dom#892
  whatwg/dom#1237

and was discussed here:

  whatwg/dom#1137
  whatwg/dom#1236

This CL adds support for clonable, behind a new ShadowRootClonable
flag. There was already a very basic test, but I added a few
more cases.

This should be fairly web compatible, but there is a risk since with
this feature enabled, declarative shadow roots in the main document
(as opposed to in a <template> element) will now be cloned. I will
launch this feature carefully. Safari has already shipped, and Gecko
has implemented this and plans to ship soon.

Chromestatus:
https://chromestatus.com/feature/5161435196030976

I2P:
https://groups.google.com/a/chromium.org/g/blink-dev/c/nZhPt0ePCAA

Fixed: 1510466
Change-Id: Ie25b72f369ca0542555f91010b0f22d295403728
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Jan 27, 2024
This landed in the these two spec PRs:

  whatwg/dom#892
  whatwg/dom#1237

and was discussed here:

  whatwg/dom#1137
  whatwg/dom#1236

This CL adds support for clonable, behind a new ShadowRootClonable
flag. There was already a very basic test, but I added a few
more cases.

This should be fairly web compatible, but there is a risk since with
this feature enabled, declarative shadow roots in the main document
(as opposed to in a <template> element) will now be cloned. I will
launch this feature carefully. Safari has already shipped, and Gecko
has implemented this and plans to ship soon.

Chromestatus:
https://chromestatus.com/feature/5161435196030976

I2P:
https://groups.google.com/a/chromium.org/g/blink-dev/c/nZhPt0ePCAA

Fixed: 1510466
Change-Id: Ie25b72f369ca0542555f91010b0f22d295403728
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Jan 27, 2024
This landed in the these two spec PRs:

  whatwg/dom#892
  whatwg/dom#1237

and was discussed here:

  whatwg/dom#1137
  whatwg/dom#1236

This CL adds support for clonable, behind a new ShadowRootClonable
flag. There was already a very basic test, but I added a few
more cases.

This should be fairly web compatible, but there is a risk since with
this feature enabled, declarative shadow roots in the main document
(as opposed to in a <template> element) will now be cloned. I will
launch this feature carefully. Safari has already shipped, and Gecko
has implemented this and plans to ship soon.

Chromestatus:
https://chromestatus.com/feature/5161435196030976

I2P:
https://groups.google.com/a/chromium.org/g/blink-dev/c/nZhPt0ePCAA

Fixed: 1510466
Change-Id: Ie25b72f369ca0542555f91010b0f22d295403728
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Jan 27, 2024
This landed in the these two spec PRs:

  whatwg/dom#892
  whatwg/dom#1237

and was discussed here:

  whatwg/dom#1137
  whatwg/dom#1236

This CL adds support for clonable, behind a new ShadowRootClonable
flag. There was already a very basic test, but I added a few
more cases.

This should be fairly web compatible, but there is a risk since with
this feature enabled, declarative shadow roots in the main document
(as opposed to in a <template> element) will now be cloned. I will
launch this feature carefully. Safari has already shipped, and Gecko
has implemented this and plans to ship soon.

Chromestatus:
https://chromestatus.com/feature/5161435196030976

I2P:
https://groups.google.com/a/chromium.org/g/blink-dev/c/nZhPt0ePCAA

Bug: 1510466
Change-Id: Ie25b72f369ca0542555f91010b0f22d295403728
aarongable pushed a commit to chromium/chromium that referenced this pull request Jan 27, 2024
This landed in the these two spec PRs:

  whatwg/dom#892
  whatwg/dom#1237

and was discussed here:

  whatwg/dom#1137
  whatwg/dom#1236

This CL adds support for clonable, behind a new ShadowRootClonable
flag. There was already a very basic test, but I added a few
more cases.

This should be fairly web compatible, but there is a risk since with
this feature enabled, declarative shadow roots in the main document
(as opposed to in a <template> element) will now be cloned. I will
launch this feature carefully. Safari has already shipped, and Gecko
has implemented this and plans to ship soon.

Chromestatus:
https://chromestatus.com/feature/5161435196030976

I2P:
https://groups.google.com/a/chromium.org/g/blink-dev/c/nZhPt0ePCAA

Bug: 1510466
Change-Id: Ie25b72f369ca0542555f91010b0f22d295403728
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5239277
Auto-Submit: Mason Freed <masonf@chromium.org>
Reviewed-by: David Baron <dbaron@chromium.org>
Commit-Queue: David Baron <dbaron@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1253059}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Jan 27, 2024
This landed in the these two spec PRs:

  whatwg/dom#892
  whatwg/dom#1237

and was discussed here:

  whatwg/dom#1137
  whatwg/dom#1236

This CL adds support for clonable, behind a new ShadowRootClonable
flag. There was already a very basic test, but I added a few
more cases.

This should be fairly web compatible, but there is a risk since with
this feature enabled, declarative shadow roots in the main document
(as opposed to in a <template> element) will now be cloned. I will
launch this feature carefully. Safari has already shipped, and Gecko
has implemented this and plans to ship soon.

Chromestatus:
https://chromestatus.com/feature/5161435196030976

I2P:
https://groups.google.com/a/chromium.org/g/blink-dev/c/nZhPt0ePCAA

Bug: 1510466
Change-Id: Ie25b72f369ca0542555f91010b0f22d295403728
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5239277
Auto-Submit: Mason Freed <masonf@chromium.org>
Reviewed-by: David Baron <dbaron@chromium.org>
Commit-Queue: David Baron <dbaron@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1253059}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Jan 27, 2024
This landed in the these two spec PRs:

  whatwg/dom#892
  whatwg/dom#1237

and was discussed here:

  whatwg/dom#1137
  whatwg/dom#1236

This CL adds support for clonable, behind a new ShadowRootClonable
flag. There was already a very basic test, but I added a few
more cases.

This should be fairly web compatible, but there is a risk since with
this feature enabled, declarative shadow roots in the main document
(as opposed to in a <template> element) will now be cloned. I will
launch this feature carefully. Safari has already shipped, and Gecko
has implemented this and plans to ship soon.

Chromestatus:
https://chromestatus.com/feature/5161435196030976

I2P:
https://groups.google.com/a/chromium.org/g/blink-dev/c/nZhPt0ePCAA

Bug: 1510466
Change-Id: Ie25b72f369ca0542555f91010b0f22d295403728
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5239277
Auto-Submit: Mason Freed <masonf@chromium.org>
Reviewed-by: David Baron <dbaron@chromium.org>
Commit-Queue: David Baron <dbaron@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1253059}
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this pull request Jan 29, 2024
… flag, a=testonly

Automatic update from web-platform-tests
Add support for the shadow root clonable flag

This landed in the these two spec PRs:

  whatwg/dom#892
  whatwg/dom#1237

and was discussed here:

  whatwg/dom#1137
  whatwg/dom#1236

This CL adds support for clonable, behind a new ShadowRootClonable
flag. There was already a very basic test, but I added a few
more cases.

This should be fairly web compatible, but there is a risk since with
this feature enabled, declarative shadow roots in the main document
(as opposed to in a <template> element) will now be cloned. I will
launch this feature carefully. Safari has already shipped, and Gecko
has implemented this and plans to ship soon.

Chromestatus:
https://chromestatus.com/feature/5161435196030976

I2P:
https://groups.google.com/a/chromium.org/g/blink-dev/c/nZhPt0ePCAA

Bug: 1510466
Change-Id: Ie25b72f369ca0542555f91010b0f22d295403728
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5239277
Auto-Submit: Mason Freed <masonf@chromium.org>
Reviewed-by: David Baron <dbaron@chromium.org>
Commit-Queue: David Baron <dbaron@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1253059}

--

wpt-commits: adc1ac02e6d8e080508325ab4525bab8d09177a6
wpt-pr: 44216
ErichDonGubler pushed a commit to erichdongubler-mozilla/firefox that referenced this pull request Jan 30, 2024
… flag, a=testonly

Automatic update from web-platform-tests
Add support for the shadow root clonable flag

This landed in the these two spec PRs:

  whatwg/dom#892
  whatwg/dom#1237

and was discussed here:

  whatwg/dom#1137
  whatwg/dom#1236

This CL adds support for clonable, behind a new ShadowRootClonable
flag. There was already a very basic test, but I added a few
more cases.

This should be fairly web compatible, but there is a risk since with
this feature enabled, declarative shadow roots in the main document
(as opposed to in a <template> element) will now be cloned. I will
launch this feature carefully. Safari has already shipped, and Gecko
has implemented this and plans to ship soon.

Chromestatus:
https://chromestatus.com/feature/5161435196030976

I2P:
https://groups.google.com/a/chromium.org/g/blink-dev/c/nZhPt0ePCAA

Bug: 1510466
Change-Id: Ie25b72f369ca0542555f91010b0f22d295403728
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5239277
Auto-Submit: Mason Freed <masonf@chromium.org>
Reviewed-by: David Baron <dbaron@chromium.org>
Commit-Queue: David Baron <dbaron@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1253059}

--

wpt-commits: adc1ac02e6d8e080508325ab4525bab8d09177a6
wpt-pr: 44216
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified-and-comments-removed that referenced this pull request Feb 1, 2024
… flag, a=testonly

Automatic update from web-platform-tests
Add support for the shadow root clonable flag

This landed in the these two spec PRs:

  whatwg/dom#892
  whatwg/dom#1237

and was discussed here:

  whatwg/dom#1137
  whatwg/dom#1236

This CL adds support for clonable, behind a new ShadowRootClonable
flag. There was already a very basic test, but I added a few
more cases.

This should be fairly web compatible, but there is a risk since with
this feature enabled, declarative shadow roots in the main document
(as opposed to in a <template> element) will now be cloned. I will
launch this feature carefully. Safari has already shipped, and Gecko
has implemented this and plans to ship soon.

Chromestatus:
https://chromestatus.com/feature/5161435196030976

I2P:
https://groups.google.com/a/chromium.org/g/blink-dev/c/nZhPt0ePCAA

Bug: 1510466
Change-Id: Ie25b72f369ca0542555f91010b0f22d295403728
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5239277
Auto-Submit: Mason Freed <masonfchromium.org>
Reviewed-by: David Baron <dbaronchromium.org>
Commit-Queue: David Baron <dbaronchromium.org>
Cr-Commit-Position: refs/heads/main{#1253059}

--

wpt-commits: adc1ac02e6d8e080508325ab4525bab8d09177a6
wpt-pr: 44216

UltraBlame original commit: c628961696861f1ee92fe22401f9f939d8df6a8d
gecko-dev-updater pushed a commit to marco-c/gecko-dev-comments-removed that referenced this pull request Feb 1, 2024
… flag, a=testonly

Automatic update from web-platform-tests
Add support for the shadow root clonable flag

This landed in the these two spec PRs:

  whatwg/dom#892
  whatwg/dom#1237

and was discussed here:

  whatwg/dom#1137
  whatwg/dom#1236

This CL adds support for clonable, behind a new ShadowRootClonable
flag. There was already a very basic test, but I added a few
more cases.

This should be fairly web compatible, but there is a risk since with
this feature enabled, declarative shadow roots in the main document
(as opposed to in a <template> element) will now be cloned. I will
launch this feature carefully. Safari has already shipped, and Gecko
has implemented this and plans to ship soon.

Chromestatus:
https://chromestatus.com/feature/5161435196030976

I2P:
https://groups.google.com/a/chromium.org/g/blink-dev/c/nZhPt0ePCAA

Bug: 1510466
Change-Id: Ie25b72f369ca0542555f91010b0f22d295403728
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5239277
Auto-Submit: Mason Freed <masonfchromium.org>
Reviewed-by: David Baron <dbaronchromium.org>
Commit-Queue: David Baron <dbaronchromium.org>
Cr-Commit-Position: refs/heads/main{#1253059}

--

wpt-commits: adc1ac02e6d8e080508325ab4525bab8d09177a6
wpt-pr: 44216

UltraBlame original commit: c628961696861f1ee92fe22401f9f939d8df6a8d
marcoscaceres pushed a commit to web-platform-tests/wpt that referenced this pull request Feb 23, 2024
This landed in the these two spec PRs:

  whatwg/dom#892
  whatwg/dom#1237

and was discussed here:

  whatwg/dom#1137
  whatwg/dom#1236

This CL adds support for clonable, behind a new ShadowRootClonable
flag. There was already a very basic test, but I added a few
more cases.

This should be fairly web compatible, but there is a risk since with
this feature enabled, declarative shadow roots in the main document
(as opposed to in a <template> element) will now be cloned. I will
launch this feature carefully. Safari has already shipped, and Gecko
has implemented this and plans to ship soon.

Chromestatus:
https://chromestatus.com/feature/5161435196030976

I2P:
https://groups.google.com/a/chromium.org/g/blink-dev/c/nZhPt0ePCAA

Bug: 1510466
Change-Id: Ie25b72f369ca0542555f91010b0f22d295403728
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5239277
Auto-Submit: Mason Freed <masonf@chromium.org>
Reviewed-by: David Baron <dbaron@chromium.org>
Commit-Queue: David Baron <dbaron@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1253059}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic: nodes topic: shadow Relates to shadow trees (as defined in DOM)
Development

Successfully merging this pull request may close these issues.

Add cloneable option to ShadowRootInit
5 participants