date:20150425

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-04-25 Thread Olli Pettay


On 04/25/2015 01:58 PM, Ryosuke Niwa wrote:



On Apr 25, 2015, at 1:17 PM, Olli Pettay  wrote:

On 04/25/2015 09:28 AM, Anne van Kesteren wrote:

On Sat, Apr 25, 2015 at 12:17 AM, Ryosuke Niwa  wrote:

In today's F2F, I've got an action item to come up with a concrete workable 
proposal for imperative API.  I had a great chat about this
afterwards with various people who attended F2F and here's a summary.  I'll 
continue to work with Dimitri & Erik to work out details in the
coming months (our deadline is July 13th).

https://gist.github.com/rniwa/2f14588926e1a11c65d3


I thought we came up with something somewhat simpler that didn't require adding 
an event or adding remove() for that matter:

https://gist.github.com/annevk/e9e61801fcfb251389ef



That is pretty much exactly how I was thinking the imperative API to work. 
(well, assuming errors in the example fixed)

An example explaining how this all works in case of nested shadow trees would 
be good. I assume the more nested shadow tree just may get some
nodes, which were already distributed, in the distributionList.


Right, that was the design we discussed.


How does the distribute() behave? Does it end up invoking distribution in all 
the nested shadow roots or only in the callee?


Yes, that's the only reason we need distribute() in the first place.  If we 
didn't have to care about redistribution, simply exposing methods to
insert/remove distributed nodes on content element is sufficient.


Should distribute callback be called automatically at the end of the microtask 
if there has been relevant[1] DOM mutations since the last manual
call to distribute()? That would make the API a bit simpler to use, if one 
wouldn't have to use MutationObservers.


That's a possibility.  It could be an option to specify as well.  But there 
might be components that are not interested in updating distributed
nodes for the sake of performance for example.  I'm not certain forcing 
everyone to always update distributed nodes is necessarily desirable given
the lack of experience with an imperative API for distributing nodes.


[1] Assuming we want to distribute only direct children, then any child list 
change or any attribute change in the children might cause
distribution() automatically.


I think that's a big if now that we've gotten rid of "select" attribute and 
multiple generations of shadow DOM.


It is not clear to me at all how you would handle the case when a node has 
several ancestors with shadow trees, and each of those want to distribute
the node to some insertion point.
Also, what is the use case to distribute non-direct descendants?





 As far as I could recall, one of
the reasons we only supported distributing direct children was so that we could implement 
"select" attribute and multiple generations of shadow
DOM.   If we wanted, we could always impose such a restriction in a declarative 
syntax and inheritance mechanism we add in v2 since those v2 APIs
are supposed to build on top of this imperative API.

Another big if is whether we even need to let each shadow DOM select nodes to 
redistribute.  If we don't need to support filtering distributed
nodes in insertion points for re-distribution (i.e. we either distribute 
everything under a given content element or nothing), then we don't need
all of this redistribution mechanism baked into the browser and the model where 
we just have insert/remove on content element will work.

- R. Niwa

Re: Minutes of Shadow DOM meeting

2015-04-25 Thread chaals

25.04.2015, 14:45, "Bjoern Hoehrmann" :
> * cha...@yandex-team.ru wrote:
>> We'll post a summary - there is most of one at
>> https://docs.google.com/spreadsheets/d/1hnCoaJTXkfSSHD5spISJ76nqbDcOVNMamgByiz3QWLA/edit?pli=1#gid=0
>
> Perhaps a document in some kind of open format would be a better medium
> than some proprietary application with unclear stability policies that
> does not work in my browser.
>> The minutes (thanks to Taylor Savage fora great scribing job) are at
>> http://www.w3.org/2015/04/25-webapps-minutes.html
>
> That contains just a few lines. Looks like the decade-old UTC day change
> bug is still plaguing the minutes generation tool.

Sigh. Well, alternatively it is the decades-old scribe forgetting to do the
thing right… I'll put together the minutes and repost them shortly.

I've attached a rough version but I'll need to do some more cleaning because I
made a mess halfway through. The content is there and legible at least…

> --
> Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
> D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de

cheers

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
cha...@yandex-team.ru - - - Find more at http://yandex.com
Title: Web apps Web COmponents meeting -- 24 Apr 2015

- DRAFT -
Web apps Web COmponents meeting
24 Apr 2015

Agenda

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-04-25 Thread Ryosuke Niwa

