Intent to Prototype: Declarative Shadow DOM

[Mason Freed]

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 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. 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, point #3 for more discussion of this issue. Activation 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. 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? 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.

[PhistucK]

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)

☆PhistucK

--
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.

[Mason Freed]

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. 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]

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]

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]

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]

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!