1858786 - No transitions of inherited properties when the change is triggered by animations

Status: NEW

(Core :: CSS Transitions and Animations, defect)

Description

[Roman Komarov]

Attachment: inherited-transitions.html

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/118.0

Steps to reproduce:

1. Go to https://codepen.io/kizu/pen/wvRZzGB or the attached .html
2. Look at the animation and transition

or

1. Create a “discrete” animation on an element.
2. Have a child element that inherits the values of the properties changed by this animation.
3. Add a transition for these properties.

Actual results:

There is no transition on the inherited properties, they change immediately.

Expected results:

The values of the inherited properties should happen with a transition. Both Chrome and Safari handle this case as expected.

There is an additional case (third one) with transitions, where Chrome and Safari stagger when there are inherited values that change with a transition and result in a transition, while Firefox handles them immediately, as if the nested element did not have a transition. I expect these cases might be connected, but maybe not?

The place in the specs that describes the transitions case is this I think: https://www.w3.org/TR/css-transitions-1/#ref-for-after-change-style%E2%91%A1 (and surrounding context as well). I admit that I did not understand completely this place in the specs, I'll probably need another read and more thinking.

But, from an author perspective, the behavior in both Chrome and Safari is more useful, and is something that I did expect to work. If the specs reading by Mozilla team would differ from what Chrome and Safari do, this would need to be brought up to CSSWG, to decide how we'd want to handle interop here, change/clarify the specs, and what to do in the end.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::CSS Transitions and Animations' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Daniel Holbert [:dholbert]]

Boris, maybe you could take a look here?

(Confirming & triaging as S3 for now since it seems like a legit bug or at least interop difference, though it's a bit of an edge case and our behavior doesn't seem to have changed/regressed on the testcase anytime in the past few years at least.)

Comment 3

[Boris Chiou [:boris]]

I may take a look this later.

Comment 4

[Brian Birtles (:birtles)]

I don't think animations are supposed to start transitions. Certainly that was the original intention. That's why the before-change style is defined as:

...define the before-change style as the computed values of all properties on the element as of the previous style change event, except with any styles derived from declarative animations such as CSS Transitions, CSS Animations, and SMIL Animations updated to the current time. [emphasis added]

The idea being that by updating the animation state on the before-change style, there should be no difference due to animation between the before-change style and the after-change style.

I created some test cases around this a long time ago but all browsers have changed significantly since then: https://bug1192592.bmoattachments.org/attachment.cgi?id=8843824

I think there may have been discussion about simplifying those definitions at one point but I'm not sure if they've actually made their way into the spec.