> On Apr 25, 2015, at 1:17 PM, Olli Pettay  wrote:
> 
> On 04/25/2015 09:28 AM, Anne van Kesteren wrote:
>> On Sat, Apr 25, 2015 at 12:17 AM, Ryosuke Niwa  wrote:
>>> In today's F2F, I've got an action item to come up with a concrete workable
>>> proposal for imperative API.  I had a great chat about this afterwards with
>>> various people who attended F2F and here's a summary.  I'll continue to work
>>> with Dimitri & Erik to work out details in the coming months (our deadline
>>> is July 13th).
>>> 
>>> https://gist.github.com/rniwa/2f14588926e1a11c65d3
>> 
>> I thought we came up with something somewhat simpler that didn't
>> require adding an event or adding remove() for that matter:
>> 
>>   https://gist.github.com/annevk/e9e61801fcfb251389ef
> 
> 
> That is pretty much exactly how I was thinking the imperative API to work.
> (well, assuming errors in the example fixed)
> 
> An example explaining how this all works in case of nested shadow trees would 
> be good.
> I assume the more nested shadow tree just may get some nodes, which were 
> already distributed, in the distributionList.

Right, that was the design we discussed.

> How does the distribute() behave? Does it end up invoking distribution in all 
> the nested shadow roots or only in the callee?

Yes, that's the only reason we need distribute() in the first place.  If we 
didn't have to care about redistribution, simply exposing methods to 
insert/remove distributed nodes on content element is sufficient.

> Should distribute callback be called automatically at the end of the 
> microtask if there has been relevant[1] DOM mutations since the last
> manual call to distribute()? That would make the API a bit simpler to use, if 
> one wouldn't have to use MutationObservers.

That's a possibility.  It could be an option to specify as well.  But there 
might be components that are not interested in updating distributed nodes for 
the sake of performance for example.  I'm not certain forcing everyone to 
always update distributed nodes is necessarily desirable given the lack of 
experience with an imperative API for distributing nodes.

> [1] Assuming we want to distribute only direct children, then any child list 
> change or any attribute change in the children
> might cause distribution() automatically.

I think that's a big if now that we've gotten rid of "select" attribute and 
multiple generations of shadow DOM.  As far as I could recall, one of the 
reasons we only supported distributing direct children was so that we could 
implement "select" attribute and multiple generations of shadow DOM.   If we 
wanted, we could always impose such a restriction in a declarative syntax and 
inheritance mechanism we add in v2 since those v2 APIs are supposed to build on 
top of this imperative API.

Another big if is whether we even need to let each shadow DOM select nodes to 
redistribute.  If we don't need to support filtering distributed nodes in 
insertion points for re-distribution (i.e. we either distribute everything 
under a given content element or nothing), then we don't need all of this 
redistribution mechanism baked into the browser and the model where we just 
have insert/remove on content element will work.

- R. Niwa

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-04-25 Thread Ryosuke Niwa

> On Apr 25, 2015, at 9:28 AM, Anne van Kesteren  wrote:
> 
> On Sat, Apr 25, 2015 at 12:17 AM, Ryosuke Niwa  wrote:
>> In today's F2F, I've got an action item to come up with a concrete workable
>> proposal for imperative API.  I had a great chat about this afterwards with
>> various people who attended F2F and here's a summary.  I'll continue to work
>> with Dimitri & Erik to work out details in the coming months (our deadline
>> is July 13th).
>> 
>> https://gist.github.com/rniwa/2f14588926e1a11c65d3
> 
> I thought we came up with something somewhat simpler that didn't
> require adding an event or adding remove() for that matter:
> 
>  https://gist.github.com/annevk/e9e61801fcfb251389ef 
> 

```js
var shadow = host.createShadowRoot({
  mode: "closed",
  distribute: (distributionList, insertionList) => {
for(var i = 0; i < distributionList.length; i++) {
  for(var ii = 0; ii < insertionList.length; ii++) {
var select = insertionList[ii].getAttribute("select")
if(select != null && distributionList[i].matches(select)) {
  insertionList[ii].add(distrubtionList[i])
} else if(select != null) {
  insertionList[ii].add(distrubtionList[i])
}
  }
}
  }
})
host.shadowRoot.distribute()
```

One major drawback of this API is computing insertionList is expensive because 
we'd have to either (where n is the number of nodes in the shadow DOM):
Maintain an ordered list of insertion points, which results in O(n) algorithm 
to run whenever a content element is inserted or removed.
Lazily compute the ordered list of insertion points when `distribute` callback 
is about to get called in O(n).

