Stand alone reproduction at https://cumbersome-lumber.glitch.me . We do indeed keep doing style, layout, paint, and compositing when there is a CSS animation on a 0-height element.

We could attempt to short-circuit this, but not sure how.

Removing from erikchen's queue as they are no longer working on Chrome animations.

I've been thinking about this a little this afternoon, and I'm not clear how best we could stop doing so much work here.

Things we have to do (I think):

  1. Run the animation - we are required by the spec to do this, and we need to fire animation events and may be animating height anyway.
  2. Dirty style on the animation target - this feels unavoidable, as we could be animating height which would then make the element non-zero height and require layout/etc.

Interestingly even if I comment out the animations dirtying style on update, we still do layout, prepaint, paint, etc, they're just much shorter. So it seems like we are already committed to a full lifecycle update at this point.

In some ways to me this seems like a problem with Style rather than Animations; perhaps style being dirtied on 0-height elements shouldn't cause layout/etc?

I'm also not sure how common this would be; do web developers often have zero-height CSS elements that they would also want to be animating? This is definitely something we could measure if we thought it was valuable to fix.

+flackr@ to sanity check the above thinking - anything obvious I've missed Rob?

I'm assuming these are overflow: hidden 0-height elements?

Given overflow:hidden, I think descendants may still have rendering changes affected by the 0-height element (i.e. position: absolute|fixed boxes may still implicitly depend on the width / padding and certainly can inherit the inheritable css properties). Determining whether a visible change would occur and a repaint is required is ultimately up to the layout / paint phases.

Also, things like getComputedStyle still needs to return correct values.

I'm not even sure if layout can be avoided given that you can query layout properties and so even if the descendants are invisible, they may have been affected by the change.

I think you're right, the bug here would seem to be that layout/paint is unable to determine the change is not visible early to avoid a repaint.

That's a great point re overflow - if the overflow isn't hidden then descendants could be trivially visible (and could inherit style changes or be affected by padding/width). And as you said, even with overflow hidden, position:absolute/fixed would be visible and could inherit properties.

I'm renaming this bug and switching components to layout/paint teams. Folks from those teams, please take a thought as to whether it's feasible to realize earlier that nothing visible has changed in these circumstances and avoid a repaint. For a basic example see https://cumbersome-lumber.glitch.me, but there are complexities for things like descendents inheriting properties, descendents being affected by padding, etc.

Step 1 would be trying to find out how many 0-height, childless, non-animated etc elements there are in the wild. My guess is that hacks for fixed position and the like account for a non-trivial number. And then we want to know how much they change.

This seems like a situation where evaluating whether we could avoid work would be more expensive in the average case than just doing the work.

 Issue 782574  has been merged into this issue.