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.3.1 : Friday, 27 October 2017 07:27:26 UTC