If we wanted to allow non-direct child descendent (e.g. grand child node) of 
the host to be distributed, then we'd also need O(m) algorithm where m is the 
number of under the host element.  It might be okay to carry on the current 
restraint that only direct child of shadow host can be distributed into 
insertion points but I can't think of a good reason as to why such a 
restriction is desirable.

- R. Niwa

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-04-25 Thread Olli Pettay

On 04/25/2015 09:28 AM, Anne van Kesteren wrote:

On Sat, Apr 25, 2015 at 12:17 AM, Ryosuke Niwa wrote:

In today's F2F, I've got an action item to come up with a concrete workable
proposal for imperative API. I had a great chat about this afterwards with
various people who attended F2F and here's a summary. I'll continue to work
with Dimitri & Erik to work out details in the coming months (our deadline
is July 13th).

https://gist.github.com/rniwa/2f14588926e1a11c65d3

I thought we came up with something somewhat simpler that didn't
require adding an event or adding remove() for that matter:

https://gist.github.com/annevk/e9e61801fcfb251389ef

That is pretty much exactly how I was thinking the imperative API to work.
(well, assuming errors in the example fixed)

An example explaining how this all works in case of nested shadow trees would
be good.
I assume the more nested shadow tree just may get some nodes, which were
already distributed, in the distributionList.

How does the distribute() behave? Does it end up invoking distribution in all
the nested shadow roots or only in the callee?

Should distribute callback be called automatically at the end of the microtask
if there has been relevant[1] DOM mutations since the last
manual call to distribute()? That would make the API a bit simpler to use, if
one wouldn't have to use MutationObservers.
(even then one could skip distribution say for example during page load time and do a page level "distribute all the stuff" once all the data is ready
etc, if wanted.).

-Olli

[1] Assuming we want to distribute only direct children, then any child list
change or any attribute change in the children
might cause distribution() automatically.

I added an example there that shows how you could implement , it's rather trivial with the matches() API. I think you can
derive any other use case easily from that example, though I'm willing
to help guide people through others if it is unclear. I guess we might
still want positional insertion as a convenience though the above
seems to be all you need primitive-wise.

Re: :host pseudo-class

2015-04-25 Thread Daniel Tan


On 4/26/2015 12:32 AM, Anne van Kesteren wrote:

I don't understand why :host is a pseudo-class rather than a
pseudo-element. My mental model of a pseudo-class is that it allows
you to match an element based on a boolean internal slot of that
element. :host is not that since e.g. * does not match :host as I
understand it. That seems super weird. Why not just use ::host?

Copying WebApps since this affects everyone caring about Shadow DOM.




My guess is it's because a shadow host element is an element, not a
pseudo-element.

The reason * doesn't match :host is because the host element, in the
context of its shadow tree, is featureless, as mentioned in [1]section
3.1.1 of css-scoping and [2]section 3.3 of selectors-4.

Does the following note in css-scoping 3.1.1 answer your question?


Why is the shadow host so weird?

The shadow host lives outside the shadow tree, and its markup is in
control of the page author, not the component author.

It would not be very good if a component used a particular class name
internally in a shadow tree, and the page author using the component
accidentally also used the the same class name and put it on the host
element. Such a situation would result in accidental styling that is
impossible for the component author to predict, and confusing for the
page author to debug.

However, there are still some reasonable use-cases for letting a
stylesheet in a shadow tree style its host element. So, to allow this
situation but prevent accidental styling, the host element appears
but is completely featureless and unselectable except through :host.


[1]: http://dev.w3.org/csswg/css-scoping-1/#host-element-in-tree
[2]: http://dev.w3.org/csswg/selectors-4/#data-model

--
Daniel Tan
NOVALISTIC

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-04-25 Thread Hayato Ito

Thanks. I am really glad to see more and more guys are thinking about
Shadow DOM.
I know distribution/re-distributions is a tough issue. A lot of exciting
things are waiting for you. :)

On Sat, Apr 25, 2015 at 10:19 AM Ryosuke Niwa  wrote:

