[whatwg] Reliably Minimize Reflows
Joseph Pecoraro
joepeck02 at gmail.com
Sat Sep 26 13:11:05 PDT 2009
>> // Single reflow would be triggered at the end of batchUpdate
>> document.batchUpdate(function() {
>> ...
>> });
>
> As a UA developer, I'd not be all that happy implementing this,
> since you can stay inside the batchUpdate more or less forever (e.g.
> by putting up alerts or doing sync XHR).
>
> In any case, it seems unnecessary.
I was aware of the potential for a thread to sit inside a
batchUpdate. I guess the basic idea would have been that batchUpdate
would be a hint to the UA. However, I can't think of any other
situations where there are API functions that are "hints" so maybe
this isn't appropriate for a spec?
>> "Browsers may choose to wait until the end of a script thread before
>> reflowing to show the changes. Opera will wait until enough changes
>> have
>> been made, enough time has elapsed, or the end of the thread is
>> reached.
>> This means that if the changes happen quickly enough in the same
>> thread,
>> they may only produce one reflow. However, this cannot be relied on,
>> especially considering the various different speeds of devices that
>> Opera runs on."
>
> Note that Gecko will not perform layout while your script is
> running, unless you ask for layout information. If Opera has a
> different behavior, I assume they have a good reason for it, right?
> Why are you sure you want to override that reason?
I don't think of this as overriding any reasons/behaviors. I thought
that this would do more to justify those reasons/behaviors.
- Joe
More information about the whatwg
mailing list