- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 27 Jul 2022 16:49:46 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Should the range of ViewTimeline be clamped?`, and agreed to the following: * `RESOLVED: ViewTimeline progress is not clamped by scrollable range` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: Should the range of ViewTimeline be clamped?<br> <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/7432<br> <TabAtkins> flackr: In ViewTimeline, if the subject you'e observeing is at the top of the page it starts in view, and you can never scroll to a position where it's "start".<br> <TabAtkins> flackr: Does it start part of the way thru the animation, or do we clamp the range?<br> <TabAtkins> flackr: There are use-cases for entry/exit where it's clearly better to not clamp the range<br> <TabAtkins> flackr: Slightly better for parallax if we do<br> <TabAtkins> flackr: But think it's possible to produce a clamped range from an unclamped, but can't do the latter reasonably<br> <TabAtkins> flackr: So I propose we don't clamp the range. In the future we can consider another phase or something if we do need to address this.<br> <TabAtkins> Makes sense to me<br> <fantasai> +1 to optimizing for fade-in/fade-out type animations<br> <TabAtkins> astearns: Is the range clamping a discoverable thing?<br> <TabAtkins> flackr: Not clamping is the easier thing for devs to reason about<br> <TabAtkins> flackr: Clamping means suddenly your produced times change if your element is near the beginning or end of the scroller<br> <TabAtkins> flackr: It's completely observable what time you get and if it's clamped or not<br> <TabAtkins> flackr: Could be exposed if we had a start and end scorll offset; the offsets would be negative<br> <ydaniv> q+<br> <TabAtkins> flackr: Dont' rmemeber if we have that or not, we might<br> <astearns> ack ydaniv<br> <TabAtkins> ydaniv: Not sure I follow on clamping<br> <TabAtkins> flackr: It means you'd always be able to reach the full range of the animation<br> <TabAtkins> flackr: So if the element started in view it would start at 0% and progress to 100% as it scrolled out of view<br> <TabAtkins> flackr: I think it's more confusing to do that<br> <TabAtkins> flackr: It complicates the relationship between position and animation progress<br> <TabAtkins> ydaniv: So if I have an enter animation, but the element starts halfway on screen<br> <TabAtkins> ydaniv: So if you clamp, I'd still start at 0% and progress the whole animation?<br> <TabAtkins> flackr: Right<br> <bramus> +1 on not clamping<br> <TabAtkins> flackr: Whereas uhnclamped it would start at 50% of the entry phase, matching the progress<br> <TabAtkins> ydaniv: For me, not clamping is the natural way to go<br> <TabAtkins> ydaniv: So like fade-in/fade-out, if my element is already in the displayed area...<br> <TabAtkins> flackr: Think there might be a conflation of scroll-trigger and scroll-driven animations<br> <TabAtkins> flackr: So if the element is halfway in, unclamped would make it half faded in<br> <TabAtkins> flackr: There are a few places where clamping is useful, if you do want the full set of keyframes available.<br> <TabAtkins> flackr: Example in the issue - an oversized image and I want it to transition from topmost to bottommost.<br> <TabAtkins> flackr: If it starts onscreen you can use an exit animation anyway<br> <TabAtkins> ydaniv: So I vote for not clamping and maybe creating a clamp mechanism later, since it seems like extra magic<br> <TabAtkins> flackr: Yeah that's the proposal. I don't think we should make the clamp mechanism yet, until we see use-cases.<br> <TabAtkins> astearns: So proposed resolution is that ViewTimeline progress is not clamped to the scrollable range<br> <TabAtkins> RESOLVED: ViewTimeline progress is not clamped by scrollable range<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7432#issuecomment-1197024321 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 27 July 2022 16:49:48 UTC