> Sure, I'll put the summary of discussion there later.
>
> - R. Niwa
>
> On Apr 25, 2015, at 10:00 AM, Hayato Ito  wrote:
>
> Thank you, guys.
> I really appreciate if you guys could use the W3C bug, 18429, to discuss
> this kind of specific topic about Shadow DOM so that we can track the
> progress easily in one place. I'm not fan of the discussion being
> scattered. :)
>
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18429
>
>
> On Sat, Apr 25, 2015 at 9:32 AM Anne van Kesteren 
> wrote:
>
>> On Sat, Apr 25, 2015 at 12:17 AM, Ryosuke Niwa  wrote:
>> > In today's F2F, I've got an action item to come up with a concrete
>> workable
>> > proposal for imperative API.  I had a great chat about this afterwards
>> with
>> > various people who attended F2F and here's a summary.  I'll continue to
>> work
>> > with Dimitri & Erik to work out details in the coming months (our
>> deadline
>> > is July 13th).
>> >
>> > https://gist.github.com/rniwa/2f14588926e1a11c65d3
>>
>> I thought we came up with something somewhat simpler that didn't
>> require adding an event or adding remove() for that matter:
>>
>>   https://gist.github.com/annevk/e9e61801fcfb251389ef
>>
>> I added an example there that shows how you could implement > select>, it's rather trivial with the matches() API. I think you can
>> derive any other use case easily from that example, though I'm willing
>> to help guide people through others if it is unclear. I guess we might
>> still want positional insertion as a convenience though the above
>> seems to be all you need primitive-wise.
>>
>>
>> --
>> https://annevankesteren.nl/
>>
>>

RE: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-04-25 Thread Travis Leithead

Nice work folks, and thanks for writing this up so quickly! Anne's Gist 
captured exactly what I was thinking this would look like.

One nit: it would be nice if the callback could be registered from _inside_ the 
shadowRoot, but I couldn't come up with a satisfactory way to do that without 
adding more complexity. :)

-Original Message-
From: Ryosuke Niwa [mailto:rn...@apple.com] 
Sent: Saturday, April 25, 2015 10:13 AM
To: Anne van Kesteren
Cc: WebApps WG; Erik Bryn; Dimitri Glazkov
Subject: Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

> On Apr 25, 2015, at 9:28 AM, Anne van Kesteren  wrote:
> 
>> On Sat, Apr 25, 2015 at 12:17 AM, Ryosuke Niwa  wrote:
>> In today's F2F, I've got an action item to come up with a concrete workable
>> proposal for imperative API.  I had a great chat about this afterwards with
>> various people who attended F2F and here's a summary.  I'll continue to work
>> with Dimitri & Erik to work out details in the coming months (our deadline
>> is July 13th).
>> 
>> https://gist.github.com/rniwa/2f14588926e1a11c65d3
> 
> I thought we came up with something somewhat simpler that didn't
> require adding an event or adding remove() for that matter:

That's the second approach I mentioned.  Like I mentioned in the gist, this 
model assumes that redistribution is done by UA and only direct children can be 
distributed.  I realized that those constraints are no longer necessary given 
we don't have content select or multiple generations of shadow DOM.

>  https://gist.github.com/annevk/e9e61801fcfb251389ef
> 
> I added an example there that shows how you could implement  select>, it's rather trivial with the matches() API. I think you can
> derive any other use case easily from that example, though I'm willing
> to help guide people through others if it is unclear. I guess we might
> still want positional insertion as a convenience though the above
> seems to be all you need primitive-wise.
> 
> 
> -- 
> https://annevankesteren.nl/
>

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-04-25 Thread Ryosuke Niwa

Sure, I'll put the summary of discussion there later.

- R. Niwa

> On Apr 25, 2015, at 10:00 AM, Hayato Ito  wrote:
> 
> Thank you, guys.
> I really appreciate if you guys could use the W3C bug, 18429, to discuss this 
> kind of specific topic about Shadow DOM so that we can track the progress 
> easily in one place. I'm not fan of the discussion being scattered. :)
> 
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18429
> 
> 
>> On Sat, Apr 25, 2015 at 9:32 AM Anne van Kesteren  wrote:
>> On Sat, Apr 25, 2015 at 12:17 AM, Ryosuke Niwa  wrote:
>> > In today's F2F, I've got an action item to come up with a concrete workable
>> > proposal for imperative API.  I had a great chat about this afterwards with
>> > various people who attended F2F and here's a summary.  I'll continue to 
>> > work
>> > with Dimitri & Erik to work out details in the coming months (our deadline
>> > is July 13th).
>> >
>> > https://gist.github.com/rniwa/2f14588926e1a11c65d3
>> 
>> I thought we came up with something somewhat simpler that didn't
>> require adding an event or adding remove() for that matter:
>> 
>>   https://gist.github.com/annevk/e9e61801fcfb251389ef
>> 
>> I added an example there that shows how you could implement > select>, it's rather trivial with the matches() API. I think you can
>> derive any other use case easily from that example, though I'm willing
>> to help guide people through others if it is unclear. I guess we might
>> still want positional insertion as a convenience though the above
>> seems to be all you need primitive-wise.
>> 
>> 
>> --
>> https://annevankesteren.nl/

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-04-25 Thread Ryosuke Niwa


