- From: fantasai via GitHub <sysbot+gh@w3.org>
- Date: Wed, 29 Sep 2021 07:47:16 +0000
- To: public-css-archive@w3.org
@bramus Responding to a few of your comments... > when the animated element is not a child of the scroll container — you'd also have three identifiers again Not quite, the scroll() function looks up to the nearest scroll container ancestor, it doesn't have to be the parent. > With the adjustments, I guess this be the correct way to do it [...] Yes. Looking at your example, maybe we should have a way for an element to grab the nearest ancestor view-timeline, same as we do for the nearest ancestor scroll-timeline? > where the navigation <nav> positioned underneath the slider #s is not a descendant of the slider #s itself This seems like it ought to be a transitions demo rather than an animations demo, to be honest! Though I'm not sure how we can capture the state there to make it transition... a problem for another day, I guess. We could make the view timelines global to the page, but we'd probably want to make sure that multiple view timelines that have the same name are prioritized by proximity (similar to how counters work). > Often it is also required to perform an animation as an element slides into the scroller, or slides out of it — e.g. not only while it is in view. Interesting! We should definitely make that easily possible somehow. Have to think about that... > Is it possible that there's a typo there and that the very last words should be “… 100% (contain).”? Good catch. Should be 0% (cover). But we're open to arguments in favor of a different default. :) -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6674#issuecomment-929925562 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 29 September 2021 07:47:18 UTC