Yeah so interesting that with 96 focus areas proposed, scrollbar styling made it to the final set of 16.
Would be curious to know what 80 things were deemed less important than dinking with how scrollbars look. Maybe it was just an easier area to create a win? Maybe there are some benefits of styling a scrollbar that I'm not thinking about? Something that makes it a little easier to emulate native OS behaviors with web technologies, perhaps? Has this ever been a must-have feature on a project anyone has worked on?
> Has this ever been a must-have feature on a project anyone has worked on?
I have a highly interactive web app which simultaneously displays tens of panels each with it's own scrollbar. It's vital that they are thin and match the web app styling.
Good UX demands the correct distribution of visual weight. If a design requires many scrollbars, and those scrollbars have static styles, than those scrollbars dictate the visual weight of the rest of the app. This can make it impossible to design a nice intuitive UI around. So vital can definitely be an appropriate description for certain UIs
Normal width scrollbars use way too much space. This is a professional app with a complex dense UI, similar to ones used by image editors, music production software, 3d modelers. All of these use non-native controls, since native ones are too "wasteful"
This is the compromise - allow the scrollbar to be styled and in exchange developers don't implement their own scrollbars in javascript (as demanded by designers/managers)
The new scrollbar styling properties are actually pretty consistent with native platforms. There's not that much flexibility with them - e.g. you can't define width in pixels, you just chose between thick, thin, or none, which match the existing native controls:
> To add more information to this issue. This property supports three values, auto, thin and none. These match nicely to WebKit's ScrollbarControlSize::Regular and ScrollbarControlSize::Thin and not rendering the scrollbar.
That ship has long since sailed. The web is the preferred framework for creating "non-native" (maybe nomadic? colonizer? invasive?) apps that largely ignore their host platform in favor of being the same everywhere. For better and worse this is what developers and designers have always wanted out of portability.
It's also what I, as a user, want. I don't want some middle-man corporate "platform" (of which there are very few to actually select from to suit your personal tastes) inserting their vision of what UIs should look like into interactions between me and the service I'm connecting to. I want my platform to be as invisible as possible and interchangeable with other platforms. The more things stay the same when switching between platforms, the better.
It's also a lot easier to learn the 2-4 dominant UX paradigms of the dominant platforms than the hundreds we have now with everyone doing their own thing. Doing remote tech support for elderly relatives is hell when you can't even rely on a menu bar being present/useful.
This is a rather bad way of making portability. It is bad for accessibility (even though they tried to add things to improve accessibility, it does not work very well), for working on multiple types of computers (since, then the software specific to that computer cannot do so by itself, and instead needs to use the specification of the received file, which is probably wrong anyways), and for many types of features that may be helpful but that are unavailable or are not designed or implemented well. Furthermore, WWW is also, not work well with multiple programs and with user customization very well, pipes, etc. And, it is complicated to implement and does not run efficiently. And, there are many security issues, having to be made more complicated just to avoid some of them, in ways that would not be necessary if it were designed properly. And, anyways, it cannot be the same everywhere, even if they want it to be.
This is mostly a question of costs & availability of developers. There's simply not enough native developers on the market, and the good ones can ask very high salaries.
Hiring N teams of M developers for N native apps, compared to hiring K<<M web developers is way more expensive, difficult, and slow.
Or seriously, working on software ecosystem preservation just to preserve it it is absurd. Things get replaced because people want, and at this point you are just trying to force people to use things they against their wishes.
If it wasn’t fore scrollbar styling, developers would just roll their own. And even if developers would be aware of how terrible it is, designers would still design it, and project managers would still demand it.
Even native scrolling is not without issues. If you have horizontal scrolling on a flex container with `flex-direction: row-reverse` the native scrollbar won’t work in Safari. So developers implementing a list which flows from the inline end to the start, are faced with two bad options. Either implement your custom scrollbar or reverse your list items before rendering to the page and set the scroll position everytime the list updates in JavaScript.
This. "How difficult would it be to write a custom implementation of scrollbar in JavaScript?" (whose performance would be 100x slower than native browser scrolling, but who cares, we all have Macbook Pros, right?)
The most offensive part is that the width is configurable. This gives try-hard designers more of an excuse to hijack and fuck up scrollbars.
The colours I don’t mind so much. Ideally all this would be a simple checkbox to toggle on right click of the scrollbar, but that gives the user choice which is almost a foreign concept in some circles.
I would agree but only for the main page scrollbar, but you can have app widgets like dropdowons, listboxes, grids that need to customize it's look like in PRO GUI toolkits.
Although some browsers might allow you to disable CSS, this can also cause problems with some files. One thing is that some implementations of form fields will not work at all with CSS disabled. One alternative would be a mode to use ARIA for styling instead of CSS. If the web page uses ARIA to denote the custom form fields and other stuff, then this might work; however, I do not know of any implementation that is capable of using ARIA for such a purpose (usually they use ARIA only for people with disabilities, but it could be useful for anyone, I think).
Yes, yes I definitely would apply this to others. Sick and tired of web developers and "designers" killing any usability and accessibility in those controls.
For those downvoting: Just as an example here's Google's Material "designers" doing a study with 800 people to figure out that yes, text fields must look like text fields, and learning literally nothing from it: https://medium.com/google-design/the-evolution-of-material-d...
As a bigger example: almost every single CSS framework decides that color and contrast are for suckers and makes many controls (and especially text inputs) with barely visible gray-on-gray colors.
I wish that this "feature" didn't exist. Just follow the platform and the user's defaults.