You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to blink-dev
mason...@chromium.orghttps://github.com/mfreed7/declarative-shadow-dom/blob/master/README.mdhttps://github.com/whatwg/dom/issues/831
None yet. I will request one once the API shape firms up a bit.
A declarative API to allow the creation of #shadowroot's using only HTML and no Javascript. Example:
<host-element>
<template shadowroot="open">
<slot></slot>
</template>
<h2>Light content</h2>
</host-element>
The above HTML would generate the following DOM tree:
<host-element>
#shadow-root (open)
<slot>
↳ <h2> reveal
</slot>
<h2>Light content</h2>
</host-element>
This API allows Web Components that use Shadow DOM to also make use of Server-Side Rendering (SSR), to get rendered content on screen quickly without requiring Javascript for shadow root attachment.
The main interoperability risk would be that other browsers fail to implement this API. This feature is roughly polyfillable, so it should still be usable while other implementations are being completed.
Firefox: No public signals
Edge: No public signals
Safari: No public signals
Web developers: Positive
See many comments from developers on the prior thread resolving *not* to move forward with declarative Shadow DOM. Most are positive and want a solution to this problem. Start after this comment.
Much thought has been given to the ergonomics of this API. A more ergonomic alternative, that of a new <shadowroot> element, would create significant web compat problems for browsers that do not yet support the new element.
The biggest risk of the current proposal is that it does not *also* solve the declarative adoptedStylesheets problem. That is, to include stylesheets within declarative shadowroots, inline <style> elements must be used. That isn't as large of a penalty as it would seem, but it is a stumbling block. See this post, point #3 for more discussion of this issue.
This feature is rather polyfillable - see this section of the explainer. However, any such polyfill would require Javascript to work, and the prime motivation for this feature is no-JS SSR. However, for sites that want to use Web Components and Shadow DOM, it would seem that such a polyfill could be written in a way that does not impact performance for browsers that have implemented this proposal, and does no worse for browsers that have not yet supported this API.
The prior implementation of <template> caused significant parser security issues. While this proposal attempts to re-use as much as possible of the existing <template> implementation, there are a few required changes. It is possible that those changes introduce new security holes. Additionally, the existing implementation of <template> could also still contain undiscovered security problems.
Since this is a parser-only feature, parsed DOM content will contain only "normal" #shadowroot nodes. Devtools already fully supports Shadow DOM, and all of those existing tools will continue to apply to this new method of declaratively creating Shadow DOM.
Yes
No
There are no WPT tests for this feature yet, but this feature should be fully testable via WPT. As part of the implementation, these tests will be written.
https://chromestatus.com/feature/5191745052606464
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to Mason Freed, blink-dev
I understand that declarative importing the shadow DOM from external files (or even from the same document, using <template id="..."> or something, in case you want the multiple instances of the same element) is not a goal of this feature at the moment, right?
If I am right, are any of them planned?
(I do realize that it sounds a lot like another <link rel="import" href="...">, but I think there is merit to this question nevertheless)
I understand that declarative importing the shadow DOM from external files (or even from the same document, using <template id="..."> or something, in case you want the multiple instances of the same element) is not a goal of this feature at the moment, right?
If I am right, are any of them planned?
(I do realize that it sounds a lot like another <link rel="import" href="...">, but I think there is merit to this question nevertheless)
No, that sounds more like HTML Modules. This proposal only affects a single HTML file, however it is loaded. There is discussion going on about an alternative syntax for declarative shadow DOM, with some sort of template id references (see here and here), but even that is same-document. Hopefully that answers your question?
Chris Kruining
unread,
Jun 24, 2021, 10:38:10 AM6/24/21
Reply to author
Sign in to reply to author
Forward
Sign in to forward
Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to blink-dev, Mason Freed
I am trying to implement this new feature for my SSR of component and loving it thus far. however, I've run into an issue, and I do hope I'm at the right place here.
what I'm struggling with is that for items I repeat (renderer with a for loop logic), those repeated items are stored in an template (normal template without `shadowroot` property), this template's content is then cloned and added to the DOM, just your typical client side rendering I can't get around due to dynamic data.
the problem for me now is that inside my template I have components with declared shadow-roots (`template[shadowroot="open"]`). These shadow-roots are however parsed immediately by the browser. Which causes me to loose the shadow-root when I clone the template's content.
Is the parsing of declaritive shadow-root inside templates by design? or an oversight perhaps?
I really hope that `template[shadowroot="open"]` inside `template`s could not be parsed immediately otherwise I can't use this feature at all and need to use normal templates and `attachShadow` by hand.
I truely hope my description is clear enough, because a minimal repro is HUGE. (nearly 800-1000 lines of js)
Mason Freed
unread,
Jul 2, 2021, 2:49:53 PM7/2/21
Reply to author
Sign in to reply to author
Forward
Sign in to forward
Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to Chris Kruining, blink-dev
Hi Chris, thanks for the comment! I see you also raised an issue for this, so to spare the rest of the people on this mailing list, I've responded there.
Thanks,
Mason
Jason S
unread,
Jan 4, 2022, 11:55:37 AM1/4/22
Reply to author
Sign in to reply to author
Forward
Sign in to forward
Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to blink-dev, Mason Freed, blink-dev, Chris Kruining
I've enabled about://flags/#enable-experimental-web-platform-features and restarted but
i dont see a shadowRoot being created in my component when i declare shadowroot="open" on the
inline template.
Im on Mac/Chrome Version 88.0.4324.150 (Official Build) (x86_64)
Mason Freed
unread,
Jan 6, 2022, 2:57:13 PM1/6/22
Reply to author
Sign in to reply to author
Forward
Sign in to forward
Delete
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to blink-dev, Jason S, Mason Freed, blink-dev, Chris Kruining
This feature is fully-shipped, in Chrome 90+, so you don't need to enable any flags. Please file bugs at https://crbug.com/new. Thanks!