- From: Yehonatan Daniv via GitHub <sysbot+gh@w3.org>
- Date: Tue, 31 Jan 2023 20:34:29 +0000
- To: public-css-archive@w3.org
> We would also update cover, enter and exit to take this into account as well, right? Well, if I'm not mistaken, cover doesn't have an edge case here. If the element is stuck somewhere in the scrollport then we're still during cover. Unless you mean from implementor point of view (and polyfill of course)? To make sure calculation of effective scroll length includes the stuck duration? Same goes for enter and exit, I don't think we have edge cases here that requires special attention, right? > It's a bit less intuitive when the sticky element is not smaller than the scrollport and the contain range would be larger than the stuck range, however I could see it still being useful. Yes. If the sticky element is equal in size then contain==stuck. If the element is larger then it's either still in enter, or at beginning of contain - as in `top: 0`. In that case I'd expect it would be prepended to contain and beginning of stuck would be `contain 0%`. Need also to check how these match with the ranges proposed in #7973 . And, I'd also consider adding a specific range `stuck` which should IMO provide a very ergonomic sugar for all these cases. > I'm not quite sure what you mean by include a switch case with the definition for sticky. I think doing this requires that we work out the minimum and maximum sticky offset (including ancestor sticky elements in the case of nested sticky elements). This is roughly equivalent to answering what is the sticky offset when scrolled to the max scroll offset - and using that offset for the start / end positions. I simply meant to add sort of `if`s in the spec to handle these cases. And yes, I guess we need figure out these cases. > I suspect that view timelines should operate on the layout position just like position: sticky does. I think this may already be implied by the fact that the spec already uses the [principal box](https://www.w3.org/TR/css-display-3/#principal-box) which is the same one used for positioning Whoa, we were just on that page this week for implementing scroll animations, and I read the definition of `principal box` but couldn't understand from the spec that it actually means _excluding_ transforms, so I _did_ expect it to behave as it is currently in blink. On one hand, yes, it makes it trickier for authors when interacting with transforms, kind of like`:hover` is. So this will simplify it. But then your effective view ranges won't match the ones calculated by the timeline. Take for example a simple parallax effect, simply using `cover` will stop animating somewhere in the middle of the range. -- GitHub Notification of comment by ydaniv Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8298#issuecomment-1411030022 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 31 January 2023 20:34:31 UTC