Alright, I guess I'll go back to using js scrollbars instead /s
I hate articles like this because they present highly opinionated solutions as something definite even though it has a narrow focus on what the author cares about.
Web apps can be incredibly powerful and convenient, sometimes a scrollbar is in the middle of the page like with that codepen. In those situations, being able to style and control the width of the scrollbar is useful.
How about we hold developers accountable for their work instead of trying to ruin it for the rest of us because a minority do something badly.
> being able to style and control the width of the scrollbar is useful
No it's not. I have operating system wide settings for how scroll bars should work and the rules are complex with visibility and size of the scroll bar changing from one second to the next.
I expect my scroll bar settings to apply to all websites and they are significantly better than what codepen does.
Codepen also doesn't allow me to scroll past the beginning/end of the file, which feels jarring and just wrong with a touch scroll device.
And I'd bet it also falls apart with assistive technology for people who can't physically operate a mouse or trackpad, which in most countries is illegal. Why open yourself up to those issues?
> Codepen also doesn't allow me to scroll past the beginning/end of the file, which feels jarring and just wrong with a touch scroll device.
Stuff like this often happens because of a lack of native styling options. Can’t change the appearance of the scroll bar (for, yes, often dumb reasons)? OK then we’ll use a giant JS library that poorly replicates every aspect of scrolling.
At least with native scroll styling, ugly as it may be, you get native behaviours.
The person you're reacting to is making a distinction between a native (in the context of browser) scrollbar with the ability to change its presentational style (but not behavior) and a completely custom JS driven scrollbar with likely different behavior from the native experience.
> highly opinionated solutions as something definite even though it has a narrow focus on what the author cares about
Most users either don't have such strong opinions about their scroll bars, or would prefer it looks coherent with the application, or OS-native (your preference). But I can almost guarantee the larger group of non-technical users will have never thought about the styling of their scrollbars for more than a few seconds.
Also in terms of accessibility, so long as they're doing CSS-only changes, and the bar is sized compliant and has proper focus states, assistive technology won't care.
But I can almost guarantee the larger group of non-technical users will have never thought about the styling of their scrollbars for more than a few seconds.
I think you're saying that this means it doesn't matter, but it actually increases the importance of respecting the users choices. Anyone who has changed their scrollbar has done so because it's important enough to them to bother. They've put effort in. That means there is far more likely to be a good reason not to override their preferred styling.
> But I can almost guarantee the larger group of non-technical users will have never thought about the styling of their scrollbars for more than a few seconds.
So you argument in favor of breaking the UIs of the non-technical users - who don't know that it is not their computer working wrong, but rather the site operator deliberately making things inaccessible - is users don't know that it is you breaking things? Sounds rather horrible.
> Also in terms of accessibility, so long as they're doing CSS-only changes, and the bar is sized compliant and has proper focus states, assistive technology won't care.
Eh, it depends on your audience. My father has very poor eyesight. He doesn't use any assistive tools (e.g. screen readers or magnifiers), but he does need his computer-reading glasses. Accessibility isn't just ADA compliance and/or screen reader support.
Same argument for why we should use tabs over space when accessibility seems squarely focused on the blind and screen readers when visual impairment is a broad spectrum. My eyesight isn’t ‘bad’, but it isn’t what it used to be and with so many code bases using 2-space indentation, I wonder why this isn’t configurable as I have a lot of difficulty discerning the contrast when it’s so shallow.
Just because most users don't think about it doesn't mean it doesn't impact them and that they should be ignored. The very fact that they can't fight for the solution that best benefits them means the onus is on us as designers and programmers to do that for them, instead of handwaving their needs away.
Considering the trend now is to straight up remove scroll bars (why the fuck...), I expect conversations like this will become moot in the not so distant future.
Or to phrase it a different way: Being able to style and control the width of the scrollbar is so incredibly useful that it must be in the hands of users, and not designers.
I would go even further: websites should not be the ultimate decider on any style-related decision. Including colors, font faces, text size, margins, padding, content width, and any other UI elements. Website should be able to suggest these things, but browsers should default to the user’s preference or the system’s configuration. The user should have the final say on how the User Agent displays HTML content.
Browsers have ceded far too much control over these things to websites, to the point where we are even debating whether they should style such fundamental OS controls as scroll bars!
It's relatively easy to force your custom stylesheets to any website. Whether it will work at all is another question.
I believe what you suggest could work only with semantic HTML without any advanced styling - no floating elements, no flexbox/grid, no absolute/relative positioning etc. This then means return to static text based websites which is fine for many use cases, but not for all.
Ideally, rich web apps which actually need all the CSS/APIs could use them, while the text-based sites would keep custom styling/JS to minimum (which would allow reasonable user-defined styling). But it's impossible to force this dichotomy in practice.
Overriding all css is so popular a concept that no Firefox plugin to do that has more than 100k downloads (and firefox users are probably the most likely to fidget with things like that).
A radical idea - people should be able to create whatever they want in whatever colours and fonts they want and have it shown to viewers the way they want, at least unless the viewer explicitly objects.
They can make custom ones when a native one doesn't exist.
There's literally no reason to write your own implementation of a drop-down menu. Zero. None.
And yet, I occasionally run into a site where I need to enter my mailing address, and they have a drop-down menu to choose my state. In a native component, I can just tab to it, type "or", and Oregon (or OR if they're using the abbreviation) will be chosen, and I can just tab on to the next input field.
But every now and then, I find myself on a form where that doesn't work. It turns out, what looks like a drop-down menu is actually a fancy div, and when you click on it, another div pops up with divs for each item. Oh, but I can't even use my keyboard to choose an option! I HAVE to click!
WHY DO WEB DEVS DO THIS!? What was gained by this? Someone spent time to reimplement something for absolutely zero gain, and a LOT of loss! WHY!?
And my complaints don't even begin to address how the custom solution is probably awful for accessibility.
You don't need to make a custom button.
You don't need a custom date picker.
I'm struggling to think what custom components you think need to be made.
My best guess is that these abominations are made in order to adhere to some pre-made design that specified all the visual aspects without regard for the existing technology. If somebody gives you an export of a design made in Photoshop and says that you need to match it pixel for pixel, that design might not be readily implementable. Depending on the approvals needed, or the cost of hiring external designers, asking them to revisit the design in order to match the tech stack might be politically infeasible.
So instead of design being the intersection of form and function, design becomes entirely detached from the function.
Lets say a date picker was not supported in html, I'd at least prefer they made one aggregating native buttons instead of from scratch with colored divs/whatever.
> being able to style and control the width of the scrollbar is useful.
Useful for who? I set my scrollbar width fairly wide intentionally so I can actually click on the thing and use it without too much effort. Some developers thing it's "useful" if I'm not able to do that by setting a significantly smaller width, which is not useful at all for me because every single time it makes the experience worse.
In some fairness, the fault is also with Firefox and Chrome for not being able to just say "never style scrollbars" like you could with Opera in 2000. Sigh...
For control-freaks who think they are the second coming of WinAmp and like to micromanage every single aspect of user experience so that it conform to THE BRAND®™.
> I hate articles like this because they present highly opinionated solutions as something definite
The first paragraph says "I feel this is a mistake". The author is very clearly expressing an opinion, not a fact. They go on to attempt to justify their opinion. I feel like you're railing against something that... isn't really happening here.
I will grant you that there are some very narrowly-defined situations where styling a scrollbar is useful and actually gives a better experience. But in general, leave them alone. They are browser chrome, and should not be touched by webpages themselves.
I don't want to sound to harsh, but my desktop environment and I know how we want our scrollbars to be and why. Web designers from thousands miles away do not.
Furthermore having the need to style scrollbars to make a UX work smells of bad UX design. Given a full screen page, is there really no space for the standard OS scrollbar (or my custom one,) which users see all day long every day they use their computer? Is the OS's UX really so bad that must be improved by a web app? It's wasted designer and developer time.
> I hate articles like this because they present highly opinionated solutions as something definite even though it has a narrow focus on what the author cares about.
Whatever the author says about custom scrollbars isn't going to stop CSS-Tricks from styling their scrollbar. The article is perfectly fine because programmers are free to ignore it, and if this article convinces even one programmer to switch from a custom scrollbar to a non-customized scrollbar it's likely they never needed it anyway.
There should be simple OS level overrides on CSS. Not a user stylesheets or extensions or hard to find a browser flag, just a preferences window where even my mother could indicate “always show scrollbars in Windows style” or “all text should be at minimum 14 points”.
I don't understand why people keep bringing up the OS in this discussion. The OS doesn't have anythign to do with the look and feel of a web page, it's the browser that decides on a default look. And even for native apps, there is no "OS look and feel" - at least not on Linux or Windows. A Win32 button doesn't look exactly like a XAML button not like an MFC button, and definitely not like a UWP button. A Gnome button doesn't look like an XFce button, nor like a Plasma button.
Also, people like it this way! The OS is just a dumb layer that my hardware vendor is forcing on me. I care much more that Word works the same when I switch from a Dell laptop to an Apple one than some OS preference.
So to be sure, you’d like your Word on Mac to also have a “close window” button as a square “X” on the top right instead of a red circle on the top left?
OS’s are not always 100% internally consistent but every OS vendor is striving towards that.
Finally I agree that the OS should not natively style a web page (although as I said I’m in favor of user overrides). A scroll bar is not a web page. It’s an OS level interface element.
Well, probably not, though even that is debatable (think of the game example). Still, I think the window control elements are pretty close to something the OS should fully control.
On the other hand, I would expect it to use the Ribbon for interaction, and mostly ignore the MacOS global menu bar, so I can still find things where I'm used to them.
Having said all that, scrollbars appear all the time inside other elements of an app, so I don't see why they should be compared to the window close button. If they're smack dab in the middle of my screen, they should look like the rest of the app.
Actually at first, as I'm using my phone, I must say that Codepen mobile UX is great. There are three buttons on top that act as tabs. There are no visible scrollbars on phones, there are no visible scrollbars in Codepen. They either programmed that or conformed to the OS, the result is OK.
I switched to desktop mode to get the HTML and result views side by side. I have to horizontally scroll the page but that's to be expected on a narrow screen. There is no visible scrollbar but again, that could be because of the mobile OS. If I were on my laptop with a full screen window I wouldn't mind to have an always visible OS scrollbar at the right of the HTML editor. It's in the middle of the screen but I've got OS scrollbars in the middle of the screen any time I place an editor window to the left of my screen, so what's the problem?
Alright, I guess I'll go back to using js scrollbars instead /s
I hate articles like this because they present highly opinionated solutions as something definite even though it has a narrow focus on what the author cares about.
Web apps can be incredibly powerful and convenient, sometimes a scrollbar is in the middle of the page like with that codepen. In those situations, being able to style and control the width of the scrollbar is useful.
How about we hold developers accountable for their work instead of trying to ruin it for the rest of us because a minority do something badly.