- From: Yehonatan Daniv via GitHub <sysbot+gh@w3.org>
- Date: Tue, 21 Nov 2023 12:32:12 +0000
- To: public-css-archive@w3.org
> The current [named timeline ranges](https://drafts.csswg.org/scroll-animations-1/#view-timelines-ranges) all depend on the subject dimensions. If the subject changes dimensions, or the same range is used on another subject, the timing will be different. That's the whole point of "view", it's the intersection of the element inside it's scrollport. > Can we define another named timeline range size-independent-to-be-bikeshed, where: > > * 0% progress represents the latest position where the center of the element's principal box coincides with the end edge of its view progress visibility range. > * 100% progress represents the latest position where the center of the element's principal box coincides with the start edge of its view progress visibility range. What is "latest" position? "latest" relative to when? > This will let authors set a view-timeline where the timing will not depend on the size of the subject, only its position. Again, position relative to what? What you want is probably to "dumb down" the model and be able to reduce the element's rectangle to a point. Then you can reason only about the scrollport. So that point needs to be something you can specify, like `start`/`center`/`end`. Then you need to reference that point to the scrollport. > The timing of the 'cover' range will become increasingly slow as the subject size increases, while the 'contain' range will become increasingly fast as the subject size gets closer to the view progress visibility range. A timing that seems reasonable on a desktop screen, might be lighting fast on a small mobile screen. That's true only if you animate dimensions (width/height) and/or position (top/left/bottom/right/inset). It doesn't change if you animate `transform`. If you do have to animate dimensions/position then you should either wrap that element in another element and use that as the subject, which isn't ideal, or use `scroll-timeline`, which also isn't ideal. But I guess that's the trade off for handling such a powerful tool. Again, unless we consider referencing a point on the element, instead of its entire rect. > Creatives coming from other fields such as animation have found this hard to grasp. Yes, though they're not really our target audience here. Anyhow, I've also come across this quite a lot. I think this is rooted in 2 things: 1. You didn't have this technology before, so everyone is used to using a library that simply targets a point on the scroll in pixels, like `ScrollTimeline`. And people are still having a hard time with that. 2. They're used to libraries that depend on IntersectionObserver and trigger once a point is reached in the viewport. Also, If you ask them: "how did you do that in After Effects etc.", the usual answer will be: "I created a dummy element to visualize the trigger", which kinds of goes back to using a wrapper element. I don't really see how manipulating the `view-timeline-inset` helps here, it simply changes the scrollport's reference. Bottom line, maybe the current range names are a bit too magical? We could consider having something like `entry-start`/`entry-center`/`entry-end` etc. -- GitHub Notification of comment by ydaniv Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9617#issuecomment-1820838321 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 21 November 2023 12:32:14 UTC