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

> On May 7, 2015, at 7:20 PM, Hayato Ito wrote: > > Ryosuke, could you file a bug for the spec if you find an uncomfortable part > in the spec? > I want to understand exactly what you are trying to improve. I don't think there is any issue with the spec per se. What Anne and I both are point

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

Ryosuke, could you file a bug for the spec if you find an uncomfortable part in the spec? I want to understand exactly what you are trying to improve. On Fri, May 8, 2015 at 2:21 AM Ryosuke Niwa wrote: > > > On May 6, 2015, at 11:10 PM, Elliott Sprehn > wrote: > > > > On Wed, May 6, 2015 at 11:

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

> On May 6, 2015, at 11:10 PM, Elliott Sprehn wrote: > > On Wed, May 6, 2015 at 11:08 PM, Anne van Kesteren wrote: >> On Thu, May 7, 2015 at 6:02 AM, Hayato Ito wrote: >> > I'm saying: >> > - Composed tree is related with CSS. >> > - Node distribution should be considered as a part of style co

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

Yeah, we, in Google, had several discussion about how the next *Selection APIs* should be. However we don't have any concrete proposals yet. We are aware that we need the new APIs because the existing APIs is not suitable. On Thu, May 7, 2015 at 3:10 PM Elliott Sprehn wrote: > On Wed, May 6, 201

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

On Wed, May 6, 2015 at 11:08 PM, Anne van Kesteren wrote: > On Thu, May 7, 2015 at 6:02 AM, Hayato Ito wrote: > > I'm saying: > > - Composed tree is related with CSS. > > - Node distribution should be considered as a part of style concept. > > Right, I think Ryosuke and I simply disagree with th

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

On Thu, May 7, 2015 at 6:02 AM, Hayato Ito wrote: > I'm saying: > - Composed tree is related with CSS. > - Node distribution should be considered as a part of style concept. Right, I think Ryosuke and I simply disagree with that assessment. CSS operates on the composed tree (and forms a render tr

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

I'm not saying the event path is not related to a composed tree. I'm saying: - Composed tree is related with CSS. - Node distribution should be considered as a part of style concept. On Thu, May 7, 2015 at 12:54 PM Ryosuke Niwa wrote: > > > On May 6, 2015, at 6:18 PM, Hayato Ito wrote: > > >

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

> On May 6, 2015, at 6:18 PM, Hayato Ito wrote: > > On Wed, May 6, 2015 at 10:22 AM Ryosuke Niwa wrote: >> >> > On May 5, 2015, at 11:55 AM, Tab Atkins Jr. wrote: >> > >> > On Tue, May 5, 2015 at 11:20 AM, Ryosuke Niwa wrote: >> >>> On May 4, 2015, at 10:20 PM, Anne van Kesteren wrote: >> >

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

I'm feeling that there is a misunderstanding about the relation between DOM tree and Composed Tree in this discussion. If you understand the difference, the discussion might be more productive. In short, - Composed Tree DOES NOT replace DOM tree. Most of existing APIs work for DOM tree. Composed T

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

On Wed, May 6, 2015 at 10:22 AM Ryosuke Niwa wrote: > > > On May 5, 2015, at 11:55 AM, Tab Atkins Jr. > wrote: > > > > On Tue, May 5, 2015 at 11:20 AM, Ryosuke Niwa wrote: > >>> On May 4, 2015, at 10:20 PM, Anne van Kesteren > wrote: > >>> > On Tue, May 5, 2015 at 6:58 AM, Elliott Sprehn

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

> On May 5, 2015, at 10:53 PM, Anne van Kesteren wrote: > > On Wed, May 6, 2015 at 3:22 AM, Ryosuke Niwa wrote: >> Where? I have not yet to see a use case for which selective redistribution >> of nodes (i.e. redistributing only a non-empty strict subset of nodes from >> an insertion point) a

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

On Wed, May 6, 2015 at 3:22 AM, Ryosuke Niwa wrote: > Where? I have not yet to see a use case for which selective redistribution > of nodes (i.e. redistributing only a non-empty strict subset of nodes from an > insertion point) are required. Isn't that what e.g. does? That is, only cares abo

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

