Intent to Prototype: Declarative Shadow DOM

292 views
Skip to first unread message

Mason Freed

unread,
Feb 12, 2020, 7:11:39 PMFeb 12
to blink-dev
mason...@chromium.org https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md https://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
This intent message was generated by Chrome Platform Status.

PhistucK

unread,
Feb 13, 2020, 5:54:25 AMFeb 13
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)


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

unread,
Feb 13, 2020, 11:08:58 AMFeb 13
to PhistucK, blink-dev
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?
Reply all
Reply to author
Forward
0 new messages