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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Rafael Weinstein-2
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).

Reply | Threaded
Open this post in threaded view
|

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

Olli Pettay
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.)


>
> 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).


-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).
>


Reply | Threaded
Open this post in threaded view
|

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

Rafael Weinstein-2
On Thu, Oct 18, 2012 at 2:51 PM, Olli Pettay <[hidden email]> 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).
>>
>

Reply | Threaded
Open this post in threaded view
|

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

Jonas Sicking-2
In reply to this post by Rafael Weinstein-2
On Thu, Oct 18, 2012 at 2:08 PM, Rafael Weinstein <[hidden email]> 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
>
> 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).

I think this is a good starting point. I don't have an opinion on the
issue that Olli brought up, but I would be surprised if there aren't
other callbacks that people want to do at the end of microtasks.

However, I suspect that we'll need to look at this in more detail once
we know what other things we want to do at end-of-task. While it's
clear to me that (1) should be run before (2). But it's not clear to
me that layout-scheduled callbacks (if there are any) should run after
MutationObserver callbacks.

And say that we add two different types of layout callbacks. It's not
clear that they should be mixed in a single queue as part of a (3)
step. We might want to run all callbacks of one of the types before we
run all the callbacks of another type, just like you are proposing to
run all MutationObserver callbacks before all layout callbacks.

A concrete example is that the FileAPI spec wants to automatically
revoke some URLs created using URL.createObjectURL at the end of a
microtask. Likely this should happen after (2), but it definitely
shouldn't happen as part of a generic queue in (3). Possibly it should
happen after (3) is done running. The nice thing about URL revokation
is that it doesn't run any callbacks, so it'll never cause (1)-(3) to
rerun.

I think the best way forward is to add some explicit hook in the HTML
spec which enables a spec to write language which would hook into this
mechanism. As we see what types of callbacks people want to run at the
end of a task we can figure out in which order they should run and if
they should share queue or not. And then we'll have to adjust the HTML
spec accordingly.

Ideally this stuff should of course live as a separate event-loop spec
and not part of HTML. That's true even without taking microtasks into
account. But since no editor has stepped with such a draft we'll have
to live with it living in HTML for now.

/ Jonas

Reply | Threaded
Open this post in threaded view
|

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

Alan Stearns
In reply to this post by Olli Pettay
On 10/18/12 2:51 PM, "Olli Pettay" <[hidden email]> 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?

>
>>
>> [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).
>>
>


Reply | Threaded
Open this post in threaded view
|

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

Olli Pettay
On 10/19/2012 01:19 AM, Alan Stearns wrote:

> On 10/18/12 2:51 PM, "Olli Pettay" <[hidden email]> 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).
>>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

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

James Robinson-5
In reply to this post by Alan Stearns


On Thu, Oct 18, 2012 at 3:19 PM, Alan Stearns <[hidden email]> wrote:
On 10/18/12 2:51 PM, "Olli Pettay" <[hidden email]> 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?

I think events based off of layout are a terrible idea and there is no good timing for them.  The regions case is a good example of why not to have them.  If you need javascript to respond to DOM changes then mutation observers are the primitive to use.  If you just want to get callbacks at a good time to update visual effects use requestAnimationFrame().

- James
 

>
>>
>> [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).
>>
>



Reply | Threaded
Open this post in threaded view
|

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

Jonas Sicking-2
On Thu, Oct 18, 2012 at 3:34 PM, James Robinson <[hidden email]> wrote:

> On Thu, Oct 18, 2012 at 3:19 PM, Alan Stearns <[hidden email]> wrote:
>> On 10/18/12 2:51 PM, "Olli Pettay" <[hidden email]> 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?
>
>
> I think events based off of layout are a terrible idea and there is no good
> timing for them.  The regions case is a good example of why not to have
> them.  If you need javascript to respond to DOM changes then mutation
> observers are the primitive to use.  If you just want to get callbacks at a
> good time to update visual effects use requestAnimationFrame().

