[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 https://github.com/w3c/csswg-drafts/issues/8298#issuecomment-1412484155. 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.