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!
On Tuesday, January 4, 2022 at 8:55:37 AM UTC-8 Jason S wrote: > 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) > > > On Friday, July 2, 2021 at 2:49:53 PM UTC-4 Mason Freed wrote: > >> Hi Chris, thanks for the comment! I see you also raised an issue >> <https://github.com/mfreed7/declarative-shadow-dom/issues/13> for >> this, so to spare the rest of the people on this mailing list, I've >> responded there >> <https://github.com/mfreed7/declarative-shadow-dom/issues/13#issuecomment-873169869> >> . >> >> Thanks, >> Mason >> >> >> >> On Thu, Jun 24, 2021 at 7:38 AM Chris Kruining <[email protected]> >> wrote: >> >>> 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) >>> On Thursday, 13 February 2020 at 17:08:58 UTC+1 Mason Freed wrote: >>> >>>> On Thu, Feb 13, 2020 at 2:54 AM PhistucK <[email protected]> wrote: >>>> >>>>> 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 >>>> <https://github.com/w3c/webcomponents/blob/gh-pages/proposals/html-modules-explainer.md>. >>>> >>>> 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 >>>> <https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md#instead-of-inline-contents-use-an-idref-to-an-existing-template> >>>> >>>> and here >>>> <https://github.com/whatwg/dom/issues/831#issuecomment-585451735>), >>>> but even that is same-document. Hopefully that answers your question? >>>> >>>> >>>>> >>>>> ☆*PhistucK* >>>>> >>>>> >>>>> On Thu, Feb 13, 2020 at 2:11 AM Mason Freed <[email protected]> >>>>> wrote: >>>>> >>>>>> Contact emails [email protected] Explainer >>>>>> https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md >>>>>> Design >>>>>> docs/spec https://github.com/whatwg/dom/issues/831 >>>>>> <https://chromestatus.com/admin/features/launch/There%20is%20an%20active%20discussion%20in%20the%20WhatWG%20at:%20https://github.com/whatwg/dom/issues/831> >>>>>> TAG >>>>>> review None yet. I will request one once the API shape firms up a >>>>>> bit. Summary 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> Motivation 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. Risks >>>>>> Interoperability and Compatibility 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 >>>>>> <https://github.com/whatwg/dom/issues/510#issuecomment-370980398>. >>>>>> Ergonomics 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 >>>>>> <https://github.com/whatwg/dom/issues/831#issuecomment-585451735> >>>>>> <https://github.com/whatwg/dom/issues/831#issuecomment-585451735>, >>>>>> point #3 for more discussion of this issue. Activation This feature >>>>>> is rather polyfillable - see this section of the explainer >>>>>> <https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md#feature-detection-and-polyfilling>. >>>>>> >>>>>> 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. Security 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. >>>>>> Debuggability 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. Will >>>>>> this feature be supported on all six Blink platforms (Windows, Mac, >>>>>> Linux, >>>>>> Chrome OS, Android, and Android WebView)? Yes Is this feature fully >>>>>> tested by web-platform-tests >>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>>>> ? 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. Link to entry on the Chrome Platform Status >>>>>> https://chromestatus.com/feature/5191745052606464 >>>>>> This intent message was generated by Chrome Platform Status >>>>>> <https://www.chromestatus.com/>. >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "blink-dev" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDjpvXkS3sRDwjZ9ZPDKN_Gomv50%3D_naM1vgvirQd_F_Hg%40mail.gmail.com >>>>>> >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDjpvXkS3sRDwjZ9ZPDKN_Gomv50%3D_naM1vgvirQd_F_Hg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b506c279-fdb5-47d9-8812-d35ca700eb92n%40chromium.org.
