Re: [csswg-drafts] [web-animations-2][css-animations-2] How should unspecified trigger range boundaries be resolved? (#11932)

Thinking about this a bit more: since the capabilities are the same either way, making it necessary for an author to have to specify, for example, `entry 100% scroll 100%` for the single point case really doesn't seem so bad, especially since it means we can stay consistent with `animation-range` by defaulting to `normal` and also preserve the meaning of `normal`.

I think the alternate example in @flackr 's [demo](https://flackr.github.io/web-demos/scroll-triggered/) demonstrates a common pattern where the element slides in and out at the bottom and top of the viewport, corresponding (roughly) to the cover range. I think it makes sense for the default setting, where a `view()` timeline has been declared, to cater to this use case (all the author needs write is `contain` or `cover`). If we default to `scroll 100%` for the end of the default range, the author has to write `contain 0% contain 100%`, otherwise the slide out at the top of the viewport won't happen.

I guess one other option is to make the default range dependent on the type of trigger, e.g. `once` defaults to `scroll 0% scroll 100%`, `alternate`, `repeat` and `state` default to `cover 0% cover 100%`. In which case maybe an auto keyword for the default range might make sense. But this, or a similar scheme, seems a bit developer-unfriendly to me as they'd have to keep track of which type maps to which default range.


Also, for the exit range I think using `auto` as the default and having it mean "match the default range" sounds good. That way the meaning of `normal` is fully preserved.

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


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

Received on Thursday, 27 March 2025 17:04:23 UTC