Re: [Shadow] Q: Removable shadows (and an idea for lightweight shadows)?
getElement* functions have been removed, [1], [2], from the ShadowRoot. [1]: https://github.com/w3c/webcomponents/commit/3d5f147812edaf74cc4f07d294836cafdf48534f [2]: https://github.com/w3c/webcomponents/commit/6416fdfe7fc87e47aa89aac8ce5430389b9ad653 See also the relevant discussions: - https://www.w3.org/Bugs/Public/show_bug.cgi?id=23620 - https://www.w3.org/Bugs/Public/show_bug.cgi?id=27569 I think it's coincidence, but I added the following note to the spec yesterday to make the spec reader-friendly. - https://github.com/w3c/webcomponents/commit/b43d98149c4c4a401fe35e115afc548031bdbc6d It might be also worth mentioning that you can use ShadowRoot.getElementById in a non-normative way there. Strictly speaking, we don't have to mention it in the spec because it's implied. On Fri, Mar 27, 2015 at 5:44 AM Elliott Sprehn espr...@chromium.org wrote: On Thu, Mar 26, 2015 at 1:38 PM, Ryosuke Niwa rn...@apple.com wrote: On Mar 26, 2015, at 1:23 PM, Travis Leithead travis.leith...@microsoft.com wrote: You make a series of excellent points. In the sense that you have a new set of nodes to manage holistically, then having some sort of “document” container does makes sense for that (a ShadowRoot) in order to place all your search/navigation APIs. You got me thinking though—getElementById is currently not available on ShadowRoot right? Does that API in the host’s document find IDs in the shadow? I presume not given the guidelines you mentioned. I wonder what other APIs from Document are desired? I thought getElementById existed in ShadowRoot at some point but the latest Blink code doesn't have it. It looks like Blink has querySelector/querySelectorAll via ParentNode: https://chromium.googlesource.com/chromium/blink/+/master/Source/core/dom/shadow/ShadowRoot.idl https://chromium.googlesource.com/chromium/blink/+/master/Source/core/dom/ParentNode.idl The spec changed, https://dom.spec.whatwg.org/#interface-nonelementparentnode ShadowRoot is a DocumentFragment and DocumentFragment implements NonElementParentNode. - E
Re: [Shadow] Q: Removable shadows (and an idea for lightweight shadows)?
On Fri, Mar 27, 2015 at 2:53 AM, Travis Leithead travis.leith...@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.
RE: [Shadow] Q: Removable shadows (and an idea for lightweight shadows)?
From: Daniel Freedman [mailto:dfre...@google.com] How would you style these shadow children? Would the main document CSS styles affect these children? I don’t know :-) Let's assume that main document CSS styles wouldn't affect them, as that seems to be a fundamental requirement for shadowDOM. So, then how to style them? Here's a few thoughts--but what do you think? * Require scoped style elements. This is today's model. I don't like it much because of the developer ergonomics--it's not as natural as the way styles are applied to documents today with link rel=stylesheet * provide new APIs to manage stylesheets for the shadow content. Maybe: element.importShadowStyleSheet(url), and then a corresponding element.shadowStyleSheets[] collection. This seems vaguely reminiscent of an imperative @import. Might be better to just add this capability [generally] to the styleSheets collection [1] come to think of it... * other ideas? [1] http://dev.w3.org/csswg/cssom/#stylesheetlist
Re: [Shadow] Q: Removable shadows (and an idea for lightweight shadows)?
On Thu, Mar 26, 2015 at 11:36 AM, Travis Leithead
travis.leith...@microsoft.com wrote:
From: Justin Fagnani [mailto:justinfagn...@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.
So if I want to query down into those children I need to do
element.shadowFirstChild.querySelectorAll or
shadowFirstChild.getElementById? That requires looking at all siblings in
the shadowChildList, so I suppose you'd want shadowQuerySelector,
shadowGetElementById, etc? You also need to duplicate elementFromPoint
(FromRect, etc.) down to Element/Text or add special shadow* versions since
right now they only exist on Document and ShadowRoot.
I have to admit I have an allergic reaction to having an element like div
id=foo and then doing element.parentNode.querySelector(#foo) != div.
Another fundamental requirement of Shadow DOM is that you never
accidentally fall out or fall into a shadow and must always take an
explicit step to get there. Having shadow node's parentNode be the host
breaks that.
We could make the parentNode be null like ShadowRoot of today, but you're
still stuck adding API duplication or writing code to iterate the
shadowChildren list.
- E
Re: [Shadow] Q: Removable shadows (and an idea for lightweight shadows)?
On Thu, Mar 26, 2015 at 11:36 AM, Travis Leithead
travis.leith...@microsoft.com wrote:
From: Justin Fagnani [mailto:justinfagn...@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()?
Re: [Shadow] Q: Removable shadows (and an idea for lightweight shadows)?
On Mar 26, 2015, at 10:53 AM, Travis Leithead travis.leith...@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
Re: [Shadow] Q: Removable shadows (and an idea for lightweight shadows)?
How would you style these shadow children? Would the main document CSS
styles affect these children?
On Thu, Mar 26, 2015 at 11:36 AM, Travis Leithead
travis.leith...@microsoft.com wrote:
From: Justin Fagnani [mailto:justinfagn...@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.
Re: [Shadow] Q: Removable shadows (and an idea for lightweight shadows)?
On Mar 26, 2015, at 1:23 PM, Travis Leithead travis.leith...@microsoft.com wrote: You make a series of excellent points. In the sense that you have a new set of nodes to manage holistically, then having some sort of “document” container does makes sense for that (a ShadowRoot) in order to place all your search/navigation APIs. You got me thinking though—getElementById is currently not available on ShadowRoot right? Does that API in the host’s document find IDs in the shadow? I presume not given the guidelines you mentioned. I wonder what other APIs from Document are desired? I thought getElementById existed in ShadowRoot at some point but the latest Blink code doesn't have it. It looks like Blink has querySelector/querySelectorAll via ParentNode: https://chromium.googlesource.com/chromium/blink/+/master/Source/core/dom/shadow/ShadowRoot.idl https://chromium.googlesource.com/chromium/blink/+/master/Source/core/dom/shadow/ShadowRoot.idl https://chromium.googlesource.com/chromium/blink/+/master/Source/core/dom/ParentNode.idl - R. Niwa
Re: [Shadow] Q: Removable shadows (and an idea for lightweight shadows)?
On Thu, Mar 26, 2015 at 10:53 AM, Travis Leithead travis.leith...@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, 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[]. This part seems like a big step back to me. Shadow roots being actual nodes means that existing code and knowledge work against them. The API surface that you'd have to duplicate with shadow*() methods would be quite large. ·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.
RE: [Shadow] Q: Removable shadows (and an idea for lightweight shadows)?
From: Justin Fagnani [mailto:justinfagn...@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.
RE: [Shadow] Q: Removable shadows (and an idea for lightweight shadows)?
You make a series of excellent points.
In the sense that you have a new set of nodes to manage holistically, then
having some sort of “document” container does makes sense for that (a
ShadowRoot) in order to place all your search/navigation APIs.
You got me thinking though—getElementById is currently not available on
ShadowRoot right? Does that API in the host’s document find IDs in the shadow?
I presume not given the guidelines you mentioned. I wonder what other APIs from
Document are desired?
Back to the original question though… is removal of previously-created shadow
roots something that makes sense?
From: Elliott Sprehn [mailto:espr...@chromium.org]
Sent: Thursday, March 26, 2015 12:59 PM
To: Travis Leithead
Cc: Justin Fagnani; Dimitri Glazkov (dglaz...@google.com); Arron Eicholz; Anne
van Kesteren (ann...@annevk.nl); Ryosuke Niwa; WebApps WG
Subject: Re: [Shadow] Q: Removable shadows (and an idea for lightweight
shadows)?
On Thu, Mar 26, 2015 at 11:36 AM, Travis Leithead
travis.leith...@microsoft.commailto:travis.leith...@microsoft.com wrote:
From: Justin Fagnani
[mailto:justinfagn...@google.commailto:justinfagn...@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.
So if I want to query down into those children I need to do
element.shadowFirstChild.querySelectorAll or shadowFirstChild.getElementById?
That requires looking at all siblings in the shadowChildList, so I suppose
you'd want shadowQuerySelector, shadowGetElementById, etc? You also need to
duplicate elementFromPoint (FromRect, etc.) down to Element/Text or add special
shadow* versions since right now they only exist on Document and ShadowRoot.
I have to admit I have an allergic reaction to having an element like div
id=foo and then doing element.parentNode.querySelector(#foo) != div.
Another fundamental requirement of Shadow DOM is that you never accidentally
fall out or fall into a shadow and must always take an explicit step to get
there. Having shadow node's parentNode be the host breaks that.
We could make the parentNode be null like ShadowRoot of today, but you're still
stuck adding API duplication or writing code to iterate the shadowChildren list.
- E
Re: [Shadow] Q: Removable shadows (and an idea for lightweight shadows)?
On Thu, Mar 26, 2015 at 1:38 PM, Ryosuke Niwa rn...@apple.com wrote: On Mar 26, 2015, at 1:23 PM, Travis Leithead travis.leith...@microsoft.com wrote: You make a series of excellent points. In the sense that you have a new set of nodes to manage holistically, then having some sort of “document” container does makes sense for that (a ShadowRoot) in order to place all your search/navigation APIs. You got me thinking though—getElementById is currently not available on ShadowRoot right? Does that API in the host’s document find IDs in the shadow? I presume not given the guidelines you mentioned. I wonder what other APIs from Document are desired? I thought getElementById existed in ShadowRoot at some point but the latest Blink code doesn't have it. It looks like Blink has querySelector/querySelectorAll via ParentNode: https://chromium.googlesource.com/chromium/blink/+/master/Source/core/dom/shadow/ShadowRoot.idl https://chromium.googlesource.com/chromium/blink/+/master/Source/core/dom/ParentNode.idl The spec changed, https://dom.spec.whatwg.org/#interface-nonelementparentnode ShadowRoot is a DocumentFragment and DocumentFragment implements NonElementParentNode. - E
