When first setting the value of a unregistered custom property, no transitionstart is triggered
Categories
(Core :: CSS Transitions and Animations, defect, P3)
Tracking
()
People
(Reporter: bramus, Unassigned)
References
(Blocks 1 open bug)
Details
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36
Steps to reproduce:
(This bug was discovered while building @bramus/style-observer, a library that responds to changes in computed styles. For this it relies on CSS Transitions and transition-behavior: allow-discrete. See https://brm.us/style-observer for details about this library.)
- Navigate to https://allow-discrete-bugs.netlify.app/firefox/unregistered-no-transition/
- Make note that the custom property
--variable2
is not registered with@property
and is currently not part of any declaration. - Click the
--variable2
button.
Tested in Firefox Nightly 131.0a1 (2024-09-01) (aarch64)
Actual results:
The first click on the --variable2
button does nothing. All successive clicks on that button do update the output.
Expected results:
Clicking the --variable2
button should update the output from the first click on.
Note that I am not sure if it is specced what should happen here. As an author, I’d like to get notified of this change though.
Comment 1•2 months ago
|
||
The severity field is not set for this bug.
:emilio, could you have a look please?
For more information, please visit BugBot documentation.
Updated•2 months ago
|
Reduced reproduction: https://codepen.io/bramus/pen/PorrjGb/ec715b1f98022bf3dcb0022e3f7d08e2
Comment 3•1 month ago
•
|
||
It seems the spec (css-variables-2) doesn't mention anything about the inter-operation for unregistered custom properties and transitions. So I'm not sure if this is a bug or an expected behavior. However, WebKit looks good so I treat this as a Gecko bug for now.
Gecko didn't create the transition because we cannot get this custom property's value from the old computed style.
Perhaps we have to tweak AnimationValue::from_computed_values() to make sure it returns a suitable value. I saw there is a bug number here (Bug 1869476) but not sure if that's the reason.
Zach, is Bug 1869476 the reason that we cannot get the unregistered custom property's value from the old computed values when clicking the button at the 1st time?
Comment 4•1 month ago
|
||
(In reply to Boris Chiou [:boris] from comment #3)
Perhaps we have to tweak AnimationValue::from_computed_values() to make sure it returns a suitable value. I saw there is a bug number here (Bug 1869476) but not sure if that's the reason.
Zach, is Bug 1869476 the reason that we cannot get the unregistered custom property's value from the old computed values when clicking the button at the 1st time?
I tested an unsubmitted draft of bug 1869476 before implementing bug 1875546, it didn't result in any behavior change at that time. I'll be happy to complete bug 1869476 to know for sure.
Comment 5•1 month ago
|
||
This might be worth a spec issue... What is the transition start value for an unset property? I guess we could keep a null value or something, or mint an empty string? But feels quite odd.
Comment 6•1 month ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #5)
This might be worth a spec issue... What is the transition start value for an unset property? I guess we could keep a null value or something, or mint an empty string? But feels quite odd.
I agree with this. Actually when I looked at this bug, I thought there is no before-change style value for this unregistered custom property. No sure if we should give it an initial value but it didn't have a type. We probably need a spec issue to define an initial value for transition purpose, or we should treat this custom property as no start value and so no transition.
Filed https://github.com/w3c/csswg-drafts/issues/10962 to discuss this with the CSS WG.
Description
•