Does that mean that you think events like onresize and onscroll are
bad? It's an honest question since I can definitely see your argument.

Though I do wonder if layout events can be useful in cases where you
don't want to be called every time the DOM changes (MutationObservers)
or on every time the screen is painted (requestAnimationFrame).

You could use those two, specifically the latter, to replace onscroll
and onresize. But it might end up using a lot more CPU power if you
have to check the current scroll position or screen size on every
painted frame. Likewise it might use a lot more CPU power if you have
to check layout primitives on every DOM mutation.

People have been asking for resize events for individual elements for
a very long time (I think it might even be implemented in some
non-Gecko browsers). This obviously wouldn't be needed if people used
MutationObservers and requestAnimationFrame, or MutationObservers and
page-wide onresize. However it might save a lot of CPU power and make
authoring a whole lot simpler if you could get called only when it was
actually needed.

I don't know enough about CSS regions to know if the same thing
applies there. But I would imagine there are layout changes where
this applies.

/ Jonas

Reply | Threaded
Open this post in threaded view
|

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

James Robinson-5


On Thu, Oct 18, 2012 at 4:16 PM, Jonas Sicking <[hidden email]> wrote:
On Thu, Oct 18, 2012 at 3:34 PM, James Robinson <[hidden email]> wrote:
> On Thu, Oct 18, 2012 at 3:19 PM, Alan Stearns <[hidden email]> wrote:
>> On 10/18/12 2:51 PM, "Olli Pettay" <[hidden email]> 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?
>
>
> I think events based off of layout are a terrible idea and there is no good
> timing for them.  The regions case is a good example of why not to have
> them.  If you need javascript to respond to DOM changes then mutation
> observers are the primitive to use.  If you just want to get callbacks at a
> good time to update visual effects use requestAnimationFrame().

Does that mean that you think events like onresize and onscroll are
bad? It's an honest question since I can definitely see your argument.

onresize when applied to the viewport isn't necessarily bad since it's talking about something that is input to layout (size of the window) not output.  Similarly when onscroll is used to detect interactions with the page and not changing in scroll position due to layout it's not necessarily evil.  However, both do suffer from the same issues and we've had to apply various levels of "hacks" to both.

For onscroll, after receiving many bugs we've effectively delayed firing the scroll event later and later to make sure the callstack is clean and to try to prevent it from interfering "too much" with the user's interactions.  In practice, scroll events fire after the user sees the scroll position update in Chrome in nearly all cases.  For onresize, we've definitely seen many bugs where people construct infinite loops.  I'm not sure what the current state of events is with onresize (except that it is inconsistent between browsers) but if it's firing synchronously or relatively quickly I'm sure it will be pushed out to fire later and less frequently for the same reasons as onscroll.


Though I do wonder if layout events can be useful in cases where you
don't want to be called every time the DOM changes (MutationObservers)
or on every time the screen is painted (requestAnimationFrame).

You could use those two, specifically the latter, to replace onscroll
and onresize. But it might end up using a lot more CPU power if you
have to check the current scroll position or screen size on every
painted frame. Likewise it might use a lot more CPU power if you have
to check layout primitives on every DOM mutation.

Indeed. I think the key distinction here is whether the page is trying to listen to changes that are input to layout (the viewport dimensions changing, the user providing input leading to scrolling) from changes that are output of layout.  If a page could reliably listen to the former and then use requestAnimationFrame to schedule work they could only tick when they really need to while still reacting.

One complication here is that things that the browser considers internal to the page like an iframe or div changing size may very well be considered "external" to the author of a component embedded in a page.  This case is harder to deal with, but I still feel that the goal should be a directed flow from things that are inputs to layouts to things that are outputs.

- James
 

People have been asking for resize events for individual elements for
a very long time (I think it might even be implemented in some
non-Gecko browsers). This obviously wouldn't be needed if people used
MutationObservers and requestAnimationFrame, or MutationObservers and
page-wide onresize. However it might save a lot of CPU power and make
authoring a whole lot simpler if you could get called only when it was
actually needed.

