- From: Rafael Weinstein <rafaelw@google.com>
- Date: Thu, 18 Oct 2012 14:08:28 -0700
- To: Webapps WG <public-webapps@w3.org>
- Cc: Olli@pettay.fi, Jonas Sicking <jonas@sicking.cc>, Ian Hickson <ian@hixie.ch>, stearns@adobe.com, Ryosuke Niwa <rniwa@webkit.org>, Ojan Vafai <ojan@chromium.org>
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-checkpoint 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 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 [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#deliverallchangerecords 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 21:08:55 UTC