Bugzilla – Bug 16391
regionLayoutUpdate needs to be async
Last modified: 2012-10-18 21:45:55 UTC
"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.
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.
(In reply to comment #0)
> "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?
We say that it's an async event, but we haven't specified when to fire it.
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.
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.
I defined the timing as "when MutationObservers are invoked"
I don't understand why microtasks are used for this.
Rafael started a webapps thread on the subject: