> 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.
Indeed. > 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 later). 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
