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

On 12/11/13 12:31 AM, Tab Atkins Jr. wrote:
> On Wed, Dec 11, 2013 at 4:06 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>> <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.

That doesn't seem good if something in the spec comes to actually depend 
on that behavior.

In particular, what browsers would like to defer (and do defer) in this 
situation is not the application of the style changes by the figuring 
out of which styles are changed.  And ideally (also implemented in at 
least WebKit and Gecko) which elements are even affected by the DOM change.

> Correct, as long as Update 3 doesn't have any effect on Element B
> either.

I'm not sure this concept of "style the tree as if the DOM looked like 
it did at point X" is something implementations are terribly interested 
in either, honestly....  It's a pretty significant complication, no?

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

Sure, I understand that (or rather, it can be optimized to that as needed).

What I'm not quite OK with is the explicit orderings required (playing 
with parallel style recomputation how, exactly?), the eager work 
required where browsers can be lazy right now, and the requirements on 
styling something other than the DOM.

> 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 */);

Hmm.

So this in fact requires significant sync work at the snapshot() call: 
you have to snapshot all DOM state that might be affected by the 
previous DOM changes.

I guess the inefficiency only pops up if you do snapshot(), so as long 
as you don't do those life is more or less OK for the UA.  And an 
implementatjon that in fact synchronously does the render on snapshot() 
(which sounds like it would not violate your constraints) might be 
preferable to having slower restyling (due to having to operate on some 
copy of the DOM because you can't trust the DOM to reflect things 
usefully anymore) in the common cases...

Might I ask what the use cases are for this snapshotting behavior as 
opposed to live things?  Seems like your use case above would be just 
fine with a live background-image reference to an element that animates 
over 1s.

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

OK.

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

I'm not sure I follow.  Is this a "should" level requirement that 
offsetTop performance shouldn't suck, or a "should" level requirement 
that it should not return incorrect data?  The latter needs to be a 
"must" and the former doesn't seem like something that can be required 
normatively, no?

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

Why, if the effect won't be visible until paint anyway?

-Boris

Received on Wednesday, 11 December 2013 14:36:18 UTC