- From: Travis Leithead <travis.leithead@microsoft.com>
- Date: Thu, 26 Mar 2015 18:36:32 +0000
- To: Justin Fagnani <justinfagnani@google.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>
> 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.
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.
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.
Received on Thursday, 26 March 2015 18:37:01 UTC