- From: Andrei Bucur <abucur@adobe.com>
- Date: Wed, 31 Jul 2013 14:07:49 +0100
- To: François REMY <francois.remy.dev@outlook.com>, "www-style@w3.org" <www-style@w3.org>
Hello Francois, Some answers inline. ________________________________________ From: François REMY [francois.remy.dev@outlook.com] Sent: Tuesday, July 30, 2013 2:24 PM To: www-style@w3.org Subject: [css-regions] Async events, events coalescing, magic stuffs This one is funny: Suppose I'm a layout manager which use regions. I want to know when the layout of my regions is updated because I want to post-process the result. My pattern would be: - mark my stuff as invalidated - stop listening to region events - queue a microtask for recomputation: --- get the current region layout properties I need --- do my stuff, which will possibly trigger one of more region relayout --- force the layout to happen by doing something fancy like asking for an offsetHeight --- at this point, everything is done, so... --- add new event listeners to the region events to cover next updates In the [css-regions] spec, it's being written that region events are async. Async in which way? Async as they are not dispatched during the task that triggered them. Basically, they are dispatched only after the rendering is stabilized/script execution ended, not during the layout that changed the regions. They are more or less just notifications. The question is: - Will the event listeners I added at the end of my process get possibly notified for the changes that did happen before they were set up? because if they do, I just created an infinite loop... if not, is there any way I can know for sure the event I get does not only cover stuff that happened before I started listening? timestamps maybe? No, a listener should be notified of the changes that occurred only after it started listening. Another question: - If I update the layout of my region 10 times, should I expect 10 events or may the events be coalesced to just one if they fire after the 10 relayouts? I think the spec needs some clarifications in regard to this. I imagine the right answer is to send only one event because the events don't carry additional information about the state of the regions when the change occurred. Being told N times something has changed doesn't look too friendly or useful to me. HTH, Andrei.
Received on Wednesday, 31 July 2013 13:08:18 UTC