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: Dominic Cooney <dominicc@google.com>
Date: Fri, 27 Mar 2015 14:42:05 +0900
Message-ID: <CAHnmYQ9HqO-pKL8CzsDh=MAZTRKpFGUrGRQvW1Tn5Bkyzde7fw@mail.gmail.com>
To: Travis Leithead <travis.leithead@microsoft.com>
Cc: "Dimitri Glazkov (dglazkov@google.com)" <dglazkov@google.com>, Arron Eicholz <arronei@microsoft.com>, "Anne van Kesteren (annevk@annevk.nl)" <annevk@annevk.nl>, Ryosuke Niwa <rniwa@apple.com>, WebApps WG <public-webapps@w3.org>
On Fri, Mar 27, 2015 at 2:53 AM, Travis Leithead <
travis.leithead@microsoft.com> wrote:

>  Hi folks,
> 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,

Could you share some background on how we should gauge simplicity? What you
have sketched here is less expressive than Shadow DOM (for example, it
can't do what the <content> element does.) That's not necessarily good or
bad, but it depends on what you're aiming for.

> 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.
Along these lines, an ancient debate was whether the boundary of the
component was just "inside" the host element or just outside it (so,
imagine a 1:1 swap of element for its shadow twin element.) But whether
this is simplified or not is a very complex question.

>  ·        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.
Received on Friday, 27 March 2015 05:42:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:44 UTC