[SELECT] Scrollbars in select list-box about open-ui

[gregwhitworth]

This is not something that we have dug into but raises an interesting question about scrolling UX for <select>. Of course scrollers can vary dramatically in the UI that is afforded them while the behavior goal is relatively the same even if the personality of scrolling varies. I can imagine the parts for a scroller. @chancestrickland any chance you want to take an initial stab at scrollbar research?

[chaance]

Yes. I've found that almost no design systems include scrollbars as we typically think of them. The MacOS scroll indicators in select menus, which were the original motivation for the issue here, do not technically meet the definition of a scrollbar since there is no range or drag button, which is generally expected per the ARIA authoring practices. Kind of wondering if it even belongs in the scrollbar spec, or if it deserves its own element.

I've started on the research page, but most of the prior art I've found is in web apps and custom scrollbar libraries rather than any of the design systems we document. So I expect the format will need some work. Hoping I'll have time to polish and submit a PR early this week.

[gregwhitworth]

I've started on the research page, but most of the prior art I've found is in web apps and custom scrollbar libraries rather than any of the design systems we document. So I expect the format will need some work. Hoping I'll have time to polish and submit a PR early this week.

@chaance I need to get a doc page up about this but please don't limit to the component libraries on research. Research any and all areas that you can. While it hasn't landed take a look at the popup explainer here: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Popup/explainer.md

You'll notice it's not a 1:1 with other pages and that's ok. The goal of the research page is not solely about listing out the JSON aspects although that's a nice start it's only the beginning. The usecases, the behaviors, how it works in other scenarios outside of component libraries on the web. So if you'd prefer to start in a more explainer form to document your findings in addition to the JSON content please do. For example, here is the concept/part naming page for slider which is useful for defining the slider anatomy: https://open-ui.org/components/slider.research.parts

And don't feel like you need to land ALL research in a single PR. Allow it to evolve over time so others can see it.

[chaance]

Happy to!

[gregwhitworth]

Thanks @chancestrickland - if you can start up a research page for scrollbars.

[gregwhitworth]

@chancestrickland any update on this?

[Rayraz]

@gregwhitworth and @chaance I'd like to push for some standardization around scrollers in general and would love to join the effort. I've got zero experience working on proposals for web standards, but I do think I have some useful ideas.

I've got a good amount of experience working on custom scrollbars and other scrolling-related UI and I've got some ideas about things that should really be standardized. My experience with ARIA is limited at best, but I'm sure that's nothing that should hold me back too much.

It might be a good idea to spin off scrollers into a separate UI component. We could then apply the outcome to things like Select, Textarea, etc.

Ideally I'd love to see things moving in a direction where developers have two paths for dealing with scrollers:

1. A standardized set of UI elements for scrollers, including ways to style these elements through CSS. This should probably at the very least include scrollbars and scroll buttons.
2. A way to disable all chrome on elements with overflow and provide devs with everything they need to decorate scrollers with fully customized UI elements instead.

@chaance is there any chance I could join the effort on the research page?

[chaance]

@Rayraz Absolutely, I haven't had as much time as I'd initially hoped to work on OpenUI but this is still a huge need. I wrote the custom scrollbar component in Radix UI and learned quite a bit in the process, so I'd be happy to chat with you to see how we can turn our experiences into something actionable for web standards.

[Rayraz]

Sounds like a plan. I'll hit you up on discord.

[gregwhitworth]

Hey @chaance @Rayraz there is an explainer up by @felipeerias from Chromium. This is primarily going after the ones already in CSS Scrollbars so this may not be new to you, but given there is a TAG review currently underway I'd like to ensure that you all give it a glance. Given what you all have said above I'd like to ensure this is heading the direction you all intend to leverage in your sites.

[Rayraz]

@gregwhitworth, I've spoken with @chaance last week on Discord and expressed my initial ideas. I think the first two goals should probably be the following:

1. Make it easy to get rid of any native chrome while keeping all user interactions. That way devs can easily create their own scroller chrome.
2. Make it easy to style native chrome.

The first one should be fully covered by the scrollbar-width property. The 2nd point is partially handled with scrollbar-color.

Since there are many different types of scrollbars and other scroll ui, I think the current suggestion for scrollbar-color is a great first step. While it's not very specific about how the colors are applied, I imagine it should be relatively easy for browsers to implement and that's great for fast adoption and backwards compatibility.

In my opinion, where OpenUI comes into it's own would be if we could define a small selection of common types of scroll ui's. We could work out a css property to define what type of scroll UI should be used (a full scrollbar with buttons, indicator-only, MacOS's arrow, maybe something more suitable for slideshows).

As far as I can think of right now, none of those things should be in conflict with the current CSS Scrollbar proposals in any major way. Maybe the scrollbar-color name could potentially be changed to scroll-ui-color or something like that, so as not to limit it to scrollbars only. I find it hard to judge if that's important or just entering into bike-shedding territory though.

I've asked @chaance if he could send me a work-in-progress of the research, but I'll do my best to take a stab at it myself in the mean time.

[github-actions]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.