Doesn't work in Safari and Firefox.
The end result = the initial result.
And I would get rid of the mouse events in favor of pointer events.
ethan_smith 4 days ago [-]
Pointer events are definitely the way to go here as they unify touch, pen and mouse inputs while also providing pressure/tilt data and better handling of edge cases like when fingers leave the active area during a gesture.
jakelazaroff 4 days ago [-]
But crucially, it does work - it just looks like a normal select, rather than a fancy scroller.
Cyykratahk 4 days ago [-]
It's great to see more progress around scroll snapping - I'll have to check out this scroll-state container query and the new events.
The biggest missing scroll-snap feature I see is the ability to tell a scrolling container to "snap to the next position in this direction", and maybe by extension "which element(s) are currently snapped". In this article clicking an arrow moves the scroll position by a fixed 40px, but it would be very nice to have a proper API that accounts for element sizes, snap alignments, out-of-axis children, etc.
I ended up writing a package a few years ago that does this (scroll-snap-api). It feels so dirty to calculate the styles on every child in the tree just to find scroll snap positions.
oneeyedpigeon 4 days ago [-]
The delay between reaching the end of the list and the button greying out is a bit awkward, imo. I think the button should disable instantly, when the end of the list is reached.
tobr 4 days ago [-]
This is part 4 in a series. Part 1 makes it more clear that this is a very new feature with limited availability.
Seems to only work in Chrome, I stared at the "end result" in both Firefox and Safari wondering what the heck was so special about a regular old dropdown menu.
webstrand 4 days ago [-]
Yeah, this is using a new feature[1] only available in Chrome so far. Mozilla is positive[2] about the specification, so we should see it in Firefox eventually, pending an implementation.
And I would get rid of the mouse events in favor of pointer events.
The biggest missing scroll-snap feature I see is the ability to tell a scrolling container to "snap to the next position in this direction", and maybe by extension "which element(s) are currently snapped". In this article clicking an arrow moves the scroll position by a fixed 40px, but it would be very nice to have a proper API that accounts for element sizes, snap alignments, out-of-axis children, etc.
I ended up writing a package a few years ago that does this (scroll-snap-api). It feels so dirty to calculate the styles on every child in the tree just to find scroll snap positions.
https://utilitybend.com/blog/the-customizable-select-part-on...
[1]: https://developer.chrome.com/blog/a-customizable-select
[2]: https://github.com/whatwg/html/pull/10548