Position on emerging standard: Declarative Shadow DOM
Hello WebKit! I would like to request an official WebKit position on the Declarative Shadow DOM proposal. There have been some great comments and discussion from WebKit folks on the issue thread, but it is a bit unclear whether the overall proposal is something WebKit would support. This was brought up and discussed, e.g., on the DOM spec PR here: https://github.com/whatwg/dom/pull/858#issuecomment-623735890 Please see below for all of the relevant supporting documents and discussions. Explainer: https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md WhatWG DOM Issue discussion: https://github.com/whatwg/dom/issues/831 HTML Spec PR: https://github.com/whatwg/html/pull/5465 DOM Spec PR: https://github.com/whatwg/dom/pull/858 TAG review: https://github.com/w3ctag/design-reviews/issues/494 Request for Mozilla Position: https://github.com/mozilla/standards-positions/issues/335 Thanks, Mason Freed
Hello WebKit folks, I just wanted to quickly ping this thread to see if there was any interest in posting a position on declarative Shadow DOM. My original post here didn't gather much feedback. :-) Thanks, Mason On Tue, May 26, 2020 at 12:11 PM Mason Freed <masonfreed@chromium.org> wrote:
Hello WebKit!
I would like to request an official WebKit position on the Declarative Shadow DOM proposal. There have been some great comments and discussion from WebKit folks on the issue thread, but it is a bit unclear whether the overall proposal is something WebKit would support. This was brought up and discussed, e.g., on the DOM spec PR here: https://github.com/whatwg/dom/pull/858#issuecomment-623735890
Please see below for all of the relevant supporting documents and discussions.
Explainer: https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md WhatWG DOM Issue discussion: https://github.com/whatwg/dom/issues/831 HTML Spec PR: https://github.com/whatwg/html/pull/5465 DOM Spec PR: https://github.com/whatwg/dom/pull/858 TAG review: https://github.com/w3ctag/design-reviews/issues/494 Request for Mozilla Position: https://github.com/mozilla/standards-positions/issues/335
Thanks, Mason Freed
Hi, Sorry for the late reply. I've been on a medical leave. I just commented on https://github.com/whatwg/dom/issues/831 - R. Niwa On Tue, Aug 4, 2020 at 4:26 PM Mason Freed <masonfreed@chromium.org> wrote:
Hello WebKit folks,
I just wanted to quickly ping this thread to see if there was any interest in posting a position on declarative Shadow DOM. My original post here didn't gather much feedback. :-)
Thanks, Mason
On Tue, May 26, 2020 at 12:11 PM Mason Freed <masonfreed@chromium.org> wrote:
Hello WebKit!
I would like to request an official WebKit position on the Declarative Shadow DOM proposal. There have been some great comments and discussion from WebKit folks on the issue thread, but it is a bit unclear whether the overall proposal is something WebKit would support. This was brought up and discussed, e.g., on the DOM spec PR here: https://github.com/whatwg/dom/pull/858#issuecomment-623735890
Please see below for all of the relevant supporting documents and discussions.
Explainer: https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md WhatWG DOM Issue discussion: https://github.com/whatwg/dom/issues/831 HTML Spec PR: https://github.com/whatwg/html/pull/5465 DOM Spec PR: https://github.com/whatwg/dom/pull/858 TAG review: https://github.com/w3ctag/design-reviews/issues/494 Request for Mozilla Position: https://github.com/mozilla/standards-positions/issues/335
Thanks, Mason Freed
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Yes, thanks! Welcome back! On Mon, Aug 10, 2020 at 3:24 PM Ryosuke Niwa <rniwa@webkit.org> wrote:
Hi,
Sorry for the late reply. I've been on a medical leave. I just commented on https://github.com/whatwg/dom/issues/831
- R. Niwa
On Tue, Aug 4, 2020 at 4:26 PM Mason Freed <masonfreed@chromium.org> wrote:
Hello WebKit folks,
I just wanted to quickly ping this thread to see if there was any
interest in posting a position on declarative Shadow DOM. My original post here didn't gather much feedback. :-)
Thanks, Mason
On Tue, May 26, 2020 at 12:11 PM Mason Freed <masonfreed@chromium.org>
wrote:
Hello WebKit!
I would like to request an official WebKit position on the Declarative
Shadow DOM proposal. There have been some great comments and discussion from WebKit folks on the issue thread, but it is a bit unclear whether the overall proposal is something WebKit would support. This was brought up and discussed, e.g., on the DOM spec PR here: https://github.com/whatwg/dom/pull/858#issuecomment-623735890
Please see below for all of the relevant supporting documents and
discussions.
Explainer:
https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md
WhatWG DOM Issue discussion: https://github.com/whatwg/dom/issues/831 HTML Spec PR: https://github.com/whatwg/html/pull/5465 DOM Spec PR: https://github.com/whatwg/dom/pull/858 TAG review: https://github.com/w3ctag/design-reviews/issues/494 Request for Mozilla Position: https://github.com/mozilla/standards-positions/issues/335
Thanks, Mason Freed
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Hello WebKit, I just wanted to send a final heads-up that Chromium is intending to ship the Declarative Shadow DOM feature. We haven't heard much back from WebKit in the last 5 months or so, but in the meantime there has been some good discussion with Mozilla and the broader community. Several more performance investigations have been performed, around the overhead of Shadow DOM generally, and around the potential polyfill alternatives for DSD. You can see a summary of these, plus all of the other changes that we've incorporated, in this comment on the Mozilla Standards Position thread <https://github.com/mozilla/standards-positions/issues/335#issuecomment-781697858>. These changes are the result of your (and the community's) involvement and feedback, so thanks. At this point, we believe all of the feedback has been addressed. Thanks, Mason On Tue, Aug 11, 2020 at 10:27 AM Mason Freed <masonfreed@chromium.org> wrote:
Yes, thanks! Welcome back!
On Mon, Aug 10, 2020 at 3:24 PM Ryosuke Niwa <rniwa@webkit.org> wrote:
Hi,
Sorry for the late reply. I've been on a medical leave. I just commented on https://github.com/whatwg/dom/issues/831
- R. Niwa
On Tue, Aug 4, 2020 at 4:26 PM Mason Freed <masonfreed@chromium.org> wrote:
Hello WebKit folks,
I just wanted to quickly ping this thread to see if there was any
interest in posting a position on declarative Shadow DOM. My original post here didn't gather much feedback. :-)
Thanks, Mason
On Tue, May 26, 2020 at 12:11 PM Mason Freed <masonfreed@chromium.org>
wrote:
Hello WebKit!
I would like to request an official WebKit position on the Declarative
Shadow DOM proposal. There have been some great comments and discussion from WebKit folks on the issue thread, but it is a bit unclear whether the overall proposal is something WebKit would support. This was brought up and discussed, e.g., on the DOM spec PR here: https://github.com/whatwg/dom/pull/858#issuecomment-623735890
Please see below for all of the relevant supporting documents and
discussions.
Explainer:
https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md
WhatWG DOM Issue discussion: https://github.com/whatwg/dom/issues/831 HTML Spec PR: https://github.com/whatwg/html/pull/5465 DOM Spec PR: https://github.com/whatwg/dom/pull/858 TAG review: https://github.com/w3ctag/design-reviews/issues/494 Request for Mozilla Position: https://github.com/mozilla/standards-positions/issues/335
Thanks, Mason Freed
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
On Thu, Feb 18, 2021 at 3:17 PM Mason Freed via webkit-dev < webkit-dev@lists.webkit.org> wrote:
I just wanted to send a final heads-up that Chromium is intending to ship the Declarative Shadow DOM feature. We haven't heard much back from WebKit in the last 5 months or so, but in the meantime there has been some good discussion with Mozilla and the broader community. Several more performance investigations have been performed, around the overhead of Shadow DOM generally, and around the potential polyfill alternatives for DSD. You can see a summary of these, plus all of the other changes that we've incorporated, in this comment on the Mozilla Standards Position thread <https://github.com/mozilla/standards-positions/issues/335#issuecomment-781697858>. These changes are the result of your (and the community's) involvement and feedback, so thanks. At this point, we believe all of the feedback has been addressed.
The latest proposal does solve much of the problems we've identified in the past, and it's looking to be a promising direction. Do you have any example website or app that you can share with which resulted in the observed 15% improvement in FCP? That would be a very intriguing observation and would substantiate the support for this feature. However, as I commented on https://github.com/whatwg/dom/pull/892 and have previously stated during the last F2F and other avenues, the currently proposed semantics of getInnerHTML is deeply problematic. We want consistent semantics across different kinds of Web API, and what's being proposed is very much different from what we had discussed what we would do for selection. Also, have people figured out how scoped custom element registries can integrate with this feature in the future? Given that's the other most frequently requested feature, it would be very regrettable if we later found out some inconsistencies or awkwardness in their integrations. - R. Niwa On Tue, Aug 11, 2020 at 10:27 AM Mason Freed <masonfreed@chromium.org>
wrote:
Yes, thanks! Welcome back!
On Mon, Aug 10, 2020 at 3:24 PM - R. Niwa <rniwa@webkit.org> wrote:
Hi,
Sorry for the late reply. I've been on a medical leave. I just commented on https://github.com/whatwg/dom/issues/831
- R. Niwa
On Tue, Aug 4, 2020 at 4:26 PM Mason Freed <masonfreed@chromium.org> wrote:
Hello WebKit folks,
I just wanted to quickly ping this thread to see if there was any
interest in posting a position on declarative Shadow DOM. My original post here didn't gather much feedback. :-)
Thanks, Mason
On Tue, May 26, 2020 at 12:11 PM Mason Freed <masonfreed@chromium.org>
wrote:
Hello WebKit!
I would like to request an official WebKit position on the
Declarative Shadow DOM proposal. There have been some great comments and discussion from WebKit folks on the issue thread, but it is a bit unclear whether the overall proposal is something WebKit would support. This was brought up and discussed, e.g., on the DOM spec PR here: https://github.com/whatwg/dom/pull/858#issuecomment-623735890
Please see below for all of the relevant supporting documents and
discussions.
Explainer:
https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md
WhatWG DOM Issue discussion: https://github.com/whatwg/dom/issues/831 HTML Spec PR: https://github.com/whatwg/html/pull/5465 DOM Spec PR: https://github.com/whatwg/dom/pull/858 TAG review: https://github.com/w3ctag/design-reviews/issues/494 Request for Mozilla Position: https://github.com/mozilla/standards-positions/issues/335
Thanks, Mason Freed
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
On Thu Feb 18 17:08:18 PST 2021 Ryosuke Niwa via webkit-dev < webkit-dev at lists.webkit.org> wrote:
The latest proposal does solve much of the problems we've identified in the past, and it's looking to be a promising direction. Do you have any example website or app that you can share with which resulted in the observed 15% improvement in FCP? That would be a very intriguing observation and would substantiate the support for this feature.
Glad to hear you think it's promising! The example is from the AMP team, and you can see more detail at the Origin Trial results summary here: https://docs.google.com/document/d/1QmBKxQLE81PsMzyPCvYhzqRAn4hxz61Jzk0uXJAh...
However, as I commented on https://github.com/whatwg/dom/pull/892 and have previously stated during the last F2F and other avenues, the currently proposed semantics of getInnerHTML is deeply problematic. We want consistent semantics across different kinds of Web API, and what's being proposed is very much different from what we had discussed what we would do for selection.
I just replied to the comment you made yesterday on DOM issue #892. I looked back at the F2F minutes ( https://www.w3.org/2020/03/23-components-minutes.html) to refresh my memory, and it turns out the current API was actually suggested (by annevk) at that meeting. I don't see any comments from you about the API shape there, but perhaps I missed it? In terms of API shape, can you clarify what you feel is deeply problematic about it? I assume you're talking about the need to pass in closed shadow roots, to enable them to be serialized. I see that your comment there suggests the requirement to pass in *all* shadow roots, even open ones. But the linked comment on selection actually refers to just closed shadow roots also. I'm unclear why you would want/need to pass in open shadow roots?
Also, have people figured out how scoped custom element registries can integrate with this feature in the future? Given that's the other most frequently requested feature, it would be very regrettable if we later found out some inconsistencies or awkwardness in their integrations.
Yes, I've talked several times to justinfagnani about Scoped Custom Element Registries, and he sees no problem integrating with DSD. We'll likely just need to add an attribute that opts the shadow root out of using the global registry, but that seems straightforward. Do you have any particular concerns? Thanks, Mason On Thu, Feb 18, 2021 at 3:16 PM Mason Freed <masonfreed@chromium.org> wrote:
Hello WebKit,
I just wanted to send a final heads-up that Chromium is intending to ship the Declarative Shadow DOM feature. We haven't heard much back from WebKit in the last 5 months or so, but in the meantime there has been some good discussion with Mozilla and the broader community. Several more performance investigations have been performed, around the overhead of Shadow DOM generally, and around the potential polyfill alternatives for DSD. You can see a summary of these, plus all of the other changes that we've incorporated, in this comment on the Mozilla Standards Position thread <https://github.com/mozilla/standards-positions/issues/335#issuecomment-781697858>. These changes are the result of your (and the community's) involvement and feedback, so thanks. At this point, we believe all of the feedback has been addressed.
Thanks, Mason
On Tue, Aug 11, 2020 at 10:27 AM Mason Freed <masonfreed@chromium.org> wrote:
Yes, thanks! Welcome back!
On Mon, Aug 10, 2020 at 3:24 PM Ryosuke Niwa <rniwa@webkit.org> wrote:
Hi,
Sorry for the late reply. I've been on a medical leave. I just commented on https://github.com/whatwg/dom/issues/831
- R. Niwa
On Tue, Aug 4, 2020 at 4:26 PM Mason Freed <masonfreed@chromium.org> wrote:
Hello WebKit folks,
I just wanted to quickly ping this thread to see if there was any
interest in posting a position on declarative Shadow DOM. My original post here didn't gather much feedback. :-)
Thanks, Mason
On Tue, May 26, 2020 at 12:11 PM Mason Freed <masonfreed@chromium.org>
wrote:
Hello WebKit!
I would like to request an official WebKit position on the
Declarative Shadow DOM proposal. There have been some great comments and discussion from WebKit folks on the issue thread, but it is a bit unclear whether the overall proposal is something WebKit would support. This was brought up and discussed, e.g., on the DOM spec PR here: https://github.com/whatwg/dom/pull/858#issuecomment-623735890
Please see below for all of the relevant supporting documents and
discussions.
Explainer:
https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md
WhatWG DOM Issue discussion: https://github.com/whatwg/dom/issues/831 HTML Spec PR: https://github.com/whatwg/html/pull/5465 DOM Spec PR: https://github.com/whatwg/dom/pull/858 TAG review: https://github.com/w3ctag/design-reviews/issues/494 Request for Mozilla Position: https://github.com/mozilla/standards-positions/issues/335
Thanks, Mason Freed
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
On Fri, Feb 19, 2021 at 2:38 PM Mason Freed via webkit-dev < webkit-dev@lists.webkit.org> wrote:
On Thu Feb 18 17:08:18 PST 2021 Ryosuke Niwa via webkit-dev < webkit-dev at lists.webkit.org> wrote:
The latest proposal does solve much of the problems we've identified in the past, and it's looking to be a promising direction. Do you have any example website or app that you can share with which resulted in the observed 15% improvement in FCP? That would be a very intriguing observation and would substantiate the support for this feature.
Glad to hear you think it's promising! The example is from the AMP team, and you can see more detail at the Origin Trial results summary here:
https://docs.google.com/document/d/1QmBKxQLE81PsMzyPCvYhzqRAn4hxz61Jzk0uXJAh...
However, as I commented on https://github.com/whatwg/dom/pull/892 and have previously stated during the last F2F and other avenues, the currently proposed semantics of getInnerHTML is deeply problematic. We want consistent semantics across different kinds of Web API, and what's being proposed is very much different from what we had discussed what we would do for selection.
I just replied to the comment you made yesterday on DOM issue #892. I looked back at the F2F minutes ( https://www.w3.org/2020/03/23-components-minutes.html) to refresh my memory, and it turns out the current API was actually suggested (by annevk) at that meeting. I don't see any comments from you about the API shape there, but perhaps I missed it?
In terms of API shape, can you clarify what you feel is deeply problematic about it? I assume you're talking about the need to pass in closed shadow roots, to enable them to be serialized. I see that your comment there suggests the requirement to pass in *all* shadow roots, even open ones. But the linked comment on selection actually refers to just closed shadow roots also. I'm unclear why you would want/need to pass in open shadow roots?
I replied in the issues directly so that people outside of the WebKit community can follow the discussion.
Also, have people figured out how scoped custom element registries can
integrate with this feature in the future? Given that's the other most frequently requested feature, it would be very regrettable if we later found out some inconsistencies or awkwardness in their integrations.
Yes, I've talked several times to justinfagnani about Scoped Custom Element Registries, and he sees no problem integrating with DSD. We'll likely just need to add an attribute that opts the shadow root out of using the global registry, but that seems straightforward. Do you have any particular concerns?
How does one specify a declarative shadow root to use a specific custom element registry? - R. Niwa On Thu, Feb 18, 2021 at 3:16 PM Mason Freed <masonfreed@chromium.org> wrote:
Hello WebKit,
I just wanted to send a final heads-up that Chromium is intending to ship the Declarative Shadow DOM feature. We haven't heard much back from WebKit in the last 5 months or so, but in the meantime there has been some good discussion with Mozilla and the broader community. Several more performance investigations have been performed, around the overhead of Shadow DOM generally, and around the potential polyfill alternatives for DSD. You can see a summary of these, plus all of the other changes that we've incorporated, in this comment on the Mozilla Standards Position thread <https://github.com/mozilla/standards-positions/issues/335#issuecomment-781697858>. These changes are the result of your (and the community's) involvement and feedback, so thanks. At this point, we believe all of the feedback has been addressed.
Thanks, Mason
On Tue, Aug 11, 2020 at 10:27 AM Mason Freed <masonfreed@chromium.org> wrote:
Yes, thanks! Welcome back!
On Mon, Aug 10, 2020 at 3:24 PM Ryosuke Niwa <rniwa@webkit.org> wrote:
Hi,
Sorry for the late reply. I've been on a medical leave. I just commented on https://github.com/whatwg/dom/issues/831
- R. Niwa
On Tue, Aug 4, 2020 at 4:26 PM Mason Freed <masonfreed@chromium.org> wrote:
Hello WebKit folks,
I just wanted to quickly ping this thread to see if there was any
interest in posting a position on declarative Shadow DOM. My original post here didn't gather much feedback. :-)
Thanks, Mason
On Tue, May 26, 2020 at 12:11 PM Mason Freed <masonfreed@chromium.org>
wrote:
Hello WebKit!
I would like to request an official WebKit position on the
Declarative Shadow DOM proposal. There have been some great comments and discussion from WebKit folks on the issue thread, but it is a bit unclear whether the overall proposal is something WebKit would support. This was brought up and discussed, e.g., on the DOM spec PR here: https://github.com/whatwg/dom/pull/858#issuecomment-623735890
Please see below for all of the relevant supporting documents and
discussions.
Explainer:
https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md
WhatWG DOM Issue discussion: https://github.com/whatwg/dom/issues/831 HTML Spec PR: https://github.com/whatwg/html/pull/5465 DOM Spec PR: https://github.com/whatwg/dom/pull/858 TAG review: https://github.com/w3ctag/design-reviews/issues/494 Request for Mozilla Position: https://github.com/mozilla/standards-positions/issues/335
Thanks, Mason Freed
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
On Fri Feb 19 20:36:12 PST 2021 Ryosuke Niwa via webkit-dev < webkit-dev at lists.webkit.org> wrote:
I replied in the issues directly so that people outside of the WebKit community can follow the discussion.
Thanks! I've replied there also.
How does one specify a declarative shadow root to use a specific custom element registry?
Well, I do see this as something that is better designed as part of the scoped custom element registry proposal. But the basic idea would be to just to add an attribute that allows the declarative shadow root to opt out of automatically using the global registry: <template shadowroot=open scoped-registry> and that would keep any custom elements contained within the shadow root from automatically upgrading based on the global registry. Maybe by just assigning an empty custom registry to that shadow root. We'll need to add an attribute to ShadowRoot, as part of the SCER proposal, to allow custom elements to then set the appropriate custom registry later. On Fri, Feb 19, 2021 at 2:38 PM Mason Freed <masonfreed@chromium.org> wrote:
On Thu Feb 18 17:08:18 PST 2021 Ryosuke Niwa via webkit-dev < webkit-dev at lists.webkit.org> wrote:
The latest proposal does solve much of the problems we've identified in the past, and it's looking to be a promising direction. Do you have any example website or app that you can share with which resulted in the observed 15% improvement in FCP? That would be a very intriguing observation and would substantiate the support for this feature.
Glad to hear you think it's promising! The example is from the AMP team, and you can see more detail at the Origin Trial results summary here:
https://docs.google.com/document/d/1QmBKxQLE81PsMzyPCvYhzqRAn4hxz61Jzk0uXJAh...
However, as I commented on https://github.com/whatwg/dom/pull/892 and have previously stated during the last F2F and other avenues, the currently proposed semantics of getInnerHTML is deeply problematic. We want consistent semantics across different kinds of Web API, and what's being proposed is very much different from what we had discussed what we would do for selection.
I just replied to the comment you made yesterday on DOM issue #892. I looked back at the F2F minutes ( https://www.w3.org/2020/03/23-components-minutes.html) to refresh my memory, and it turns out the current API was actually suggested (by annevk) at that meeting. I don't see any comments from you about the API shape there, but perhaps I missed it?
In terms of API shape, can you clarify what you feel is deeply problematic about it? I assume you're talking about the need to pass in closed shadow roots, to enable them to be serialized. I see that your comment there suggests the requirement to pass in *all* shadow roots, even open ones. But the linked comment on selection actually refers to just closed shadow roots also. I'm unclear why you would want/need to pass in open shadow roots?
Also, have people figured out how scoped custom element registries can integrate with this feature in the future? Given that's the other most frequently requested feature, it would be very regrettable if we later found out some inconsistencies or awkwardness in their integrations.
Yes, I've talked several times to justinfagnani about Scoped Custom Element Registries, and he sees no problem integrating with DSD. We'll likely just need to add an attribute that opts the shadow root out of using the global registry, but that seems straightforward. Do you have any particular concerns?
Thanks, Mason
On Thu, Feb 18, 2021 at 3:16 PM Mason Freed <masonfreed@chromium.org> wrote:
Hello WebKit,
I just wanted to send a final heads-up that Chromium is intending to ship the Declarative Shadow DOM feature. We haven't heard much back from WebKit in the last 5 months or so, but in the meantime there has been some good discussion with Mozilla and the broader community. Several more performance investigations have been performed, around the overhead of Shadow DOM generally, and around the potential polyfill alternatives for DSD. You can see a summary of these, plus all of the other changes that we've incorporated, in this comment on the Mozilla Standards Position thread <https://github.com/mozilla/standards-positions/issues/335#issuecomment-781697858>. These changes are the result of your (and the community's) involvement and feedback, so thanks. At this point, we believe all of the feedback has been addressed.
Thanks, Mason
On Tue, Aug 11, 2020 at 10:27 AM Mason Freed <masonfreed@chromium.org> wrote:
Yes, thanks! Welcome back!
On Mon, Aug 10, 2020 at 3:24 PM Ryosuke Niwa <rniwa@webkit.org> wrote:
Hi,
Sorry for the late reply. I've been on a medical leave. I just commented on https://github.com/whatwg/dom/issues/831
- R. Niwa
On Tue, Aug 4, 2020 at 4:26 PM Mason Freed <masonfreed@chromium.org> wrote:
Hello WebKit folks,
I just wanted to quickly ping this thread to see if there was any
interest in posting a position on declarative Shadow DOM. My original post here didn't gather much feedback. :-)
Thanks, Mason
On Tue, May 26, 2020 at 12:11 PM Mason Freed <masonfreed@chromium.org>
wrote:
Hello WebKit!
I would like to request an official WebKit position on the
Declarative Shadow DOM proposal. There have been some great comments and discussion from WebKit folks on the issue thread, but it is a bit unclear whether the overall proposal is something WebKit would support. This was brought up and discussed, e.g., on the DOM spec PR here: https://github.com/whatwg/dom/pull/858#issuecomment-623735890
Please see below for all of the relevant supporting documents and
discussions.
Explainer:
https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md
WhatWG DOM Issue discussion: https://github.com/whatwg/dom/issues/831 HTML Spec PR: https://github.com/whatwg/html/pull/5465 DOM Spec PR: https://github.com/whatwg/dom/pull/858 TAG review: https://github.com/w3ctag/design-reviews/issues/494 Request for Mozilla Position: https://github.com/mozilla/standards-positions/issues/335
Thanks, Mason Freed
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
On Tue, Feb 23, 2021 at 5:06 PM Mason Freed via webkit-dev < webkit-dev@lists.webkit.org> wrote:
On Fri Feb 19 20:36:12 PST 2021 Ryosuke Niwa via webkit-dev < webkit-dev at lists.webkit.org> wrote:
I replied in the issues directly so that people outside of the WebKit community can follow the discussion.
Thanks! I've replied there also.
The issue with the semantics of getInnerHTML is problematic enough that we'd object to this feature as long as that's included in its current shape.
How does one specify a declarative shadow root to use a specific custom
element registry?
Well, I do see this as something that is better designed as part of the scoped custom element registry proposal. But the basic idea would be to just to add an attribute that allows the declarative shadow root to opt out of automatically using the global registry:
<template shadowroot=open scoped-registry>
and that would keep any custom elements contained within the shadow root from automatically upgrading based on the global registry. Maybe by just assigning an empty custom registry to that shadow root. We'll need to add an attribute to ShadowRoot, as part of the SCER proposal, to allow custom elements to then set the appropriate custom registry later.
That seems to indicate that none of the custom elements inside a declarative shadow root can be upgraded until all its ancestor custom elements which use a custom element registry have been upgraded. This would make the declarative shadow DOM's perf benefit less attractive IMO. - R. Niwa
participants (2)
-
Mason Freed
-
Ryosuke Niwa