Re: Beginning of a spec on style batching/flushing?

On Wed, Dec 11, 2013 at 4:06 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 12/10/13 11:27 PM, Tab Atkins Jr. wrote:
>>    Each element in a document is associated with a <dfn export>style
>> updates queue</dfn>
>
>
> This explicitly orders the style updates, but...
>
>
>>    A <dfn>style update</dfn> is a pending currently-unapplied change
>> made to the style of an element on the page
>>    which might have an effect on the style, layout, or rendering of the
>> element.
>
>
> I'm not sure what that means.  Consider this testcase:
>
> <style>
>   .highlighted { color: purple; }
>   .also { background: green; }
> </style>
> <div>Some text</div>
> <script>
>   var div = document.querySelector("div");
>   div.offsetWidth; // Flush styles on div.... more on this below
>   div.className = "highlighted";
>   // What's in the style updates queue for the div now?
>   div.className = "also";
>   // And now?
>   div.className = "also highlighted";
>   // What about now?
> </script>

I suppose it would be [color:purple], then [color:purple,
background:green], then the same again.

The exact order of style updates is unimportant within a consecutive
run of style updates.  Maybe I can be more explicit about that.

> The other thing I'd like to understand is whether we can have a situation
> like so for style updates queues:
>
> Element A: Update 1, Action 2, Update 3
> Element B: Update 4, Action 5, Update 6
>
> where Update 3 and Update 4 were triggered by the same DOM mutation. Seems
> like this should be possible, right?  So in this situation we need to apply
> Update 1 (but not any of the other updates, so basically style the DOM as if
> the mutation that caused Update 3 has not happened yet?), then do Action 2,
> then do the rest of the stuff in any order as long as update 4 precedes
> action 5 which precedes update 6?
>
> Or am I totally misunderstanding the proposal?

Correct, as long as Update 3 doesn't have any effect on Element B
either.  I may be using inadequate terminology to describe the data
structure I'm imagining here; it's kinda a multi-tree where
independent branches are updates/actions that can be executed
independently, without each affecting the other's affected elements?

Note that the reason I'm defining this is because I'm speccing the
ability to take "snapshots" of an element.  The snapshotting is async
(so you don't have to immediately do a sync style flush, relayout, and
render), but it needs to respect ordering, so you can do:

el.style.foo = "bar";
CSS.elementSources.set('before', el.snapshot());
el.style.foo = "baz";
CSS.elementSources('after', el.snapshot());
el.animate('background-image', /* from before to after over 1s */);

(Ignore precise syntax/naming/etc - you get the idea.)

>>    User agents should prioritize applying <a>style updates</a>
>>    that precede a <a>style-dependent action</a>
>>    when a <a>style-dependent action</a> is in the queue.
>
> Prioritize over what?

As opposed to delaying them.  Recall that this follows immediately
after the bit saying that UAs can delay applying style updates as long
as they think appropriate. This is meant to capture the fact that when
you, say, read .offsetTop, UAs should immediately flush their styles
so they can return synchronously as quickly as possible.  Even when an
action is async, its presence should still cause a UA to be a bit
quicker about flushing updates than it might be if nothing was waiting
on the style but a normal screen-paint.

~TJ

Received on Wednesday, 11 December 2013 05:32:45 UTC