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

Hello,

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

Thanks,
Andrei.

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?
>
>Thanks,
>Andrei.
>________________________________________
>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.
>
>~TJ
>

Received on Tuesday, 27 November 2012 15:03:53 UTC