> On Apr 25, 2015, at 9:28 AM, Anne van Kesteren  wrote:
> 
>> On Sat, Apr 25, 2015 at 12:17 AM, Ryosuke Niwa  wrote:
>> In today's F2F, I've got an action item to come up with a concrete workable
>> proposal for imperative API.  I had a great chat about this afterwards with
>> various people who attended F2F and here's a summary.  I'll continue to work
>> with Dimitri & Erik to work out details in the coming months (our deadline
>> is July 13th).
>> 
>> https://gist.github.com/rniwa/2f14588926e1a11c65d3
> 
> I thought we came up with something somewhat simpler that didn't
> require adding an event or adding remove() for that matter:

That's the second approach I mentioned.  Like I mentioned in the gist, this 
model assumes that redistribution is done by UA and only direct children can be 
distributed.  I realized that those constraints are no longer necessary given 
we don't have content select or multiple generations of shadow DOM.

>  https://gist.github.com/annevk/e9e61801fcfb251389ef
> 
> I added an example there that shows how you could implement  select>, it's rather trivial with the matches() API. I think you can
> derive any other use case easily from that example, though I'm willing
> to help guide people through others if it is unclear. I guess we might
> still want positional insertion as a convenience though the above
> seems to be all you need primitive-wise.
> 
> 
> -- 
> https://annevankesteren.nl/
>

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-04-25 Thread Hayato Ito

Thank you, guys.
I really appreciate if you guys could use the W3C bug, 18429, to discuss
this kind of specific topic about Shadow DOM so that we can track the
progress easily in one place. I'm not fan of the discussion being scattered.
:)

https://www.w3.org/Bugs/Public/show_bug.cgi?id=18429


On Sat, Apr 25, 2015 at 9:32 AM Anne van Kesteren  wrote:

> On Sat, Apr 25, 2015 at 12:17 AM, Ryosuke Niwa  wrote:
> > In today's F2F, I've got an action item to come up with a concrete
> workable
> > proposal for imperative API.  I had a great chat about this afterwards
> with
> > various people who attended F2F and here's a summary.  I'll continue to
> work
> > with Dimitri & Erik to work out details in the coming months (our
> deadline
> > is July 13th).
> >
> > https://gist.github.com/rniwa/2f14588926e1a11c65d3
>
> I thought we came up with something somewhat simpler that didn't
> require adding an event or adding remove() for that matter:
>
>   https://gist.github.com/annevk/e9e61801fcfb251389ef
>
> I added an example there that shows how you could implement  select>, it's rather trivial with the matches() API. I think you can
> derive any other use case easily from that example, though I'm willing
> to help guide people through others if it is unclear. I guess we might
> still want positional insertion as a convenience though the above
> seems to be all you need primitive-wise.
>
>
> --
> https://annevankesteren.nl/
>
>

:host pseudo-class

2015-04-25 Thread Anne van Kesteren

I don't understand why :host is a pseudo-class rather than a
pseudo-element. My mental model of a pseudo-class is that it allows
you to match an element based on a boolean internal slot of that
element. :host is not that since e.g. * does not match :host as I
understand it. That seems super weird. Why not just use ::host?

Copying WebApps since this affects everyone caring about Shadow DOM.


-- 
https://annevankesteren.nl/

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-04-25 Thread Anne van Kesteren

On Sat, Apr 25, 2015 at 12:17 AM, Ryosuke Niwa  wrote:
> In today's F2F, I've got an action item to come up with a concrete workable
> proposal for imperative API.  I had a great chat about this afterwards with
> various people who attended F2F and here's a summary.  I'll continue to work
> with Dimitri & Erik to work out details in the coming months (our deadline
> is July 13th).
>
> https://gist.github.com/rniwa/2f14588926e1a11c65d3

I thought we came up with something somewhat simpler that didn't
require adding an event or adding remove() for that matter:

  https://gist.github.com/annevk/e9e61801fcfb251389ef

