This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 16391 - regionLayoutUpdate needs to be async
Summary: regionLayoutUpdate needs to be async
Status: RESOLVED FIXED
Alias: None
Product: CSS
Classification: Unclassified
Component: Regions (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Alan Stearns
QA Contact: public-css-bugzilla
URL:
Whiteboard: cssom
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-15 20:43 UTC by Ryosuke Niwa
Modified: 2012-10-18 21:45 UTC (History)
10 users (show)

See Also:


Attachments

Description Ryosuke Niwa 2012-03-15 20:43:22 UTC
http://dev.w3.org/csswg/css3-regions/#region-flow-layout-events
"Region Event Targets dispatch regionLayoutUpdate events when there is a possible layout change of their named flow segment."

The spec needs to explicitly state the timing at which this event needs to be fired. Given that most implementations can't fire synchronous events during or immediately after the layout (since layout itself happens lazily when needed rather than when the value is changed), I suspect we need to use end-of-task or end-of-micro-task as the specific timing.
Comment 1 Alan Stearns 2012-03-15 21:02:38 UTC
Ryosuke also suggested to make the document the target for this event, with the named flow as an event property. This would remove any issues with deferring events that are meant to bubble up the DOM.
Comment 2 Vincent Hardy 2012-03-15 21:11:45 UTC
(In reply to comment #0)
> http://dev.w3.org/csswg/css3-regions/#region-flow-layout-events
> "Region Event Targets dispatch regionLayoutUpdate events when there is a
> possible layout change of their named flow segment."
> 
> The spec needs to explicitly state the timing at which this event needs to be
> fired. Given that most implementations can't fire synchronous events during or
> immediately after the layout (since layout itself happens lazily when needed
> rather than when the value is changed), I suspect we need to use end-of-task or
> end-of-micro-task as the specific timing.

I have a question:

The event description already says it is an Async. event. What other type of statement would you like to see in the specification prose?

Thanks,
-v
Comment 3 Alan Stearns 2012-04-14 21:27:37 UTC
We say that it's an async event, but we haven't specified when to fire it.
Comment 4 Ojan Vafai 2012-06-11 04:23:31 UTC
Rafael or Adam can probably expand on the advantages/disadvantages of firing this at end of microtask versus end of task. I think in many cases end of microtask might avoid flicker you would get with end of task, but I'm not sure.
Comment 5 Alan Stearns 2012-08-08 23:50:30 UTC
Another detail is whether to restrict the event trigger to more coarse layout changes. At the moment the spec says that the event triggers when there is a "possible layout change." Alex has expressed an interpretation of this as "something has changed either in parameters of regions or in content that made layout do non-zero work."

A more restrictive trigger could be something like "the regionOverset property has changed somewhere in the region chain." This would result in fewer events fired, but could miss some subtle changes that a script might want to respond to.

A use case for the less restrictive trigger is updating dictionary-style headers or footers that list the first and last word displayed on a page. There could be a layout change that affects this presentational data that does not meet the more restrictive trigger.
Comment 6 Alan Stearns 2012-10-04 23:25:05 UTC
I defined the timing as "when MutationObservers are invoked"

https://dvcs.w3.org/hg/csswg/rev/d5407e5d40c8
Comment 7 Olli Pettay 2012-10-18 21:24:14 UTC
I don't understand why microtasks are used for this.
Comment 8 Alan Stearns 2012-10-18 21:45:55 UTC
Rafael started a webapps thread on the subject:

http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0227.html