[css-overflow-3] [css-ui-4] Draggable scrollers

[bramus]

(Not sure which spec this should go into, ergo not tagging it)

Whenever I see demos like https://codepen.io/supah/pen/xxJMbbg I’m wondering what it would take to make a scroller draggable on desktop (i.e. click + hold on the scroller and then move the pointer to change the scroll offset)

Yes, it can be done with a tad of JS but that’s blocking and would require authors to try and recreate the native fling curves to get it right, often leading to an uncanny valley type of situation as that’s OS dependent.

Ideally, to me, it would be a single CSS property that says “this scroller can be dragged to scroll”. When activated, clicking + dragging on the padding-box of the scroller will change the scroll offset in response.

While this has some implications such as not being able to select text in those scrollers (I guess), I don’t think this is a problem for things like https://scroll-driven-animations.style/demos/cover-flow/css/. Authors should be educated to only use this feature in certain situations.

[Loirooriol]

No tag just makes it easier to forget about issues. Scrolling containers are CSS Overflow, and interaction with the pointer seems CSS UI, so going with that.

[bramus]

Thanks, Oriol. I’ve updated the title to reflect this as well.

[yisibl]

Yes, this interaction effect is very popular: https://twitter.com/didiercatz/status/1744065302088843508

I have a hack implementation: https://twitter.com/yisibl/status/1744691885606945102

https://github.com/w3c/csswg-drafts/assets/2784308/d83e7660-9861-4eb8-a17e-8fd6b37fb84e

[argyleink]

What if the way this was implemented was with a "full scrollport covering, invisible, track and thumb". No code would have to change in the engine, because to it, the user is just dragging the thumb inside the track. To the user, they feel like theyre panning. As if scrollbar-width accepted 100cqb or 100cqi.

[yisibl]

What if the way this was implemented was with a "full scrollport covering, invisible, track and thumb". No code would have to change in the engine, because to it, the user is just dragging the thumb inside the track. To the user, they feel like theyre panning. As if scrollbar-width accepted 100cqb or 100cqi.

This may result in the specified tab not being clicked.

[yisibl]

@argyleink I achieved a similar effect using scroll-snap + scroll-timeline, and I'm not sure it can be improved any further.

https://codepen.io/yisi/pen/abMwRGL

[donnysim]

This would be great, there's a lot of cases where the content converts into a slider on mobile or desktop. Having the ability to define ability to drag scroll with mouse would remove the need for most slider libraries and doing gymnastics on enabling or disabling them or sometimes even having slider running but with display: none; on breakpoints which is less than ideal. The scroll-snap is one part of the puzzle that takes us far but it does not work with js drag as it prevents any kind of scroll modification, which leads you to still pretty much implementing all the smooth scroll logic at which point is why even bother, just use a library.

For some situations like the active item or/and a number indicator n/total would still be acceptable to do with js as most of it can be easily achieved with intersection observers and that would still be a fraction of js that is needed for a full fledged slider, while at the same time just a minor hiccup with js disabled as most would still work.

For the text selection, browsers maybe could implement the same logic as with links, hold Alt to select the text without triggering the link etc..

[flackr]

I suggested a direct-manipulation (the spec term for pointer devices which scroll on down) over in pointer-events (which is where we have the related touch-action defined): https://github.com/w3c/pointerevents/issues/203#issuecomment-819693123

I've broken this out into its own pointer-events issue https://github.com/w3c/pointerevents/issues/512