W3C home > Mailing lists > Public > www-style@w3.org > February 2014

[css3-regions] Regions events timing

From: Andrei Bucur <abucur@adobe.com>
Date: Mon, 24 Feb 2014 12:38:18 +0000
To: www-style list <www-style@w3.org>
CC: Ryosuke Niwa <rniwa@apple.com>
Message-ID: <CF310AE1.11219%abucur@adobe.com>
Hello!

The CSS Regions spec basically states that an UA should dispatch an event
when something changes as a result of the fragmentation process [1]. This
brings up questions considering UAs are usually optimised and apply
changes to the pages as late as possible, lazily.

For example, letıs say a document runs a script:
1. That changes something in the content of a region that causes overset
to change.
2. Then reads a value depending on the layout (e.g. body.offsetTop)
actually forcing the browser to apply the change at 1.
3. Finally undoes the change at 1.

When executing 2 the UA detects there was a change and schedules an event
to be dispatched later on even though the change doesnıt apply any more
when the final layout is made (that actually renders on the screen), after
the script execution ends.

If the script runs only 1 and 3 and the UA is optimised to apply the
changes lazily, thereıs no middle layout taking place and the event is not
scheduled after the last step.

Does it make sense to specify the events are dispatched only for "visible"
changes inside the page, that actually have a chance to render? Maybe we
can hook up with task queues [2] and say the dispatch detection is made at
the end of the script task currently executing or that it is actually a
task by itself scheduled on the document queue?

Thoughts?
Andrei.

[1] http://dev.w3.org/csswg/css-regions/#named-flow-events
[2] http://dev.w3.org/html5/pf-summary/browsers.html#task-queue
Received on Monday, 24 February 2014 12:38:50 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:19 UTC