W3C home > Mailing lists > Public > www-style@w3.org > November 2012

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

From: Alan Stearns <stearns@adobe.com>
Date: Thu, 29 Nov 2012 16:03:34 -0800
To: Andrei Bucur <abucur@adobe.com>, "Tab Atkins Jr." <jackalmage@gmail.com>
CC: www-style list <www-style@w3.org>
Message-ID: <CCDD35CA.1A3FB%stearns@adobe.com>
I think it makes sense to have this event run at the same time "resize"
events run. But it should definitely occur *after* the resize event,
because changes from resize should happen before any regionlayoutupdate
code is invoked. In my limited understanding, I *think* this means that
the regionlayoutupdate event should be sync with respect to the resize
event (or with events in the same task queue as resize?). As Andrei
mentioned, the resize event itself isn't very well specified, so I'm not
sure what would go into the regionlayoutupdate definition to specify the



On 11/27/12 7:03 AM, "Andrei Bucur" <abucur@adobe.com> wrote:

>Just a kind reminder this issue still requires resolution. Tab, would you
>be able to give me some hints about what other events were discussed to be
>either synchronous or asynchronous. More information about the potential
>pitfalls that can show up if the event is marked as synchronous will also
>On 11/15/12 9:24 PM, "Andrei Bucur" <abucur@adobe.com> wrote:
>>Hi Tab,
>>I'm not extremely familiar with the concepts of task queues, sync/async
>>events or how the event loop is actually driven by an user agent. However
>>it makes sense a synchronous event  introduces dependencies that are
>>unwanted, have weird behaviors or are hard to implement. The sources of
>>information are also extremely hard to find on the topics I mentioned
>>earlier. I wasn't able to determine precisely in what task queue the
>>"resize" event should go (I assume it should be the UI events task queue)
>>or if it goes in any at all.
>>Do you have some references to point me at where I can digest better such
>>a proposal?
>>From: Tab Atkins Jr. [jackalmage@gmail.com]
>>Sent: Thursday, November 15, 2012 10:15 AM
>>To: Andrei Bucur
>>Cc: Alan Stearns; www-style list
>>Subject: Re: [css-regions] Fwd: Scheduling multiple types of
>>end-of-(micro)task work
>>On Thu, Nov 15, 2012 at 9:51 AM, Andrei Bucur <abucur@adobe.com> wrote:
>>> 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.
>>Synchronous events are, in general, the devil, and shouldn't be used
>>unless there's a *very* good reason they have to be, and a thorough
>>review has been done of the implications.
Received on Friday, 30 November 2012 00:05:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:24 UTC