Re: [csswg-drafts] [css-overflow-5] Scrolling to unreachable scroll aligned marker positions (#11165)

The CSS Working Group just discussed `[css-overflow-5] Scrolling to unreachable scroll aligned marker positions`, and agreed to the following:

* `RESOLVED: Go with Option 5`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> flackr: this is similar to the earlier issue. i have a demo page with some options<br>
&lt;TabAtkins> flackr: it feels bad when you scroll that there are certain markers you just can't reach<br>
&lt;TabAtkins> flackr: the best compromise to handle this, short of the developer choosing to add extra padding, is to hijack the first and last "some amount" of scrolling (arbitrarily chose 1/8 of the scrollport width), and distribute that proportionally to the items before the first reachable scroll position, and same to end<br>
&lt;TabAtkins> flackr: so at position 0 you'll ahve the first marker selected, then you'll quickly zoom thru the unalignable markers, and then hit the first alignable marker.<br>
&lt;TabAtkins> argyle: if you're using scroll snap as a selection mechanism, this'll still be frustrating, but if you're just like browsing and the dots are highlighting as you scroll, it's not too bad.<br>
&lt;TabAtkins> argyle: so squishing down and virtualizing the amount of scroll to hit the remaining snap points seems reasonable<br>
&lt;TabAtkins> astearns: how does this interact with the previous resolution?<br>
&lt;TabAtkins> astearns: thru a non-scroll action you've activated the second item. is the scroll position now not 0?<br>
&lt;TabAtkins> flackr: my proposal is this doesn't change, it's still 0. but the moment you scroll, it'll jump to the first item (via this issue's calculation)<br>
&lt;TabAtkins> astearns: so i've navigated to item 2, i scroll to the right, my expectation is i'll go to item 3<br>
&lt;TabAtkins> flackr: yes, but you'lla ctually go to item 1. same as previous issue, several items conceptually at position 0, and as soon as you do a non-targeted scroll, it does a calculation (based just on scroll state) to find the active marker<br>
&lt;TabAtkins> q+<br>
&lt;astearns> ack TabAtkins<br>
&lt;astearns> q+<br>
&lt;fantasai> TabAtkins: I do recommend rolling through the demos in flackr's page<br>
&lt;fantasai> TabAtkins: once you play with them and realize how bad the behaviors all are<br>
&lt;fantasai> TabAtkins: you realize this gives you smooth behavior as you scroll<br>
&lt;fantasai> TabAtkins: it's not a perfect solution, but it's the best by a long shot<br>
&lt;fantasai> TabAtkins: all the others are actively terrible, just a little awkward, way better than the others<br>
&lt;TabAtkins> argyle: at least scroll padding, there's no magic. maybe there's extra space, but everything aligns, there's no edge cases, etc<br>
&lt;astearns> q-<br>
&lt;vmpstr> q+<br>
&lt;TabAtkins> flackr: i fully support guidance to say ideally make all your positions reachable. but i think it woudl be extremely breaking to force extra padding to your scroller.<br>
&lt;TabAtkins> argyle: it is annoying to add padding; flex and grid do some weird stuff<br>
&lt;TabAtkins> flackr: there's a linked issue to make that easier<br>
&lt;astearns> ack vmpstr<br>
&lt;TabAtkins> vmpstr: so if the first two markers aren't reachable, as i approach 0 scroll offset but not at 0, the marker would switch to the second, then the first...?<br>
&lt;TabAtkins> vmpstr: why not then if i click the second marker, it would position me at an offset that would show the second marker selected?<br>
&lt;TabAtkins> flackr: that has interactions with other specs<br>
&lt;TabAtkins> TabAtkins: [explains how scroll snap makes this situation untenable]<br>
&lt;fantasai> TabAtkins: [example of messing with scroll-snap behavior]<br>
&lt;fantasai> TabAtkins: You can't be in-between items when snapping is on<br>
&lt;TabAtkins> flackr: unless we did some signif work with scroll-snap, i think that would be even weirder<br>
&lt;TabAtkins> argyle: the goal is to have the perceptual marker match the end of scrolling... are we sending snap changing events?<br>
&lt;TabAtkins> argyle: there's like four dots i can't rest at...<br>
&lt;fantasai> TabAtkins: If your thing relies on actually being able to snap to every item, you need your layout to allow for snapping to those items<br>
&lt;fantasai> TabAtkins: we can't do anything to make that possible other than adding padding, which would break things<br>
&lt;fantasai> TabAtkins: There's an unwinnable situation here, need to compromise somehow<br>
&lt;TabAtkins> argyle: okay i'm interacting with them, they all seem to hijack my scroll in some way, 4 is the first item that snaps...<br>
&lt;TabAtkins> argyle: is option 5 everyone's choice for the least evil option?<br>
&lt;bramus> SGTM<br>
&lt;TabAtkins> (yes, for me)<br>
&lt;TabAtkins> argyle: on mobile does it get really weird?<br>
&lt;TabAtkins> flackr: my proposal uses a % of the scrollport width so it scrolls with the size<br>
&lt;TabAtkins> s/scrolls/scales/<br>
&lt;TabAtkins> argyle: thanks for the demo page, this experience speaks a thousand words<br>
&lt;TabAtkins> argyle: so these wouldn't emit snapchanging?<br>
&lt;TabAtkins> flackr: right because they're not snapped<br>
&lt;TabAtkins> argyle: okay but they just indicate visually<br>
&lt;TabAtkins> argyle: still a little bad but a compromise<br>
&lt;TabAtkins> flackr: when we support using real elements as markers, you'll also be able to use this to get those things indicated<br>
&lt;TabAtkins> astearns: so are we resolving on the least-bad option?<br>
&lt;TabAtkins> flackr: proposed is option 5 as the best we can do without breaking content. if we come up with somethign better in the future, we can consider changing it.<br>
&lt;TabAtkins> flackr: this does currently live in a non-normative part of the spec; we decided active marker calculation would be non-normative until we're happy with it. seems not too hard to change if we change our minds.<br>
&lt;TabAtkins> astearns: so proposed resolution is option 5. objections?<br>
&lt;TabAtkins> RESOLVED: Go with Option 5<br>
</details>


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


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

Received on Wednesday, 20 November 2024 16:58:11 UTC