Re: [csswg-drafts] [css-animations] Extend animation-play-state for triggering animations when an element is in viewport (#8942)

> The idea of using an `in-view` selector was dismissed

I'm just curious about what the discussion was here. I know in the very very early days of the scroll-driven animations spec we have scroll triggers which would have been awesome--basically like declarative intersection observer so you could trigger transitions or even just static changes. The main problem was just that you couldn't easily implement them such that they run on the compositor. I think they were probably the same thing as `in-view` selectors. Is that the reason the `in-view` selector was dismissed?

> Perhaps this could be inferred from the `animation-fill-mode`, so that `both` and `backwards` are used for those respectively.

Fill modes are tricky. They don't compose very well and we had to introduce the whole effect replacing mechanism just to prevent them from leaking memory. At times we've talked about deprecating them if we could. They might be the right primitive here, but just as a knee-jerk reaction, I think it would be worth considering other options before we try to overload them for this.

-- 
GitHub Notification of comment by birtles
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8942#issuecomment-1586433047 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 12 June 2023 01:27:11 UTC