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 <king.chri...@gmail.com> > 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 <phis...@gmail.com> 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 <mason...@chromium.org> >>>> wrote: >>>> >>>>> Contact emails mason...@chromium.org 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 blink-dev+...@chromium.org. >>>>> 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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4aa0ce40-e611-4bea-8312-4ea3d5e597can%40chromium.org.
