W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2015

Re: [Shadow] Q: Removable shadows (and an idea for lightweight shadows)?

From: Ryosuke Niwa <rniwa@apple.com>
Date: Thu, 26 Mar 2015 12:56:36 -0700
Cc: "Dimitri Glazkov (dglazkov@google.com)" <dglazkov@google.com>, Arron Eicholz <arronei@microsoft.com>, "Anne van Kesteren (annevk@annevk.nl)" <annevk@annevk.nl>, WebApps WG <public-webapps@w3.org>
Message-id: <4CFF902D-7592-4F53-A6FE-2D7CEE5CB1D4@apple.com>
To: Travis Leithead <travis.leithead@microsoft.com>

> On Mar 26, 2015, at 10:53 AM, Travis Leithead <travis.leithead@microsoft.com> wrote:
> Today’s ShadowDOM model is designed around only adding shadow roots to element in the ‘light side’. I assume this is intentional, but was hoping someone could describe why this design was chosen? Or said another way, if there was an imperative API to _remove_ a shadow DOM, would that symmetry be bad?
> In full transparency, I’m thinking about potential solutions for a simplified shadow dom, and it occurs to me that it can’t get much simpler than the following:
> ·        Elements only [ever] have one “shadow side” which is essentially a secondary child node list. Whenever anything’s in this list the Element renders that content instead of its “light” children. (Or maybe there’s a switch to tell the element which side to render: light or dark?)
> ·        Elements expose this “shadow node list” via APIs that are very similar to existing node list management, e.g., appendShadowChild(), insertShadowBefore(), removeShadowChild(), replaceShadowChild(), shadowChildren[], shadowChildNodes[].
> ·        No special Event swizzling, no security boundary, no alternate script engine, no intermediate shadow root object,  etc. This minimalist approach only provides node ‘hiding’ and potentially an alternate rendering path.
> ·        Another feature could then provide the stronger “component” boundary, specifically the javascript global scope isolation. This delineation may more closely match the division we are seeing between the “React-like” scenarios and more robust component-kitchen-style custom element deployments.

Am I right in understanding that those shadow child node can have direct children?  If that were the case, then this model is functionally equivalent to a model with shadow root.  Those shadow children we add in this model is essentially new shadow root because we can have a tree of nodes "in shadow" under them.

- R. Niwa
Received on Thursday, 26 March 2015 19:57:04 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:26 UTC