W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2012

Re: Scheduling multiple types of end-of-(micro)task work

From: Rafael Weinstein <rafaelw@google.com>
Date: Thu, 18 Oct 2012 15:08:09 -0700
Message-ID: <CABMdHiSkGL34=3ASUYYM6W=Cpj96=cmzsZXw76p=VjTvz55OPA@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:55 GMT