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 <rn...@apple.com> wrote: > On Apr 30, 2015, at 8:17 PM, Hayato Ito <hay...@chromium.org> wrote: > > On Fri, May 1, 2015 at 2:59 AM Ryosuke Niwa <rn...@apple.com> wrote: > >> > >> > On Apr 30, 2015, at 6:00 AM, Domenic Denicola <d...@domenic.me> 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 cannot be interoperably > implemented is false? (Not that I am a huge fan of <content select>, but I > want to make sure we have our arguments against it lined up and on solid > footing.) > >> > > >> >> but it is problematic if you want to do an imperative API as I tried > to explain in the bit you did not quote back. > >> > > >> > Sure, let's dig in to that claim now. Again, this is mostly > clarifying probing. > >> > > >> > Let's say we had an imperative API. As far as I understand from the > gist, one of the problems is when do we invoke the distributedCallback. If > we use MutationObserve time, then inconsistent states can be observed, etc. > >> > > >> > Why can't we say that this distributedCallback must be invoked at the > same time that the current spec updates the distribution result? Since it > sounds like there is no interop problem with this timing, I don't > understand why this wouldn't be an option. > >> > >> There will be an interop problem. Consider a following example: > >> > > > > 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-evaluation of the distribution. > > The problem isn't so much that the current shadow DOM specification has an > interop issue because what we're talking here, as the thread title clearly > communicates, is the imperative API for node distribution, which doesn't > exist in the current specification. > > In particular, invoking user code at the timing specified in section 3.4 > which states "if any condition which affects the distribution result > changes, the distribution result must be updated before any use of the > distribution result" introduces a new interoperability issue because > "before any use of the distribution result" is implementation dependent. > e.g. element.offsetTop may or not may use the distribution result depending > on UA. Furthermore, it's undesirable to precisely spec this since doing so > will impose a serious limitation on what UAs could optimize in the future. > > - R. Niwa > >