I added an example there that shows how you could implement , it's rather trivial with the matches() API. I think you can
derive any other use case easily from that example, though I'm willing
to help guide people through others if it is unclear. I guess we might
still want positional insertion as a convenience though the above
seems to be all you need primitive-wise.

-- 
https://annevankesteren.nl/

Re: Minutes of Shadow DOM meeting

2015-04-25 Thread Arthur Barstow


On 4/25/15 8:45 AM, Bjoern Hoehrmann wrote:

* cha...@yandex-team.ru wrote:

We'll post a summary - there is most of one at
https://docs.google.com/spreadsheets/d/1hnCoaJTXkfSSHD5spISJ76nqbDcOVNMamgByiz3QWLA/edit?pli=1#gid=0

Perhaps a document in some kind of open format would be a better medium
than some proprietary application with unclear stability policies that
does not work in my browser.


I just copied the data in the above document to the meeting's agenda page:

Re: Minutes of Shadow DOM meeting

2015-04-25 Thread Arthur Barstow


On 4/25/15 8:45 AM, Bjoern Hoehrmann wrote:

* cha...@yandex-team.ru wrote:

http://www.w3.org/2015/04/25-webapps-minutes.html


See .


That contains just a few lines. Looks like the decade-old UTC day change
bug is still plaguing the minutes generation tool.

Re: Minutes of Shadow DOM meeting

2015-04-25 Thread Bjoern Hoehrmann

* cha...@yandex-team.ru wrote:
>We'll post a summary - there is most of one at
>https://docs.google.com/spreadsheets/d/1hnCoaJTXkfSSHD5spISJ76nqbDcOVNMamgByiz3QWLA/edit?pli=1#gid=0
> 

Perhaps a document in some kind of open format would be a better medium
than some proprietary application with unclear stability policies that
does not work in my browser.

>The minutes (thanks to Taylor Savage fora  great scribing job) are at 
>http://www.w3.org/2015/04/25-webapps-minutes.html

That contains just a few lines. Looks like the decade-old UTC day change
bug is still plaguing the minutes generation tool.
-- 
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de

[Shadow DOM] Use Cases for Selective Redistributions

2015-04-25 Thread Ryosuke Niwa

Hi,

Could someone give me a concrete use cases for node redistributions where the 
second and subsequent insertion points need to redistribute a subset of nodes 
that have been redistributed to an insertion point in an earlier shadow DOM?  
Maybe someone at Google working on Polymer would have one?

Wasn't this feature was needed in inheritance cases when we had multiple 
generations of shadow DOM (which we just decided to remove from the spec)?

If we don't need to redistribute a subset of nodes (at least for the majority 
of use cases we care about in v1), then we could just not worry about node 
redistributions in our imperative API.  Note that we can "redistribute" the 
entire content element just fine since a content element can be distributed 
along with its distributed nodes as one piece.

- R. Niwa

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-04-25 Thread Ryosuke Niwa

Just to clarity, I obviously haven't had a time to discuss this with my 
colleagues so I don't know which one (or something else entirely) we (Apple) 
end up endorsing/opposing at the end.

