[scroll-animations-1][css-animations-1] A non-animated "Is in viewport"

[noamr]

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.

.thing:in-view-range(view()) {
   view-transition-name: actual-thing;
}

[ydaniv]

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?

[noamr]

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)

[ydaniv]

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 🎂

[noamr]

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.

[flackr]

This seems like more of an ask for the css-animations spec to perhaps have a convenient syntax for a single value animation, though I recognize there was also a proposal to use view timelines as a state selector. Moving this to level 2.