- From: Rafael Weinstein <rafaelw@google.com>
- Date: Thu, 18 Oct 2012 15:08:09 -0700
- To: olli@pettay.fi
- Cc: Webapps WG <public-webapps@w3.org>, Jonas Sicking <jonas@sicking.cc>, Ian Hickson <ian@hixie.ch>, stearns@adobe.com, Ryosuke Niwa <rniwa@webkit.org>, Ojan Vafai <ojan@chromium.org>
On Thu, Oct 18, 2012 at 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-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 > > > (Not sure how that will work with native objects.) I assume you mean host objects (e.g. HTMLElement). The Object.observe doesn't say anything about host objects, so unless the wrapper property actually changes (e.g myElem.myExpando = 'newValue'), it won't be observable. The goal of this mechanism wasn't to observe changes to host 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). I can't. I don't know enough about CSS Regions. I'm bringing this up now because I've seen multiple instances of people *considering* microtask timing for Event dispatch, but this is the first time someone is trying it. > > > -Olli > > > > >> >> [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 22:08:37 UTC