> On Apr 25, 2015, at 12:14 AM, Ryosuke Niwa  wrote:
> 
> Hi all,
> 
> In today's F2F, I've got an action item to come up with a concrete workable 
> proposal for imperative API.  I had a great chat about this afterwards with 
> various people who attended F2F and here's a summary.  I'll continue to work 
> with Dimitri & Erik to work out details in the coming months (our deadline is 
> July 13th).
> 
> https://gist.github.com/rniwa/2f14588926e1a11c65d3 
> 
> 
> Imperative API for Node Distribution in Shadow DOM
> 
> There are two approaches to the problem depending on whether we want to 
> natively support redistribution or not.
> 
> To recap, a redistribution of a node (N_1) happens when it's distributed to 
> an insertion point (I_1) inside a shadow root (S_1), and I_1's parent also 
> has a shadow root which contains an insertion point which ends picking up 
> N_1. e.g. the original tree may look like:
> 
> (host of S_1) - S_1
>   + N_1 + (host of S_2) - S_2
>+ I_1   + I_2
> Here, (host of S_1) has N_1 as a child, and (host of S_2) is a child of S_1 
> and has I_1 as a child. S_2 has I_2 as a child. The composed tree, then, may 
> look like:
> 
> (host of S_1)
>  + (host of S_2)
>+ I_2
>  + N_1
>  
> Redistribution
>  is implemented by authors
> 
> In this model, we can add insertAt and remove on content element and expose 
> distributedNodes defined as follows:
> 
> insertAt(Node nodeToDistribute, long index) - Inserts nodeToDistribute to the 
> list of the distributed nodes at index. It throws if nodeToDistribute is not 
> a descendent (or a direct child if wanted to keep this constraint) of the 
> shadow host of the ancestor shadow root of containt or if index is larger 
> than the length of distributedNodes.
> remove(Node distributedNode) - Remove distributedNode from the list 
> distributed nodes. Throws if distributedNodes doesn't contain this node.
> distributedNodes - Returns an array of nodes that are distributed into this 
> insertion point in the order they appear.
> In addition, content fires a synchrnous distributionchanged event when 
> distributedNodeschanges (in response to calls to insertAt or remove). 
> 
>  Pros
> 
> Very simple / very primitive looking.
> Defers the exact mechanism/algorithm of re-distributions to component authors.
> We can support distributing any descendent, not just direct children, to any 
> insertion points. This was not possible with select attribute especially with 
> the presence of multiple generations of shadow DOM due to perfomance problems.
> Allows distributed nodes to be re-ordered (select doesn't allow this).
>  Cons
> 
> Each component needs to manually implement re-distributions by recursively 
> traversing through distributedNodes of content elements inside 
> distributedNodes of the content element if it didn't want to re-distribute 
> everything. This is particularly challenging because you need to listen to 
> distributionchanged event on every such content element. We might need 
> something aking to MutationObserver's subtree option to monitor this if we're 
> going this route.
> It seems hard to support re-distribution natively in v2.
>  
> Redistribution
>  is implemented by UAs
> 
> In this model, the browser is responsible for taking care of redistributions. 
> Namely, we would like to expose distributionPool on the shadow root which 
> contains the ordered list of nodes that could be distributed (because they're 
> direct children of the host) or re-distributed. Conceptually, you could think 
> of it as a depth first traversal of distributedNodes of every content 
> element. Because this list contains every candidate for (re)distribution, 
> it's impractical to include every descendent node especially if we wanted to 
> do synchronous updates so we're back to supporting only direct children for 
> distribution.
> 
> In this proposal, we add a new callback distributeCallback(NodeList 
> distributionPool) as an arguemnt (probably inside a dictionary) to 
> createShadowRoot. e.g.
> 
> var shadowRoot = element.createShadowRoot({
>   distributedCallback: function (distributionPool) {
> ... // code to distribute nodes
>   }
> });
> Unfortunately, we can't really use insertAt and remove in model because 
> distributionPoolmaybe changed under the foot by (outer) insertion points in 
> the light DOM if this shadow root to attached to a host inside another shadow 
> DOM un

Imperative API for Node Distribution in Shadow DOM (Revisited)

2015-04-25 Thread Ryosuke Niwa

Hi all,

In today's F2F, I've got an action item to come up with a concrete workable 
proposal for imperative API.  I had a great chat about this afterwards with 
various people who attended F2F and here's a summary.  I'll continue to work 
with Dimitri & Erik to work out details in the coming months (our deadline is 
July 13th).

https://gist.github.com/rniwa/2f14588926e1a11c65d3 


Imperative API for Node Distribution in Shadow DOM

There are two approaches to the problem depending on whether we want to 
natively support redistribution or not.

To recap, a redistribution of a node (N_1) happens when it's distributed to an 
insertion point (I_1) inside a shadow root (S_1), and I_1's parent also has a 
shadow root which contains an insertion point which ends picking up N_1. e.g. 
the original tree may look like:

(host of S_1) - S_1
  + N_1 + (host of S_2) - S_2
   + I_1   + I_2
Here, (host of S_1) has N_1 as a child, and (host of S_2) is a child of S_1 and 
has I_1 as a child. S_2 has I_2 as a child. The composed tree, then, may look 
like:

(host of S_1)
 + (host of S_2)
   + I_2
 + N_1
 
Redistribution
 is implemented by authors

In this model, we can add insertAt and remove on content element and expose 
distributedNodes defined as follows:

insertAt(Node nodeToDistribute, long index) - Inserts nodeToDistribute to the 
list of the distributed nodes at index. It throws if nodeToDistribute is not a 
descendent (or a direct child if wanted to keep this constraint) of the shadow 
host of the ancestor shadow root of containt or if index is larger than the 
length of distributedNodes.
remove(Node distributedNode) - Remove distributedNode from the list distributed 
nodes. Throws if distributedNodes doesn't contain this node.
distributedNodes - Returns an array of nodes that are distributed into this 
insertion point in the order they appear.
In addition, content fires a synchrnous distributionchanged event when 
distributedNodeschanges (in response to calls to insertAt or remove). 

 Pros

Very simple / very primitive looking.
Defers the exact mechanism/algorithm of re-distributions to component authors.
We can support distributing any descendent, not just direct children, to any 
insertion points. This was not possible with select attribute especially with 
the presence of multiple generations of shadow DOM due to perfomance problems.
Allows distributed nodes to be re-ordered (select doesn't allow this).
 Cons

Each component needs to manually implement re-distributions by recursively 
traversing through distributedNodes of content elements inside distributedNodes 
of the content element if it didn't want to re-distribute everything. This is 
particularly challenging because you need to listen to distributionchanged 
event on every such content element. We might need something aking to 
MutationObserver's subtree option to monitor this if we're going this route.
It seems hard to support re-distribution natively in v2.
 
Redistribution
 is implemented by UAs

In this model, the browser is responsible for taking care of redistributions. 
Namely, we would like to expose distributionPool on the shadow root which 
contains the ordered list of nodes that could be distributed (because they're 
direct children of the host) or re-distributed. Conceptually, you could think 
of it as a depth first traversal of distributedNodes of every content element. 
Because this list contains every candidate for (re)distribution, it's 
impractical to include every descendent node especially if we wanted to do 
synchronous updates so we're back to supporting only direct children for 
distribution.

In this proposal, we add a new callback distributeCallback(NodeList 
distributionPool) as an arguemnt (probably inside a dictionary) to 
createShadowRoot. e.g.

var shadowRoot = element.createShadowRoot({
  distributedCallback: function (distributionPool) {
... // code to distribute nodes
  }
});
Unfortunately, we can't really use insertAt and remove in model because 
distributionPoolmaybe changed under the foot by (outer) insertion points in the 
light DOM if this shadow root to attached to a host inside another shadow DOM 
unless we manually listen to distributionchangedevent on every content (which 
may recursively appear in distributedNodes of those content).

One way to work around this problem is let UA also propagate changes to 
distributionPool to each nested shadow DOM. That is, when distributionPool of a 
shadow root gets modified due to changes to distributionPools of direct 
children (of the shadow host) that are content elements themselves, UA w

Re: Proposal for changes to manage Shadow DOM content distribution

2015-04-25 Thread Ryosuke Niwa


> On Apr 24, 2015, at 2:23 PM, Tab Atkins Jr.  wrote:
> 
> On Wed, Apr 22, 2015 at 5:04 PM, Ryosuke Niwa  wrote:
>> I find it decidedly relevant given I'm pointing out that attribute-specified
>> slots Domenic mentioned isn't what you described.  Since the only venue in
>> which attribute-specified slots came up are [1], [2], and [3].  We're
>> DEFINITELY NOT interested in filling slots based on values of arbitrary
>> attributes.
>> 
>> [1] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0188.html
>> [2] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0190.html
>> [3] https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0195.html
> 
> Apologies, I'd misread [1] and didn't realize it really was talking
> about projecting the value of an attribute into the content of a slot.
> 
> (Though I'm confused by the vehemence of your denial here, given that
> in [2] you said you "could imagine that such a feature could be easily
> added".)

What I meant is that we don't want a declarative syntax to filling a slot based 
with elements based on attribute values of those elements.  I'm less concerned 
about distributing the value of an attribute to a slot based on its attribute 
name.

Regardless, all of this is moot for foreseeable future given we just reached a 
consensus to focus on an imperative API for v1 on today's F2F.

- R. Niwa

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

Re: Minutes of Shadow DOM meeting

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

Re: :host pseudo-class

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

RE: Imperative API for Node Distribution in Shadow DOM (Revisited)

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

:host pseudo-class

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

Re: Minutes of Shadow DOM meeting

Re: Minutes of Shadow DOM meeting

Re: Minutes of Shadow DOM meeting

[Shadow DOM] Use Cases for Selective Redistributions

Re: Imperative API for Node Distribution in Shadow DOM (Revisited)

Imperative API for Node Distribution in Shadow DOM (Revisited)

Re: Proposal for changes to manage Shadow DOM content distribution

20 matches

Site Navigation

Mail list logo

Footer information