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