Re: [css3-animations] display:none, visibility:hidden and animations

On 10/6/11 11:19 PM, Shane Stephens wrote:
>     The starting and stopping is the problem.
>
> Why? Is there a reason why it's hard to detect a style change which
> might result in an animation starting and stopping?

Yes.  That requires computing the set of matching rules for nodes in 
display:none subtrees.

> (1) on page load, every element is either display: none or not.
>   - for those elements which are not display: none, do what we currently do
>   - for those elements which are display: none, resolve just enough
> information to determine animation-name and transition-property values.

This last bit is _expensive_.

Seriously, I think you seriously underestimate what fraction of pageload 
selector matching can be.

Let me put numbers to this: for the HTML5 single-page spec with the 
various script bits disabled, around 25% of pageload is 
selector-matching in Gecko last I measured.  And it's not because we've 
avoided optimizing selector matching or anything....

> Note that this is relatively simple as these properties don't inherit

That's irrelevant; it still requires selector matching.

>   - A style change occurs that modifies animation-name or
> transition-property.

This requires checking for style changes on various DOM mutations in 
display:none subtrees, which is something else UAs can (and do at least 
in Gecko's case) completely optimize away right now.

> Nothing here is particularly expensive.

This is where you're wrong.  See above.

> There will be no overhead for elements without animations

Just figuring out whether an element has an animation at all involves 
significant overhead.

-Boris

Received on Friday, 7 October 2011 03:27:03 UTC