W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2014

Re: Separating Transclusion Mechanisms for Inheritance and Data Binding

From: Dimitri Glazkov <dglazkov@chromium.org>
Date: Mon, 28 Apr 2014 11:25:07 -0700
Message-ID: <CADh5Ky0Fn4zgthsbYhEaYGDMK71GwGUfLU5x+J2=TqbcJE0+Lg@mail.gmail.com>
To: Ryosuke Niwa <rniwa@apple.com>
Cc: public-webapps <public-webapps@w3.org>
On Sun, Apr 27, 2014 at 2:36 PM, Ryosuke Niwa <rniwa@apple.com> wrote:

> On Apr 22, 2014, at 10:46 AM, Dimitri Glazkov <dglazkov@chromium.org>
> wrote:
>
> BTW, here's a jsbin that implements yield/transclude using existing Shadow
> DOM plumbing:
>
> http://jsbin.com/pacim/1/edit
>
>
> Thanks for an example.  That indeed polyfills the API we're proposing in
> terms of the currently spec'ed API.
>

Great!


>
> One important aspect of our proposal is to avoid having to rely on
> "shadowRoot" property on HTMLElement, which wouldn't exist in Type III
> encapsulation.
>

Note, that the access to element's shadowRoot happens from the element's
own implementation of a method.

If I were a developer of a framework that implements the idea you
suggested, I would do something like this:
http://jsbin.com/pacim/4/edit



>
> On Apr 22, 2014, at 11:06 AM, Dimitri Glazkov <dglazkov@chromium.org>
> wrote:
>
> Here's a jsbin that uses the shadow-as-function syntax and does the same
> thing:
>
> http://jsbin.com/peqoz/2/edit
>
>
> This one doesn't quite work as intended in that the insertion points in
> MyCardElement's shadow DOM could grab nodes from the light DOM.
>

Help me understand what you mean here. Which nodes will these insertion
points grab? Would love an example.

:DG<
Received on Monday, 28 April 2014 18:25:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:24 UTC