Bug 176858 – div with animated 'transform' should remain a containing block for positioned descendants, even if it's animating the value "transform:none"

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: Animations

[Daniel Holbert]

I'm using Safari 10.1.2.

STEPS TO REPRODUCE:
(1) Visit https://jsfiddle.net/kkpznn6L/

EXPECTED RESULTS:
No red should be visible.

ACTUAL RESULTS:
Red is visible. (The fixed-pos lime div abandons its red containing block and uses the viewport as its containing block instead.)


Notes:
The animation ends at "transform:none", which normally (if there weren't any animations) would mean that the red div should stop being a containing block for positioned children, which would mean that Safari's behavior here is correct [1].

However, that spec text doesn't matter because there's another effect that supercedes it, from the CSS Animations spec:
"While an animation [...] has an animation-fill-mode of 'forwards' or 'both', the user agent must act as if the will-change property ([css-will-change-1]) on the element additionally includes all the properties animated by the animation."
https://drafts.csswg.org/css-animations/#animations

So the rendering should be the same as what it'd be if "will-change:transform" were present.  For comparison, here is a reference case with that style manually added:
https://jsfiddle.net/kkpznn6L/1/

Safari renders *that one* correctly (no red). So, that means Safari is mis-rendering the original testcase (https://jsfiddle.net/kkpznn6L/ ) -- it's not honoring this bit of CSS Animations spec text.

Firefox 55 and Edge 15 each produce the expected result, BTW.
Chrome 62 dev and Safari 10.1.2 produce the incorrect/unexpected result.
Chrome bug: https://bugs.chromium.org/p/chromium/issues/detail?id=764783


[1] "...any value other than 'none' for the transform also causes the element to ... [act] as a containing block for fixed positioned descendants."
https://drafts.csswg.org/css-transforms/#transform-rendering

[Simon Fraser (smfr)]

Yeah, we haven't implemented that "will-change" piece fully yet.

[Radar WebKit Bug Importer]

<rdar://problem/34417985>

[Ahmad Saleem]

I am not able to reproduce this bug in Safari 16.2, Safari Technology Preview 161 and it is matching with Chrome Canary 111 and Firefox Nightly 111.

Marking this as "RESOLVED CONFIGURATION CHANGED". Thanks!