> On Apr 27, 2015, at 3:31 PM, Hayato Ito <hay...@chromium.org> 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:
> - element.offsetWidth:  Style resolution requires distribution. We must 
> update distribution, if it's dirty, before calculation offsetWidth 
> synchronously.
> - event dispatching: event path requires distribution because it needs a 
> composed tree.
> Can the current HTML/DOM specs are rich enough to explain the timing when the 
> imperative APIs should be run in these cases?

It certainly doesn't tell us when style resolution happens. In the case of 
event dispatching, it's impossible even in theory unless we somehow disallow 
event dispatching within our `distribute` callbacks since we can dispatch new 
events within the callbacks to decide to where a given node gets distributed. 
Given that, I don't think we should even try to make such a guarantee.

We could, however, make a slightly weaker guarantee that some level of 
conditions for the user code outside of `distribute` callbacks. For example, I 
can think of three levels (weakest to strongest) of self-consistent invariants:
1. every node is distributed to at most one insertion point.
2. all first-order distributions is up-to-date (redistribution may happen 
3. all distributions is up-to-date.

> For me, the imperative APIs for distribution sounds very similar to the 
> imperative APIs for style resolution. The difficulties of both problems might 
> be similar.

We certainly don't want to (in fact, we'll object to) spec the timing for style 
resolution or what even style resolution means.

- R. Niwa

Reply via email to