You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Following up on #8282:
Currently to set a style that behaves differently based on whether the element is in the viewport, one has to use scroll-driven animations. For example, to set a view-transition-name when the element is in the viewport:
@keyframes set-name-when-in-view {
from { view-transition-name: actual-name }
to { view-transition-name: actual-name }
}
.thing {
animation-name: set-name-when-in-view;
animation-timeline-name:view();
}
The above works! However it requires going through an animation mental model for something that's not actually animated.
Perhaps view-timeline (or CSS animations in general?) can provide a convenient way to use animation primitives on something that's not animating? e.g.
Using a layout dependant state in a selector is something that we tried to avoid so far, as to avoid endless loops.
This is also why we went with a value-based approach for animation-trigger.
However, perhaps we could consider this as a further extension for State Container Queries?
Using a layout dependant state in a selector is something that we tried to avoid so far, as to avoid endless loops. This is also why we went with a value-based approach for animation-trigger. However, perhaps we could consider this as a further extension for State Container Queries?
Yea that might be a better approach. Though I think endless loops in particular (pseudo-class) selectors are not an essentially different problem from view-timeline endless loops (you animate transform based on view() which changes your view-timeline and so forth)
Specifically for that we ignore transforms, per #8298 (comment).
This is what makes view() so appealing for animations, you can reason about it and have complex animations at the same time 🎂
Specifically for that we ignore transforms, per #8298 (comment). This is what makes view() so appealing for animations, you can reason about it and have complex animations at the same time 🎂
Can't you animate the view timeline size, or animate something else that makes it move into/out of the viewport?
All of this is dandy but it has to do with when view() is computed, not with whether it's an at-rule or a pseudo-class.
Following up on #8282:
Currently to set a style that behaves differently based on whether the element is in the viewport, one has to use scroll-driven animations. For example, to set a
view-transition-name
when the element is in the viewport:The above works! However it requires going through an animation mental model for something that's not actually animated.
Perhaps view-timeline (or CSS animations in general?) can provide a convenient way to use animation primitives on something that's not animating? e.g.
The text was updated successfully, but these errors were encountered: