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: Justin Fagnani <justinfagnani@google.com>
Date: Thu, 26 Mar 2015 13:34:08 -0700
Message-ID: <CAEKsHmD+XfkqCFBSHd7a5aPAnn6rdb3LmdDMo=d5ojoNwaPrUg@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 Thu, Mar 26, 2015 at 11:36 AM, Travis Leithead <
travis.leithead@microsoft.com> wrote:

> > From: Justin Fagnani [mailto:justinfagnani@google.com]
> >> 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[].
> >
> >This part seems like a big step back to me. Shadow roots being actual
> nodes means
> >that existing code and knowledge work against them.
>
> "existing code and knowledge work against them" -- I'm not sure you
> understood correctly.
>

No, I think I understood :)

ShadorRoot extends DocumentFragment, and thus Node and has all the API yo
would expect like querySelector(), qsA(), childNodes(), textContent,
appendChild(), cloneNode(), insertBefore(), etc... You can pass a
ShadowRoot to any API expecting a node. For instance, deep traversal though
shadow trees only requires updating normal traversal to crawl into shadows,
it doesn't require teaching it a multitude of shadow*() methods.


> Nodes in the "shadow child list" wouldn't show up in the childNodes list,
> nor in any of the
> node traversal APIs (e.g., not visible to qSA, nextSibling,
> previousSibling, children, childNodes,
> ect.
>
> Trivially speaking, if you wanted to hide two divs that implement a "stack
> panel" and have some
> element render it, you'd just do:
> element.appendShadowChild(document.createElement('div'))
> element.appendShadowChild(document.createElement('div'))
>
> Those divs would not be discoverable by any traditional DOM APIs (they
> would now be on the
> "shadow side"), and the only way to see/use them would be to use the new
> element.shadowChildren
> collection.
>

As in the current API where the only way to see shadow children is by
accessing a shadow root. Your examples become:
element.shadowRoot.appendChild(document.createElement('div'))
element.shadowRoot.appendChild(document.createElement('div'))

Or things like: function writeDivSoup(container){...}, which will work as
writeDivSoup(element.shadowRoot)


> But perhaps I'm misunderstanding your point.
>
> >The API surface that you'd have to duplicate with shadow*() methods would
> be quite large.
>
> That's true. Actually, I think the list above is probably about it.
>

querySelector(), find() and friends are important. Plus, speaking of find()
what about additions to Node and DocumentFragment in the future? Do you
keep just adding things like queryShadowSelector() and shadowFind()?
Received on Thursday, 26 March 2015 20:34:55 UTC

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