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
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://
On Thu, Mar 26, 2015 at 1:38 PM, Ryosuke Niwa 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 “doc
> On Mar 26, 2015, at 1:23 PM, Travis Leithead
> 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
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(),
> ins
: Removable shadows (and an idea for lightweight
shadows)?
On Thu, Mar 26, 2015 at 11:36 AM, Travis Leithead
mailto:travis.leith...@microsoft.com>> wrote:
> From: Justin Fagnani
> [mailto:justinfagn...@google.com<mailto:justinfagn...@google.com>]
>> Elements expose this “sh
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(),
> ins
> On Mar 26, 2015, at 10:53 AM, Travis Leithead
> 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 wa
>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 shadow
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”
> 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[],
>> shadowC
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
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
13 matches
Mail list logo
