transition to value of scroll-animated CSS variable fails
Categories
(Core :: CSS Parsing and Computation, defect, P3)
Tracking
()
People
(Reporter: ana.tudor.lhnh, Unassigned)
Details
Attachments
(1 file)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:133.0) Gecko/20100101 Firefox/133.0
Steps to reproduce:
- Give the root element a
height
a few times bigger than the viewport and tie a custom propertyprg
to the scroll progress.
@property --prg {
syntax: '<number>';
initial-value: 0;
inherits: true
}
html {
height: 900%;
animation: prg 1s linear;
animation-timeline: scroll()
}
@keyframes prg { to { --prg: 1 } }
Note that this requires layout.css.scroll-driven-animations.enabled to be set to true in about:config.
- Introduce another custom property on the body. This custom property should be lagging behind a bit.
@property --lag {
syntax: '<number>';
initial-value: 0;
inherits: true
}
body {
--lag: var(--prg);
background:
linear-gradient(90deg,
darkorange calc(var(--lag)*100%), #0000 0),
linear-gradient(90deg,
purple calc(var(--prg)*100%), #0000 0);
transition: --lag .75s cubic-bezier(1, 0, .5, .5)
}
Actual results:
There is no transition
for --lag
in Firefox. It's not noticeable visually and transition events don't get triggered.
Expected results:
There should have been a transition
for lag --lag
. This is what happens in Chrome - the orange progress lags behind the purple one.
Live test https://codepen.io/thebabydino/pen/MWNrdVj?editors=1111
The problem can also be seen here https://codepen.io/thebabydino/pen/poMpGxE?editors=1111
Comment 1•3 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::CSS Parsing and Computation' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 2•3 months ago
|
||
The severity field is not set for this bug.
:jwatt, could you have a look please?
For more information, please visit BugBot documentation.
Updated•3 months ago
|
Description
•