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: Andrei Bucur <abucur@adobe.com>
Date: Thu, 15 Nov 2012 19:24:55 +0000
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: Alan Stearns <stearns@adobe.com>, www-style list <www-style@w3.org>
Message-ID: <6E8E2AB3820BBC418FE7F934E849C9D018B888D700@eurmbx01.eur.adobe.com>
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 Thursday, 15 November 2012 19:25:37 UTC

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