[whatwg] Reliably Minimize Reflows

[Joseph Pecoraro]

>> // 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