I don't know enough about CSS regions to know if the same thing
applies there. But I would imagine there are layout changes where
this applies.

/ Jonas

Reply | Threaded
Open this post in threaded view
|

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

Andrei Bucur-2
Hello,

I agree using micro-tasks for the "regionLayoutUpdate" event is not a very good option and we should respecify the event behaviour.

One idea that comes in my mind is to specialize the "regionLayoutEvent" into something more measurable (basically, having a better answer to what are the conditions that trigger the event). My suggestion is to use the region flow ranges: the event is scheduled (I'll come back to this later) when the flow ranges in any region in the chain change. Conceptually this is similar to mutation observers - e.g. when the content of a DOM node changes, a callback can be invoked. The same way, when the fragment of content flowing into a region has changed, the "regionLayoutUpdate" event is dispatched (I quoted it because I'm not sure this name would fit it any more).

Trying to include this proposal in one of the categories James nicely defined, it unfortunately remains a layout output event. The "scheduling" issue is still here, but I think specializing the trigger condition this way allows us to simplify the wording to something like "the event is dispatched after all the effects of the range changes in the region chain have been applied" (see [1]), thus masking the fact a layout was made. However, with this wording I wonder why the event can't be made synchronous. It would become more like the "resize" event and allow real-time operations over the named flows/regions. The "regionLayoutUpdate" would also chain nicely with the "resize" event - the user resizes the window, a layout is triggered, the ranges change, regionLayoutUpdate is dispatched, other changes apply (tricky one), the resize event is dispatched.

Thoughts?

Thanks,
Andrei.

[1] http://www.w3.org/TR/DOM-Level-3-Events/#event-type-resize

On Oct 19, 2012, at 2:41 AM, James Robinson <[hidden email]> wrote:

>
>
> On Thu, Oct 18, 2012 at 4:16 PM, Jonas Sicking <[hidden email]> wrote:
> On Thu, Oct 18, 2012 at 3:34 PM, James Robinson <[hidden email]> wrote:
> > On Thu, Oct 18, 2012 at 3:19 PM, Alan Stearns <[hidden email]> wrote:
> >> On 10/18/12 2:51 PM, "Olli Pettay" <[hidden email]> 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?
> >
> >
> > I think events based off of layout are a terrible idea and there is no good
> > timing for them.  The regions case is a good example of why not to have
> > them.  If you need javascript to respond to DOM changes then mutation
> > observers are the primitive to use.  If you just want to get callbacks at a
> > good time to update visual effects use requestAnimationFrame().
>
> Does that mean that you think events like onresize and onscroll are
> bad? It's an honest question since I can definitely see your argument.
>
> onresize when applied to the viewport isn't necessarily bad since it's talking about something that is input to layout (size of the window) not output.  Similarly when onscroll is used to detect interactions with the page and not changing in scroll position due to layout it's not necessarily evil.  However, both do suffer from the same issues and we've had to apply various levels of "hacks" to both.
>
> For onscroll, after receiving many bugs we've effectively delayed firing the scroll event later and later to make sure the callstack is clean and to try to prevent it from interfering "too much" with the user's interactions.  In practice, scroll events fire after the user sees the scroll position update in Chrome in nearly all cases.  For onresize, we've definitely seen many bugs where people construct infinite loops.  I'm not sure what the current state of events is with onresize (except that it is inconsistent between browsers) but if it's firing synchronously or relatively quickly I'm sure it will be pushed out to fire later and less frequently for the same reasons as onscroll.
>
>
> Though I do wonder if layout events can be useful in cases where you
> don't want to be called every time the DOM changes (MutationObservers)
> or on every time the screen is painted (requestAnimationFrame).
>
> You could use those two, specifically the latter, to replace onscroll
> and onresize. But it might end up using a lot more CPU power if you
> have to check the current scroll position or screen size on every
> painted frame. Likewise it might use a lot more CPU power if you have
> to check layout primitives on every DOM mutation.
>
> Indeed. I think the key distinction here is whether the page is trying to listen to changes that are input to layout (the viewport dimensions changing, the user providing input leading to scrolling) from changes that are output of layout.  If a page could reliably listen to the former and then use requestAnimationFrame to schedule work they could only tick when they really need to while still reacting.
>
> One complication here is that things that the browser considers internal to the page like an iframe or div changing size may very well be considered "external" to the author of a component embedded in a page.  This case is harder to deal with, but I still feel that the goal should be a directed flow from things that are inputs to layouts to things that are outputs.
>
> - James
>  
>
> People have been asking for resize events for individual elements for
> a very long time (I think it might even be implemented in some
> non-Gecko browsers). This obviously wouldn't be needed if people used
> MutationObservers and requestAnimationFrame, or MutationObservers and
> page-wide onresize. However it might save a lot of CPU power and make
> authoring a whole lot simpler if you could get called only when it was
> actually needed.
>
> I don't know enough about CSS regions to know if the same thing
> applies there. But I would imagine there are layout changes where
> this applies.
>
> / Jonas
>


