- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Fri, 19 Oct 2012 01:28:34 +0300
- To: Alan Stearns <stearns@adobe.com>
- CC: Rafael Weinstein <rafaelw@google.com>, Webapps WG <public-webapps@w3.org>, Jonas Sicking <jonas@sicking.cc>, Ian Hickson <ian@hixie.ch>, Ryosuke Niwa <rniwa@webkit.org>, Ojan Vafai <ojan@chromium.org>, "robert@ocallahan.org" <robert@ocallahan.org>
On 10/19/2012 01:19 AM, Alan Stearns wrote: > On 10/18/12 2:51 PM, "Olli Pettay" <Olli.Pettay@helsinki.fi> wrote: > >> On 10/19/2012 12:08 AM, Rafael Weinstein wrote: >>> CSS Regions regionLayoutUpdate brings up an issue I think we need to >>> get ahead of: >>> >>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16391 >>> >>> For context: >>> -------- >>> Mutation Observers are currently spec'd in DOM4 >>> >>> http://dom.spec.whatwg.org/#mutation-observers >>> >>> and delivery timing is defined in HTML >>> >>> >>> http://www.whatwg.org/specs/web-apps/current-work/#perform-a-microtask-ch >>> eckpoint >>> >>> The timing here is described as a "microtask checkpoint" and is >>> conceptually "deliver all pending mutation records immediately after >>> any script invocation exits". >>> >>> TC-39 has recently approved Object.observe >>> >>> http://wiki.ecmascript.org/doku.php?id=harmony:observe >> >> (Not sure how that will work with native objects.) >> >> >>> >>> for inclusion in ECMAScript. It is conceptually modeled on Mutation >>> Observers, and delivers all pending change records immediately >>> *before* the last script stack frame exits. >>> >>> Additionally, although I've seen various discussion of dispatching DOM >>> Events with the microtask timing, CSS regionLayoutUpdate is the first >>> I'm aware of to attempt it >>> >>> http://dev.w3.org/csswg/css3-regions/#region-flow-layout-events >> >> >> Could you explain why microtasks are good for this case? >> I would have expected something bound to animation frame callback >> handling, >> or perhaps just tasks (but before next layout flush or something). > > In the spec bug discussion, it was suggested that we use end-of-task or > end-of-microtask timing. When I looked at these options, it seemed to me > that the regionLayoutUpdate event was somewhat close in intent to > MutationObservers. So between those two options, I picked microtask. If > there's a better place to trigger the event, I'm happy to make a change to > the spec. > > The current wording may be wrong for separate reasons anyway. The event is > looking for layout changes. For instance, if the geometry of a region in > the region chain is modified, and this causes either (a) overflow in the > last region in the chain or (b) the last region in the chain to become > empty, then we want the event to trigger so that a script can add or > remove regions in the chain to make the content fit correctly. If a task > in the event queue caused the change, then the microtask point after that > task is probably too soon to evaluate whether the event needs to fire. And > if that was the last task in the queue, then there may not be another > microtask happening after layout has occurred. > > So what I need is an appropriate timing step for responding to layout > changes. Any suggestions? Is there something wrong with animation frame callbacks or similar? (I'm not a layout hacker ;) ) > >> >>> >>> [I think this is wrong, and I'm hoping this email can help nail down >>> what will work better]. >>> >>> ------- >>> >>> Strawman: >>> >>> I'd like to propose a mental model for how these types of work get >>> scheduled. Note that my guiding principles are consistent with the >>> original design of the the end-of-(micro)task timing: >>> >>> -Observers should be delivered to async, but "soon" >>> >>> -Best efforts should be made to prevent future events from running in >>> a world where pending observer work has not yet been completed. >>> >>> >>> Delivery cycles: >>> >>> 1) Script (Object.observe) delivery. This is conceptually identical to >>> Mutation Observers. >>> >>> >>> http://wiki.ecmascript.org/doku.php?id=harmony:observe#deliverallchangere >>> cords >>> >>> 2) DOM (Mutation Observers) delivery. >>> >>> http://dom.spec.whatwg.org/#mutation-observers >>> >>> 3) End-of-task queue. >>> >>> This would be a new construct. Conceptually it would be a task queue >>> like other task queues, except that its purpose is to schedule >>> end-of-task work. Running it causes events to be dispatched in order >>> until the queue is empty. >>> >>> >>> Scheduling: >>> >>> A) Immediately before any script invocation returns to the browser >>> (after the last stack frame exits), run (1). This can be purely a >>> concern of the script engine and spec'd independent of HTML & DOM4. >>> >>> B) Immediately after any script invocation returns to the browser >>> (microtask checkpoint), run (2). Note that delivering to each observer >>> creates a new script invocation, at the end of which, (1) will run >>> again because of (A). >>> >>> C) Immediately before the UA completes the current task, run (2). This >>> is necessary incase DOM changes have occurred outside of a script >>> context (e.g. an input event triggered a change), and is already >>> implemented as part of DOM Mutation Observers. >>> >>> D) Run (3). Note that each script invocation terminates in running (1) >>> because of (A), then (2) because of (B). >>> >> > >
Received on Thursday, 18 October 2012 22:29:20 UTC