Re: [csswg-drafts] [css-scroll-snap-2] Should scrollsnapchanging target the currently visible element during flings (#10838)

The CSS Working Group just discussed `[css-scroll-snap-2] Should scrollsnapchanging target the currently visible element during flings`, and agreed to the following:

* `RESOLVED: scrollsnapchanging uses the targeted location for targeted scrolls, but does not predict the destination of momentum scrolling (uses the current scroll location instead)`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> flackr: we defined scrollsnapchanging as using the "eventual scrol lpositition". this makes sense for targeted scrolls, but is confusing when flinging.<br>
&lt;TabAtkins> flackr: we'll predict a position far out, but if you change your scroll velocity the identified item jumps back to the one currently in view<br>
&lt;TabAtkins> flackr: proposing we change the behavior so that targeted scrolls (where we know the intended destination) that we use that target (as the spec already says), but for momentum scrolls we use the current position, as if you're actively scrolling and we don't know where you'll end up<br>
&lt;TabAtkins> flackr: this is more intuitive, where the identified item doesn't jump ahead of your scroll<br>
&lt;TabAtkins> +1, this sounds right. I'd expect indicated element to gradually move as the fling progresses<br>
&lt;TabAtkins> astearns: are you going to be able to tell what kind of things you're getting back?<br>
&lt;TabAtkins> astearns: targeted vs currnet scroll position?<br>
&lt;TabAtkins> flackr: API doesn't differentiate, you just get a currentTarget<br>
&lt;TabAtkins> flackr: for all the use-cases we've been talking about this feels right, but it's possible we might want something always based on the current location.<br>
&lt;TabAtkins> flackr: doesn't make sense to have something always based on target location; sometimes you don't have a different target location.<br>
&lt;TabAtkins> flackr: but if we eventaully wanted one for the currently-in-view thing even during a targeted scroll, we could add it<br>
&lt;TabAtkins> astearns: i don't have a particular reason to need it, was just wondering<br>
&lt;TabAtkins> flackr: yeah, for all use-cases we know - carousel, selected UI - it makes sense to use current or target as i'm proposing here, depending on type of scroll<br>
&lt;TabAtkins> astearns: other questions?<br>
&lt;TabAtkins> astearns: summary?<br>
&lt;TabAtkins> flackr: proposed resolution: scrollsnapchanging uses the targeted location for targeted scrolls, but does not predict the destination of momentum scrolling (uses the current scroll location instead)<br>
&lt;TabAtkins> RESOLVED: scrollsnapchanging uses the targeted location for targeted scrolls, but does not predict the destination of momentum scrolling (uses the current scroll location instead)<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10838#issuecomment-2536638877 using your GitHub account


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

Received on Wednesday, 11 December 2024 17:28:34 UTC