Re: [whatwg/dom] Declarative Shadow DOM (#510)

Tokyo F2F: The outcome was we will not move forward with this proposal. Overloading `<template>` tag with more functionality (like `shadowroot` attribute) may end up with lots of confusion for developers, especially given ongoing, not finalized progress with template instantiation. Specific new `<shadowroot>` tag would require new parser macro to wait for the end tag to attach shadow root and remove the node, that could introduce similar security problems during implementation as it did for `template` element.

We need to make sure that before shadow root is attached its `<style>`s should not apply to the outer/host tree, scripts and custom elements should not have an access to the `<shadowroot>` ascendant node.

I actually do not feel competent enough in the parser area to give a correct rationale why do we need that macro and wait for the end tag.
@rniwa could you comment shortly why can't we attach shadow root to the parent and remove the element on start tag, then continue attaching descendants to the shadow root, or beside using the different name, use the mechanics of template element for parsing?

Supporting non-scripting/scripting-forbidden environments is not sufficient motivation for implementing new features into the Platform for the Group. All other cases should be solvable by a library/custom element that implements declarative shadow dom. Therefore it's up to the user-land and frameworks to adopt such convention.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/510#issuecomment-370980398