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.

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

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

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

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.

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.

@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

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..

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): w3c/pointerevents#203 (comment)

I've broken this out into its own pointer-events issue w3c/pointerevents#512