> On May 5, 2015, at 11:55 AM, Tab Atkins Jr. wrote: > > On Tue, May 5, 2015 at 11:20 AM, Ryosuke Niwa wrote: >>> On May 4, 2015, at 10:20 PM, Anne van Kesteren wrote: >>> On Tue, May 5, 2015 at 6:58 AM, Elliott Sprehn wrote: We can solve this problem by running the dist

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

On Tue, May 5, 2015 at 11:20 AM, Ryosuke Niwa wrote: >> On May 4, 2015, at 10:20 PM, Anne van Kesteren wrote: >> >>> On Tue, May 5, 2015 at 6:58 AM, Elliott Sprehn wrote: >>> We can solve this >>> problem by running the distribution code in a separate scripting context >>> with a restricted (dis

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

> On May 4, 2015, at 10:20 PM, Anne van Kesteren wrote: > >> On Tue, May 5, 2015 at 6:58 AM, Elliott Sprehn wrote: >> We can solve this >> problem by running the distribution code in a separate scripting context >> with a restricted (distribution specific) API as is being discussed for >> other

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

On Tue, May 5, 2015 at 6:58 AM, Elliott Sprehn wrote: > We can solve this > problem by running the distribution code in a separate scripting context > with a restricted (distribution specific) API as is being discussed for > other extension points in the platform. That seems like a lot of added c

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

On Thu, Apr 30, 2015 at 6:22 AM, Anne van Kesteren wrote: > On Thu, Apr 30, 2015 at 3:05 PM, Hayato Ito wrote: > > That's the exactly intended behavior in the current spec. > > The timing of distribution is not observable. > > Right, but you can synchronously observe whether something is > distr

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

> On Apr 30, 2015, at 9:01 PM, Hayato Ito wrote: > > Thanks, however, we're talking about > https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0442.html. Ah, I think there was some miscommunication there. I don't think anyone is claiming that the current spec results in interop is

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

> On Apr 30, 2015, at 9:25 PM, Elliott Sprehn wrote: > > On Thu, Apr 30, 2015 at 8:57 PM, Ryosuke Niwa wrote: >> ... >> > >> > The return value of (2) is the same in either case. There is no observable >> > difference. No interop issue. >> > >> > Please file a bug for the spec with a concrete

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

On Thu, Apr 30, 2015 at 8:57 PM, Ryosuke Niwa wrote: > ... > > > > The return value of (2) is the same in either case. There is no > observable difference. No interop issue. > > > > Please file a bug for the spec with a concrete example if you can find a > observable difference due to the lazy-ev

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

Thanks, however, we're talking about https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0442.html. On Fri, May 1, 2015 at 12:57 PM Ryosuke Niwa wrote: > On Apr 30, 2015, at 8:17 PM, Hayato Ito wrote: > > On Fri, May 1, 2015 at 2:59 AM Ryosuke Niwa wrote: > >> > >> > On Apr 30, 2015

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

On Apr 30, 2015, at 8:17 PM, Hayato Ito wrote: > On Fri, May 1, 2015 at 2:59 AM Ryosuke Niwa wrote: >> >> > On Apr 30, 2015, at 6:00 AM, Domenic Denicola wrote: >> > >> >> This essentially forces distribution to happen since you can observe the >> >> result of distribution this way. Same with

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

On Fri, May 1, 2015 at 2:59 AM Ryosuke Niwa wrote: > > > On Apr 30, 2015, at 6:00 AM, Domenic Denicola wrote: > > > >> This essentially forces distribution to happen since you can observe > the result of distribution this way. Same with element.offsetWidth etc. And > that's not necessarily probl

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

> On Apr 30, 2015, at 6:00 AM, Domenic Denicola wrote: > >> This essentially forces distribution to happen since you can observe the >> result of distribution this way. Same with element.offsetWidth etc. And >> that's not necessarily problematic, > > OK. So the claim that the current spec can

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

> On Apr 30, 2015, at 5:12 AM, Anne van Kesteren wrote: > > On Mon, Apr 27, 2015 at 11:05 PM, Ryosuke Niwa wrote: >> I’m writing any kind of component that creates a shadow DOM, I’d just keep >> references to all my insertion points instead of querying them each time I >> need to distribute n

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

> On Apr 30, 2015, at 5:12 AM, Anne van Kesteren wrote: > > On Mon, Apr 27, 2015 at 11:05 PM, Ryosuke Niwa wrote: >>> The other thing I would like to explore is what an API would look like >>> that does the subclassing as well. >> >> For the slot approach, we can model the act of filling a slo

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

On Thu, Apr 30, 2015 at 3:05 PM, Hayato Ito wrote: > That's the exactly intended behavior in the current spec. > The timing of distribution is not observable. Right, but you can synchronously observe whether something is distributed. The combination of those two things coupled with us not wanting

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

On Thu, Apr 30, 2015 at 3:00 PM, Domenic Denicola wrote: > OK. So the claim that the current spec cannot be interoperably implemented is > false? Well, the wording could be improved for sure. If you're new to this you might get confused. > Why can't we say that this distributedCallback must be

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

On Thu, Apr 30, 2015 at 9:54 PM Anne van Kesteren wrote: > On Thu, Apr 30, 2015 at 2:44 PM, Domenic Denicola wrote: > > From: Anne van Kesteren > >> var x = new Event(eventType) > >> someNodeThatIsDistributed.addEventListener(eventType, e => > console.log(e.path)) > >> someNodeThatIsDistribu

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

On Thu, Apr 30, 2015 at 2:44 PM, Domenic Denicola wrote: > From: Anne van Kesteren >> var x = new Event(eventType) >> someNodeThatIsDistributed.addEventListener(eventType, e => >> console.log(e.path)) >> someNodeThatIsDistributed.dispatchEvent(ev); > > Can you explain in a bit more detail why

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

On Tue, Apr 28, 2015 at 5:48 AM, Ryosuke Niwa wrote: > One thing that worries me about the `distribute` callback approach (a.k.a. > Anne's approach) is that it bakes distribution algorithm into the platform > without us having thoroughly studied how subclassing will be done upfront. Agreed. Dim

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

On Thu, Apr 30, 2015 at 2:30 PM, Domenic Denicola wrote: > Can someone point me to the part of the spec that is problematic? That is, > where is the line that says "UAs may run this algorithm at any time"? I am > not sure what to Ctrl+F for. At the end of section 3.4 it states "If any condition w

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

On Tue, Apr 28, 2015 at 12:31 AM, Hayato Ito wrote: > I think there are a lot of user operations where distribution must be > updated before returning the meaningful result synchronously. > Unless distribution result is correctly updated, users would take the dirty > result. > > For example: > - e

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

On Mon, Apr 27, 2015 at 11:05 PM, Ryosuke Niwa wrote: > I’m writing any kind of component that creates a shadow DOM, I’d just keep > references to all my insertion points instead of querying them each time I > need to distribute nodes. I guess that is true if you know you're not going to modify

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

> On Apr 29, 2015, at 5:12 PM, Justin Fagnani wrote: > > Here's one case of redistribution: > https://github.com/Polymer/core-scaffold/blob/master/core-scaffold.html#L122 > > Any time you see inside a custom element it's potentially > redistribution. Here there's on that is (line 122), and o

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

On Wed, Apr 29, 2015 at 5:59 PM, Ryosuke Niwa wrote: > > > On Apr 29, 2015, at 4:16 PM, Dimitri Glazkov > wrote: > > > > On Tue, Apr 28, 2015 at 1:52 PM, Ryosuke Niwa wrote: > >> I've updated the gist to reflect the discussion so far: > >> https://gist.github.com/rniwa/2f14588926e1a11c65d3 > >>

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

> On Apr 29, 2015, at 4:16 PM, Dimitri Glazkov wrote: > > On Tue, Apr 28, 2015 at 1:52 PM, Ryosuke Niwa wrote: >> I've updated the gist to reflect the discussion so far: >> https://gist.github.com/rniwa/2f14588926e1a11c65d3 >> >> Please leave a comment if I missed anything. > > Thank you for

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

Here's one case of redistribution: https://github.com/Polymer/core-scaffold/blob/master/core-scaffold.html#L122 Any time you see inside a custom element it's potentially redistribution. Here there's on that is (line 122), and one that could be (line 116), and one that definitely isn't (line 106).

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

On Wed, Apr 29, 2015 at 4:47 PM, Ryosuke Niwa wrote: >> On Apr 29, 2015, at 4:37 PM, Tab Atkins Jr. wrote: >> On Wed, Apr 29, 2015 at 4:15 PM, Dimitri Glazkov wrote: >>> On Mon, Apr 27, 2015 at 8:48 PM, Ryosuke Niwa wrote: One thing that worries me about the `distribute` callback approach

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

> On Apr 29, 2015, at 4:37 PM, Tab Atkins Jr. wrote: > > On Wed, Apr 29, 2015 at 4:15 PM, Dimitri Glazkov wrote: >> On Mon, Apr 27, 2015 at 8:48 PM, Ryosuke Niwa wrote: >>> One thing that worries me about the `distribute` callback approach (a.k.a. >>> Anne's approach) is that it bakes distribu

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

> On Apr 29, 2015, at 4:15 PM, Dimitri Glazkov wrote: > > On Mon, Apr 27, 2015 at 8:48 PM, Ryosuke Niwa wrote: >> One thing that worries me about the `distribute` callback approach (a.k.a. >> Anne's approach) is that it bakes distribution algorithm into the platform >> without us having thoro

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

On Wed, Apr 29, 2015 at 4:15 PM, Dimitri Glazkov wrote: > On Mon, Apr 27, 2015 at 8:48 PM, Ryosuke Niwa wrote: >> One thing that worries me about the `distribute` callback approach (a.k.a. >> Anne's approach) is that it bakes distribution algorithm into the platform >> without us having thoroughl

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

On Tue, Apr 28, 2015 at 1:52 PM, Ryosuke Niwa wrote: > I've updated the gist to reflect the discussion so far: > https://gist.github.com/rniwa/2f14588926e1a11c65d3 > > Please leave a comment if I missed anything. > Thank you for doing this. There are a couple of unescaped tags in https://gist.gi

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

On Mon, Apr 27, 2015 at 8:48 PM, Ryosuke Niwa wrote: > One thing that worries me about the `distribute` callback approach (a.k.a. > Anne's approach) is that it bakes distribution algorithm into the platform > without us having thoroughly studied how subclassing will be done upfront. > > Mozilla t

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

On Tue, Apr 28, 2015 at 4:32 PM, Ryosuke Niwa wrote: > On Apr 27, 2015, at 4:23 PM, Tab Atkins Jr. wrote: > > On Mon, Apr 27, 2015 at 4:06 PM, Tab Atkins Jr. > wrote: > > On Mon, Apr 27, 2015 at 3:42 PM, Ryosuke Niwa wrote: > > On Apr 27, 2015, at 3:15 PM, Steve Orvell wrote: > IMO, the appea

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

On Apr 27, 2015, at 4:23 PM, Tab Atkins Jr. wrote: > On Mon, Apr 27, 2015 at 4:06 PM, Tab Atkins Jr. wrote: >> On Mon, Apr 27, 2015 at 3:42 PM, Ryosuke Niwa wrote: On Apr 27, 2015, at 3:15 PM, Steve Orvell wrote: IMO, the appeal of this proposal is that it's a small change to the >>>

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

I've updated the gist to reflect the discussion so far: https://gist.github.com/rniwa/2f14588926e1a11c65d3 Please leave a comment if I missed anything. - R. Niwa

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

> On Apr 28, 2015, at 1:04 PM, Elliott Sprehn wrote: > > A distribute callback means running script any time we update distribution, > which is inside the style update phase (or event path computation phase, ...) > which is not a location we can run script. That's not what Anne and the rest o

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

A distribute callback means running script any time we update distribution, which is inside the style update phase (or event path computation phase, ...) which is not a location we can run script. We could run script in another scripting context like is being considered for custom layout and paint

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

For the record, I, as a spec editor, still think "Shadow Root hosts yet another Shadow Root" is the best idea among all ideas I've ever seen, with a " as function", because it can explain everything in a unified way using a single tree of trees, without bringing yet another complexity such as multi

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

> On Apr 27, 2015, at 12:25 AM, Justin Fagnani wrote: > > On Sun, Apr 26, 2015 at 11:05 PM, Anne van Kesteren wrote: >> On Sat, Apr 25, 2015 at 10:49 PM, Ryosuke Niwa wrote: >> > If we wanted to allow non-direct child descendent (e.g. grand child node) >> > of >> > the host to be distributed,

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

> On Apr 27, 2015, at 7:32 PM, Steve Orvell wrote: >> >> Perhaps we need to make childrenChanged optionally get called when >> attributes of child nodes are changed just like the way you can configure >> mutation observers to optionally monitor attribute changes. > > Wow, let me summarize if

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

> > Perhaps we need to make childrenChanged optionally get called when > attributes of child nodes are changed just like the way you can configure > mutation observers to optionally monitor attribute changes. Wow, let me summarize if I can. Let's say we have (a) a custom elements synchronous call

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

> On Apr 27, 2015, at 5:43 PM, Steve Orvell wrote: >> >> That might be an acceptable mode of operations. If you wanted to >> synchronously update your insertion points, rely on custom element's >> lifecycle callbacks and you can only support direct children for >> distribution. > > That's i

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

> > That might be an acceptable mode of operations. If you wanted to > synchronously update your insertion points, rely on custom element's > lifecycle callbacks and you can only support direct children for > distribution. That's interesting, thanks for working through it. Given a `childrenChange

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

> On Apr 27, 2015, at 4:41 PM, Steve Orvell wrote: > >> Again, the timing was deferred in [1] and [2] so it really depends on when >> each component decides to distribute. > > I want to be able to create an element that acts like other dom > elements. This element uses Shadow DOM and distrib

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

> > Again, the timing was deferred in [1] and [2] so it really depends on when > each component decides to distribute. I want to be able to create an element that acts like other dom elements. This element uses Shadow DOM and distribution to encapsulate its details. Let's imagine a 3rd party us

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

On Mon, Apr 27, 2015 at 4:06 PM, Tab Atkins Jr. wrote: > On Mon, Apr 27, 2015 at 3:42 PM, Ryosuke Niwa wrote: >>> On Apr 27, 2015, at 3:15 PM, Steve Orvell wrote: >>> IMO, the appeal of this proposal is that it's a small change to the current >>> spec and avoids changing user expectations about

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

On Mon, Apr 27, 2015 at 3:42 PM, Ryosuke Niwa wrote: >> On Apr 27, 2015, at 3:15 PM, Steve Orvell wrote: >> IMO, the appeal of this proposal is that it's a small change to the current >> spec and avoids changing user expectations about the state of the dom and >> can explain the two declarative

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

> On Apr 27, 2015, at 3:31 PM, Hayato Ito wrote: > > I think there are a lot of user operations where distribution must be updated > before returning the meaningful result synchronously. > Unless distribution result is correctly updated, users would take the dirty > result. Indeed. > For exa

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

> On Apr 27, 2015, at 3:15 PM, Steve Orvell wrote: > > IMO, the appeal of this proposal is that it's a small change to the current > spec and avoids changing user expectations about the state of the dom and can > explain the two declarative proposals for distribution. > >> It seems like with

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

I think there are a lot of user operations where distribution must be updated before returning the meaningful result synchronously. Unless distribution result is correctly updated, users would take the dirty result. For example: - element.offsetWidth: Style resolution requires distribution. We mu

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

Could you clarify what you are trying to achieve? If we don't support, everything would be weird. I guess you are proposing the alternative of the current pool population algorithm and pool distribution algorithm. I appreciate you could explain what are expected result using algorithms. On Tue,

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

IMO, the appeal of this proposal is that it's a small change to the current spec and avoids changing user expectations about the state of the dom and can explain the two declarative proposals for distribution. > It seems like with this API, we’d have to make O(n^k) calls where n is the > number o

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

> On Apr 27, 2015, at 2:38 PM, Hayato Ito wrote: > > On Tue, Apr 28, 2015 at 6:18 AM Ryosuke Niwa > wrote: > > > On Apr 26, 2015, at 6:11 PM, Hayato Ito > > wrote: > > > > I think Polymer folks will answer the use case of re-distribution. >

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

> On Apr 27, 2015, at 1:45 PM, Ryosuke Niwa wrote: > > >> On Apr 27, 2015, at 11:47 AM, Steve Orvell > > wrote: >> >> Here's a minimal and hopefully simple proposal that we can flesh out if this >> seems like an interesting api direction: >> >> https://gist.github.

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

On Tue, Apr 28, 2015 at 6:18 AM Ryosuke Niwa wrote: > > > On Apr 26, 2015, at 6:11 PM, Hayato Ito wrote: > > > > I think Polymer folks will answer the use case of re-distribution. > > > > So let me just show a good analogy so that every one can understand > intuitively what re-distribution *mean

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

> On Apr 26, 2015, at 6:11 PM, Hayato Ito wrote: > > I think Polymer folks will answer the use case of re-distribution. > > So let me just show a good analogy so that every one can understand > intuitively what re-distribution *means*. > Let me use a pseudo language and define XComponent's con

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

> On Apr 26, 2015, at 11:05 PM, Anne van Kesteren wrote: > > On Sat, Apr 25, 2015 at 10:49 PM, Ryosuke Niwa wrote: >> 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 o

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

> On Apr 27, 2015, at 11:47 AM, Steve Orvell wrote: > > Here's a minimal and hopefully simple proposal that we can flesh out if this > seems like an interesting api direction: > > https://gist.github.com/sorvell/e201c25ec39480be66aa > It

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

Here's a minimal and hopefully simple proposal that we can flesh out if this seems like an interesting api direction: https://gist.github.com/sorvell/e201c25ec39480be66aa We keep the currently spec'd distribution algorithm/timing but remove `select` in favor of an explicit selection callback. The

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

On 04/27/2015 02:11 AM, Hayato Ito wrote: I think Polymer folks will answer the use case of re-distribution. I wasn't questioning the need for re-distribution. I was questioning the need to distribute grandchildren etc - and even more, I was wondering what kind of algorithm would be sane in t

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

On Mon, Apr 27, 2015 at 3:41 PM, Matthew Robb wrote: > I know this isn't the biggest deal but I think naming the function > distribute is highly suggestive, why not just expose this as > `childListChangedCallback` ? Because that doesn't match the actual semantics. The callback is invoked once dis

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

I know this isn't the biggest deal but I think naming the function distribute is highly suggestive, why not just expose this as `childListChangedCallback` ? - Matthew Robb On Mon, Apr 27, 2015 at 4:34 AM, Anne van Kesteren wrote: > On Mon, Apr 27, 2015 at 10:23 AM, Justin Fagnani > wrote: > >

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

On Mon, Apr 27, 2015 at 10:23 AM, Justin Fagnani wrote: > A separate hidden tree per class sounds very much like multiple generations > of shadow trees, and we just killed that... We "killed" it for v1, not indefinitely. As I already said, based on my post-meeting conversations it might not have

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

On Mon, Apr 27, 2015 at 1:01 AM, Anne van Kesteren wrote: > On Mon, Apr 27, 2015 at 9:25 AM, Justin Fagnani > wrote: > > I really don't think the platform needs to do anything to support > > subclassing since it can be done so easily at the library level now that > > multiple generations of shad

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

On Mon, Apr 27, 2015 at 9:25 AM, Justin Fagnani wrote: > I really don't think the platform needs to do anything to support > subclassing since it can be done so easily at the library level now that > multiple generations of shadow roots are gone. As long as a subclass and > base class can cooperat

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

On Sun, Apr 26, 2015 at 11:05 PM, Anne van Kesteren wrote: > On Sat, Apr 25, 2015 at 10:49 PM, Ryosuke Niwa wrote: > > 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 a

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

On Sat, Apr 25, 2015 at 10:49 PM, Ryosuke Niwa wrote: > 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

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

I think Polymer folks will answer the use case of re-distribution. So let me just show a good analogy so that every one can understand intuitively what re-distribution *means*. Let me use a pseudo language and define XComponent's constructor as follows: XComponents::XComponents(Title text, Icon i

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

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 imper

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

> 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 ab

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 a

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

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

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

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. >

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

at 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

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

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 >

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

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

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

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

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 Di

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

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 ite

Imperative API for Node Distribution in Shadow DOM (Revisited)

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 mont