Reply | Threaded
Open this post in threaded view
|

[css-regions] Fwd: Scheduling multiple types of end-of-(micro)task work

Andrei Bucur-2
Hello,

CCing www-style and BCCing public-webapps

I have given some thoughts to the regionlayoutupdate event - what condition triggers it and when it should be dispatched.
For the current version of the spec I think it is sufficient to consider the event is triggered only by changes of the overset value of the NamedFlow (so it could be renamed to flowoversetchanged). This covers most of the use-cases I can think of. In my opinion, having something more generic brings a lot of complexity without much value. We could discuss more about how regionlayoutupdate can be extended when there will be strong use cases that need a more powerful event (e.g. to detect subtle layout changes).
The timing of the event is a bit tricky to get right. The overset value of the NamedFlow object is a result of the layout (see the discussion in the original thread). As a consequence there aren't many options to pick from. I'm imagining something like this:
1. The event needs to be synchronous to allow scripts to update the layout in a responsive manner by interleaving with other events that cause a layout change.
2. I think the event must be dispatched on the same task queue of the "resize" event. The reason is to allow smooth updates of the layout when the user resizes the browser window.

Thoughts?

Thanks,
Andrei.

Begin forwarded message:

> From: Andrei Bucur <[hidden email]>
> Subject: Re: Scheduling multiple types of end-of-(micro)task work
> Date: October 19, 2012 5:53:27 PM GMT+03:00
> To: Webapps WG <[hidden email]>
> Cc: Jonas Sicking <[hidden email]>, Alan Stearns <[hidden email]>, "[hidden email]" <[hidden email]>, Rafael Weinstein <[hidden email]>, Ian Hickson <[hidden email]>, Ryosuke Niwa <[hidden email]>, Ojan Vafai <[hidden email]>, James Robinson <[hidden email]>
>
> Hello,
>
> I agree using micro-tasks for the "regionLayoutUpdate" event is not a very good option and we should respecify the event behaviour.
>
> One idea that comes in my mind is to specialize the "regionLayoutEvent" into something more measurable (basically, having a better answer to what are the conditions that trigger the event). My suggestion is to use the region flow ranges: the event is scheduled (I'll come back to this later) when the flow ranges in any region in the chain change. Conceptually this is similar to mutation observers - e.g. when the content of a DOM node changes, a callback can be invoked. The same way, when the fragment of content flowing into a region has changed, the "regionLayoutUpdate" event is dispatched (I quoted it because I'm not sure this name would fit it any more).
>
> Trying to include this proposal in one of the categories James nicely defined, it unfortunately remains a layout output event. The "scheduling" issue is still here, but I think specializing the trigger condition this way allows us to simplify the wording to something like "the event is dispatched after all the effects of the range changes in the region chain have been applied" (see [1]), thus masking the fact a layout was made. However, with this wording I wonder why the event can't be made synchronous. It would become more like the "resize" event and allow real-time operations over the named flows/regions. The "regionLayoutUpdate" would also chain nicely with the "resize" event - the user resizes the window, a layout is triggered, the ranges change, regionLayoutUpdate is dispatched, other changes apply (tricky one), the resize event is dispatched.
>
> Thoughts?
>
> Thanks,
> Andrei.
>
> [1] http://www.w3.org/TR/DOM-Level-3-Events/#event-type-resize
>
> On Oct 19, 2012, at 2:41 AM, James Robinson <[hidden email]> wrote:
>
>>
>>
>> On Thu, Oct 18, 2012 at 4:16 PM, Jonas Sicking <[hidden email]> wrote:
>> On Thu, Oct 18, 2012 at 3:34 PM, James Robinson <[hidden email]> wrote:
>>> On Thu, Oct 18, 2012 at 3:19 PM, Alan Stearns <[hidden email]> wrote:
>>>> On 10/18/12 2:51 PM, "Olli Pettay" <[hidden email]> 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?
>>>
>>>
>>> I think events based off of layout are a terrible idea and there is no good
>>> timing for them.  The regions case is a good example of why not to have
>>> them.  If you need javascript to respond to DOM changes then mutation
>>> observers are the primitive to use.  If you just want to get callbacks at a
>>> good time to update visual effects use requestAnimationFrame().
>>
>> Does that mean that you think events like onresize and onscroll are
>> bad? It's an honest question since I can definitely see your argument.
>>
>> onresize when applied to the viewport isn't necessarily bad since it's talking about something that is input to layout (size of the window) not output.  Similarly when onscroll is used to detect interactions with the page and not changing in scroll position due to layout it's not necessarily evil.  However, both do suffer from the same issues and we've had to apply various levels of "hacks" to both.
>>
>> For onscroll, after receiving many bugs we've effectively delayed firing the scroll event later and later to make sure the callstack is clean and to try to prevent it from interfering "too much" with the user's interactions.  In practice, scroll events fire after the user sees the scroll position update in Chrome in nearly all cases.  For onresize, we've definitely seen many bugs where people construct infinite loops.  I'm not sure what the current state of events is with onresize (except that it is inconsistent between browsers) but if it's firing synchronously or relatively quickly I'm sure it will be pushed out to fire later and less frequently for the same reasons as onscroll.
>>
>>
>> Though I do wonder if layout events can be useful in cases where you
>> don't want to be called every time the DOM changes (MutationObservers)
>> or on every time the screen is painted (requestAnimationFrame).
>>
>> You could use those two, specifically the latter, to replace onscroll
>> and onresize. But it might end up using a lot more CPU power if you
>> have to check the current scroll position or screen size on every
>> painted frame. Likewise it might use a lot more CPU power if you have
>> to check layout primitives on every DOM mutation.
>>
>> Indeed. I think the key distinction here is whether the page is trying to listen to changes that are input to layout (the viewport dimensions changing, the user providing input leading to scrolling) from changes that are output of layout.  If a page could reliably listen to the former and then use requestAnimationFrame to schedule work they could only tick when they really need to while still reacting.
>>
>> One complication here is that things that the browser considers internal to the page like an iframe or div changing size may very well be considered "external" to the author of a component embedded in a page.  This case is harder to deal with, but I still feel that the goal should be a directed flow from things that are inputs to layouts to things that are outputs.
>>
>> - James
>>
>>
>> People have been asking for resize events for individual elements for
>> a very long time (I think it might even be implemented in some
>> non-Gecko browsers). This obviously wouldn't be needed if people used
>> MutationObservers and requestAnimationFrame, or MutationObservers and
>> page-wide onresize. However it might save a lot of CPU power and make
>> authoring a whole lot simpler if you could get called only when it was
>> actually needed.
>>
>> I don't know enough about CSS regions to know if the same thing
>> applies there. But I would imagine there are layout changes where
>> this applies.
>>
>> / Jonas
>>
>
>