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

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

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Fri, 19 Oct 2012 01:28:34 +0300
Message-ID: <50808292.4040906@helsinki.fi>
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 GMT

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