Bug 46041 – CSS inheritance delayed when transition duration on parent and child elements

• Component: Animations
• Status: NEW

[Sidney San Martín]

Created attachment 68015 [details]
Demo of font-size not being inherited until the transition is complete

When both a parent and a child element have -webkit-transition-durations for an inherited style property, and the property changes on the parent element, the property does not begin to change on the child element until the transition is complete on the parent. This only appears to happen in some cases

Try clicking the outer element in the demo a few times. When it adds and removes a class from the outer element that increases its font-size. When the class is added, the font-size of the inner element does not change until the transition is complete, but when it is removed, the transitions happen simultaneously. If you remove the -webkit-transition-duration from the inner element, the font-size transitions happen simultaneously in both directions.

[Rob Arnold]

Created attachment 133584 [details]
Test case

I also ran across this playing around with background-color

[Scott]

This is still an issue almost 5 years later. My main concern with this reported issue is that it is still not seen as a priority and yet there is no CSS workaround for many use cases.

[Radar WebKit Bug Importer]

<rdar://problem/21793947>

[shrpne]

Here is another showcase http://codepen.io/schonert/details/ovjhd/
And it is still not fixed for 6 years

[Alexandre Bonneau]

Perhaps this is related ; you can clearly see the faulty behavior on this live  example : https://codepen.io/AnotherLinuxUser/pen/ZJRNWP?editors=1100

Is there any way this gets more traction after 7 years?

[Alexandre Bonneau]

This is the workaround for the problem I posted earlier ; at comment #1 mentioned, you have to just through hoops in order to avoid having a transition on the parent and child at the same time.

The workaround : https://codepen.io/AnotherLinuxUser/pen/MvBEzN?editors=1100

The bug still needs fixing though ;)

[Ahmad Saleem]

I am able to reproduce this bug using WebKit ToT (266957@main) using following test case (from Comment 05): https://codepen.io/AnotherLinuxUser/pen/ZJRNWP?editors=1100

^ If you hover on 'XXX', it will take some time to reflect background update on 'There is a delay here'.

WebKit & Chrome Canary 118 both have this issue while Firefox Nightly 118 does not have this issue and reflect update immediately.

[Scott]

13 years. Think they going for some sort of bug existence record with this one.

[Antoine Quint]

The issue here is that WebKit and Chrome both trigger a _new_ transition for font-size on #inner on each animation frame as the #outer value changes. I will have to check the correct behavior here per spec.

[Antoine Quint]

Created attachment 469546 [details]
Testcase with logging

Attaching a new testcase which logs how transitions are started. It shows three different behaviors:

Firefox: single transitionstart event for both #outer and #inner going from 16px to 32px

Safari: single transitionstart event for #outer going from 16px to 32px and one transitionstart event for #inner per frame showing how we try to interpolate from the last interpolated value from the parent to the newly interpolated value until the parent's transition completes.

Chrome: single transitionstart event for #outer going from 0px to 0px and several, but fewer, transitionstart event for #inner from 0px to 0px. There's clearly a bug in Chrome with getKeyframes() in this instance.

[Antoine Quint]

I think the Firefox behavior is correct (on top of being rather clearly what the author would expect). Here's the relevant spec text, from https://drafts.csswg.org/css-transitions-1/#starting:

"Likewise, define the after-change style as the computed values of all properties on the element based on the information known at the start of that style change event, but using the computed values of the animation-* properties from the before-change style, excluding any styles from CSS Transitions in the computation, and inheriting from the after-change style of the parent."

When the "triggered" CSS class is applied and font-size changes to 2em on the #outer element, I interpret this spec text as having these effects:

1. for #outer this would mean the after-change style is 2em, which computes to 32px
2. for #inner, the after-change style will inherit from the #outer after-change style, and thus be 32px

As such both elements should transition together from 16px to 32px.

Chrome has recently resolved this issue, chromium bug: https://issues.chromium.org/issues/40337057

As of Today's Chrome Canary, I've verified this issue is indeed resolved.

There's a good chance that the chrome fixes could be directly imported, or at least have great inspiration on how to resolve it here as well.

[Antoine Quint]

We're now the last browser engine having this issue :( Cc'ing antti who might have ideas here.