[csswg-drafts] [css-transitions] Reading computed styles can immediately start then cancel transitions on newly mounted elements (#10187)

thecrypticace has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-transitions] Reading computed styles can immediately start then cancel transitions on newly mounted elements ==
Hi! I'm looking for some clarification on a particularly weird browser behavior with regards to CSS transitions on newly-mounted elements which I encountered while triaging a bug in a project I maintain for work.

Normally adding classes to an element can cause a transition to play (depending on the CSS properties being changed, state of the element, etc…). However, there's a situation where this doesn't happen correctly. To reproduce this you have to have an element do all of the following within the same frame in the following order:

1. Mount the element to the DOM; AND
2. Read the value of _any_ computed property via `getComputedStyle(…).getPropertyValue()` or `getComputedStyle(…)[property_name]` (note: this can be read from the animating element itself or any element in its subtree); AND
3. Add the class to the element that prepares the transition

When this happens a transition starts and is then immediately cancelled. And there is also an animation present when calling `Element.getAnimations()` when there normally would not be one. It happens in every browser I've tested (Chrome, Firefox, Safari, and Edge) but I can't find anything in the spec that would directly explain this behavior and it's a bit confusing because if you do any of the following, the transition plays as expected:

1. Read a computed property value AFTER adding the class
2. Don't read a computed property value
3. Wait one frame after mounting the element before doing anything else
4. Wait one frame before adding just the class
5. Use an element that is already in the DOM rather than mounting it

I've created two examples to demonstrate this behavior. One of them is a simplified version that demonstrates the issue directly. The other one compare it to some other situations where the transition plays as expected.

Press `toggle` to fade all elements out then press it again to fade them in and you'll see the behavior I'm describing.

- Simple example: https://jsbin.com/huxinohuke/1/edit?html,output
- Complex example: https://jsbin.com/tuyakemiru/1/edit?html,output

The [Starting of transitions](https://drafts.csswg.org/css-transitions-1/#starting) section of the CSS Transitions spec might be relevant here but the fact that this only happens for newly-mounted elements leads me to believe it's a bug and not intended behavior.

My question is basically: Is this the intended behavior? If so, is there a reason for it?


Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10187 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 9 April 2024 18:51:18 UTC