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:
-
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
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.
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(),
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(),
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
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
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
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
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[],
: 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
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
12 matches
Mail list logo
