On the contrary, we should be encouraging people to customize scrollbars so that scrolling is taken into consideration again. It can help get rid of trends like invisible/hidden scrollbars or those useless horizontal progress bars that shows how far into a page you've read
There's been an ongoing trend in UI design in recent years to assume more and more of the user.
The removal of scrollbars from browsers confused my parents. Instead of having up and down arrows by your content now you're just expected to just know that you scroll with your mouse / trackpad. Similarly, modern versions of Windows will just assume you know that the four squares at the bottom of your screen is where you need to click to start using your computer, and Mac will just assume you know the red dot closes the current window. These patterns probably seem obvious to us as power users, but I find average users get endlessly confused by them.
And it's not just elderly people who get tripped up by this. I've seen kids who have primarily used phones and tablets growing up get confused when they first use a desktop computer because they haven't yet learnt all the required prerequisite UI patterns. Even as a power user if you switch from Windows to Mac (or vice versa) it often takes some time just figure out all of the completely unintuitive modern UI because the UI designer is lazily assuming you already know how to do everything...
Just yesterday my girlfriend (who uses her computer almost every day) asked me for help replying to an email in outlook on her laptop. Confused I asked, "what do you mean you need help replying to an email?". Well, she was confused because she doesn't use outlook much and didn't know she needed to click the small curved arrow icon to reply to an email. For the last 5 minutes she had been stupidly looking for a button that said "reply".
While I completely agree with your sentiment about scroll bars, I feel like this a much bigger issue and one that web developers shouldn't be required to fix. The core issue here is that your OS / browser shouldn't be hiding your scrollbar to begin with... This isn't something web developers should be addressing, but the UI designers who think it's preferable for me to have a browser URL bar that is 80% of my screen width at the expense of the word "back" on my back button.
> These patterns probably seem obvious to us as power users, but I find average users get endlessly confused by them.
They're obvious to power users because we have seen them a million times before.
When a web developer does a custom scroll bar that is when "average" users get confused, because suddenly they're presented with something they haven't seen.
It's not too much to expect a user to know how scrolling works by default in their client operating system/browser. It _is_ asking too much to expect users to know how scrolling works when you customise how it works. Web developers should not be touching this stuff.
> And it's not just elderly people who get tripped up by this. I've seen kids who have primarily used phones and tablets growing up get confused when they first use a desktop computer
It goes the other way as well lol. There's lots of ridiculous random gestures for android/iOS
In general it feels like a lot of UI design these days is optimizing for looking pretty in screenshots and photos rather than being useful as a tool, it's honestly gotten really frustrating in recent years.
A month or so ago, a screenshot of Snow-Leopad-era OS X standard UI controls made the rounds on the fediverse. One forgets so fast with incremental change, but when you take it in with some distance, it’s truly devastating how things have regressed since that time.
The Apple folk and adjacent circles like to throw around how “design is how it works™”, but design hasn’t been how it works in Macos for a while (and it’s not better anywhere else).
The worst pattern I've seen is setting the page height to the viewport height and then placing scrollbars on containers. For example this particular UI library has managed to break print layout and page navigation keys and mouse scrolling until you focus the content div
https://www.skeleton.dev/docs/get-started
I was once guilty of doing this on a site I made but the users called it out so I fixed it. It's another thing for a UI library to spread this pattern.
Oh the pain of printing any modern news site with their fixed headers and popping ads. You just select the text and "R-CLK->Print selected" praying that at least the content is just a list of paragraphs (<p>) and nothing more...
I usually go into the inspector, find the element that contains the story and "screenshot node." Or I go the opposite way and "block elements" with ublock until I get a reasonable page, then delete all of those rules after I print. Unless they have a print stylesheet, of course. People still do those.
Fixed headers and popups that are not a problem per se but it's bad implementations that cause the problems. It's possible to use a print stylesheet to hide certain elements and set the background to white.
Wouldn’t this look completely off with a massive light mode default Chromium scroll bar in the middle of everything? When I was developing that my main goal was to get the UI looking consistent and clean so it would feel good to use, which I think is an underappreciated thing; if your UI doesn’t “feel right” then people won’t enjoy using it no matter how functional it is
To be fair it probably does have contrast issues which I could improve
Note: it’s an Electron app so maybe that’s different
TIL. This actually solves my main need for custom scrollbars.
Now the only remaining use case is when designers don't design components around default scrollbars. Sometimes the default one just looks too big compared to the size of the component. But this can be solved with design (don't cram stuff into small fixed boxes that then need to be scrollable).
That would help, it wouldn’t look quite right though.
What’s the difference between styling a scroll bar and, say, a button in an application like this? If you want everything to look how the user prefers and fit into the OS then you shouldn’t really style anything at all
> Wouldn’t this look completely off with a massive light mode default Chromium scroll bar in the middle of everything?
Yes, which is why that design is wrong. Respect @media(prefers-color-scheme). Forcing a light or dark background causes readability issues for some people.
Since Electron can be considered the browser chrome itself, the developer can access to its lower level API to customize those things. You can also set the dark mode in CSS.
The thing is that the looks of scrollbars vary so much between platforms - on mobile you can barely see them only when you do the action of scrolling! So it would be rather weird that, if you are seeing a website in mobile and you just put a scrollbar because reasons, you're quitting some horizontal/vertical space to the effective area of the website.
And note that the act of scrolling is much more related to the OS host rather than something the website itself should provide (now, if there was an standard way across every device to scroll to the very top or the very bottom of a view (webpage, list, etcetera...). I am a designer myself but I agree than we should not mess with them. And the plus that it's a bit less of work for us (and devs, when they have to implement those things).
It’s an Electron app for me so it’s only going to be on Chromium on desktop
But if scroll bars can be themed with CSS now, that should still give the browser control over things like whether they take up space or not and the actual scrolling behaviour, right? It would just allow the developer to give some styling hints so it doesn’t look completely disconnected from the rest of the page
But it will look disconnected from every other app on the user's system.
Whatever style the user currently has installed on their system, if the scrollbars on your app look the same as all the other scrollbars they ever use, they'll recognise them instantly and know how to use them instantly, with zero additional cognitive load.
You users might be using enough of their brain to figure out your app (maybe because they're also being partially distracted by their boss/child/phone/pet/music) already, don't make them spend time thinking about your gorram scrollbar as well.
This is actually why I have been resisting the new tweetdeck experience. (That and the activity feature being removed). The scrollbars are so bad on Windows. The screenshots I have seen from mac look nice enough, but windows scrollbars were never meant to be in the middle of the webpage 6 times.
On pages, I fully agree. Within components, I also agree but I've found it hard to push back when a design calls for scrollbars because the alternative is... what?
It can be difficult to visually say "Hey, you! There's more to see if you scroll down in this area" You can try to use gradients with fade-outs, you can try to make it so the top of the last item in a scroll area is just visible enough to make it clear something can be scrolled into view. I've also seen actual text-based messages at the bottom of scroll areas to let users know. But at that point, is it really better than creating your own little scroll bar?
Really I think we just need better APIs from the browsers to customize when a scroll bar is shown (again, not on the page level but within scrollable elements), and what it looks like. This has already gotten much better over the years but there are still some features that would be great to have in this area.
One thing I will say is I really dislike the smooth-scrolling behavior that some sites build in with JS. It's usually broken on macs that already have smooth scrolling and it's just a dumb thing to add.
> One thing I will say is I really dislike the smooth-scrolling behavior that some sites build in with JS. It's usually broken on macs that already have smooth scrolling and it's just a dumb thing to add.
I'm fairly sure every platform uses smooth scrolling by default, and so I'm absolutely and utterly baffled as to why web devs think they need to implement it in JavaScript.
If you're on a platform without it, or you've explicitly disabled it, there's probably a good reason for it, so re-adding it with JavaScript is taking away agency from the user.
> Within components, I also agree but I've found it hard to push back when a design calls for scrollbars because the alternative is... what?
Accessibility. Mention that blind users will be unable to utilize the site without a lot of additional work and you can usually kill it dead.
Custom scrollbars are such a niche thing that usually nobody is married to the idea - I've found it quite easy in the past to kill off those sorts of weird quirks in design with just that word... If you still have issues mention that mobile browsers often do a lot of customization around bounce scrolling and the like. Building this design choice out now likely means that whenever Apple releases a new phone it's quite possible that your site look antiquated and requires some major reworks.
No need I can tell you the answer: No they are not affected. Feel free to make your scrollbars blue green with a red border and rounded edges. The content is still as accessible
Say your app is satirizing flashy magazines with a funky magenta-and-yellow color theme. Would you like a gray scrollbar in the middle of the page? Or, if your app is a medieval role playing game with a wooden theme for the UI, would you expect flat gray scrollbars to work well?
> Really I think we just need better APIs from the browsers to customize when a scroll bar is shown (again, not on the page level but within scrollable elements)
What do you have in mind beyond "always show", "show if needed", and "always hide"? Those have all existed for decades as "overflow: scroll", "overflow: auto", and "overflow: hidden".
There is somebody on another thread asking for "stick to the visible margin of the element". But I guess most people want to change the scrolling behavior or appearance.
this post could have been way less that a million lines long. maybe if it had a nice colored scrollbar it would be more pleasant to read.
kidding aside, it is longer that it could be, to get the point across. maybe the browser just needs a similar setting to the macos and windows one, to never use css on scrollbar, and we're good?
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?
> 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.
> 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.
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.
> 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.
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.
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.
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!
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.
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.
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.
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.
> 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.
> 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.
> 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®™.
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.
> 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.
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?
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.
One of my very first blog posts[1], which took off at the time on HN[2] was on this topic - in reaction to the trend of "horizontal page progress bars" (a.k.a. scroll bars!)
What's old is new again... and again... and again... :)
> Scrollbars are part of the area of the browser that is outside your scope of concern.
No, they're actually in my scope of concern, that is the whole point of your article. The reason they were brought into my scope of concern is that a lot of people had a use case for styling custom scrollbars. I have a use case for it myself. If you're saying "don't abuse your ability as a developer and make inacessible websites" then yeah, okay. But taking options away from people because they might theoretically make bad moves with them is not a good strategy. If you took away every CSS attribute I could use to make inaccessible websites, we wouldn't have anything left. You'd be surprised what I can mess up. Better to teach people how to do it right and why.
Taking all the flexibility away would be fantastic. I wish all webapps looked as close as possible to native apps, and couldn't style things like buttons.
This is a meaningless statement, because even native apps don't "look like" native apps. No operating system has a universal style across all native apps, and some (Windows) aren't even internally consistent with the OS's apps.
> no operating system has a universal style across all native apps
Imo, an app that isn’t using Cocoa (or carbon for older apps) widgets on macOS isn’t “native”. If you just use the default widget set on macOS, your app will have a consistent style with every other native app. If you use Qt, Swing, Electron, etc., your app will look out of place and break in ways that annoy at least some of your users.
there's more than twenty years of examples of macOS apps using Cocoa and Carbon and being inconsistent with the rest of the OS, iTunes being the most egregious
So that's an excuse to make things even more inconsistent?
I get your point, though; I'm a Linux desktop user, and have to contend with apps written using a variety of UI framework. For that reason, I tend to try to stick with GTK apps, as I prefer consistency. I have Qt set up to use/emulate GTK's theming as close as possible. No, it's not perfect, but most things on my desktop look pretty consistent.
Except webapps, of course! They break everything when it comes to consistency. I wish that wasn't the case.
I've never met a styled scrollbar that was better than those native to my OS, and that includes the ones imposed by any app, not just web apps. Even Edge is guilty.
On the contrary, I'm completely in favor of custom CSS scrollbars because it's unimaginable that websites could do worse than modern OSes already do when it comes to scrollbars. If anyone here has a time machine, immediately after you've finished killing Hitler may I recommend that you gently persuade Jony Ive away from the terrible decision to make scrollbars hidden, low contrast, and impossibly thin.
Personally, I like the Apple ones. I’m partially sighted, so I should probably want the stronger visual design, but I don’t.
What I prefer is consistency with the OS. My OS is my main tool for interacting with the digital realm. My life would be easier if the conventions were more evenly applied. Custom scrollbars concern me that my OS defaults are being overriden: will the field scroll at the expected speed; can I flick it and catch it as I’m used to; is the scale expressive of content size?
Custom scrollbars tell me that the developer doesn’t care about me, they care more about their brand manager and their pay check. This suggests the product they represent wont suit me.
Along with intrusive pop-ups, subscription overlays, and “we value your privacy”, it’s a clear sign I should not engage with that provder.
There was a quick starburst trend around 2010 where super-fancy css componentry was being heavily explored & all sorts of interesting but not necessarily better stuff was being done, with radical redesigns. My mini-project submission for a job I got was using a super melted Geiger esque up-down button set.
I've tried to go back & find evidence of this era, to find more examples of these heavily glitzed up components. And wow, so much of this has disappeared entirely off the net. Maybe I'm lacking the right keywords. But this feels like a mega flash in the pan that came & went super fast.
Indeed, I was just about to comment on the linked page overstyling fonts and colors while suggesting to avoid overstyling other elements. The title can be clipped to "Don't use custom CSS" while reusing the same justifications.
>> Apple learned the lesson about visible scrollbars the hard way when it introduced its ultra-minimal, disappearing scrollbar indicators.
>> There’s no visual indication that there’s more content present in this window—the only way to discover it is to scroll downwards. However, without an affordance to indicate the presence of additional offscreen content, the chances are low that someone will bother to check.
I appreciate the callout that Apple is an infringer on removing the scrollbars, which is a bad UI practice. For the entire lifespan of the web, overflow content indicators have been (aka scrollbars), for better or worse, an inherent function of the browser.
Moreover, Google said they did a study when they first released their minimalist homepage design and when people saw lots of white space below the search bar, they assumed the page wasn't finished loading yet and more content was to come.
People were accustomed to long pages like Yahoo's homepage with lots of content below the search bar.
They solved it by adding a footer section with typical copyright text and people understood that the page was finished loading.
The awesome thing is that this comes right after an example that uses about 200 characters...
I know we love to talk about optimizing web contents, but a single selector and a few hundred bytes (before minification and compression...) is not significant
What would be nice would be some sort of solemn undertaking that the presence or absence of a browser scrollbar will never alter the placement of the content.
I recognize that web developers want full control over the user experience, usually to the point of reimplementing all of the native UI widgets provided by the user’s OS.
As a user, I prefer for my OS to do things my OS does, including styling my widgets. My scrollbars, my scrolling behavior, window chrome, all of it… whether it’s good or bad or right or wrong, that’s between me and my OS.
As a user, I hate when web apps mess with scrolling. It breaks affordances I use, like tapping at the top of the screen to jump to the top of the page, or home/end keys on desktop. It is inevitably a worse experience than native scrolling, no matter how hard you try. Facebook mobile web for example is basically unusable right now because it’s trying to overthink scrolling. If Facebook can’t get it right, I’m not sure what makes anyone else think they can.
And why would anyone want to? Honestly! Microsoft and Apple have already done all that work.
As for scroll bars and other widgets, again, right or wrong, that’s not for some web site to mess with. Sorry if the developer doesn’t like the way it looks… they only have to deal with it while working on it. As a user, I am stuck with the developer’s choices, even if they override my own choices, which I’ve made in my OS, which is where those choices belong.
If you’re going to clobber native experience, I would argue, don’t do it unless there is absolutely no other option. Corollary: there is always another option.
YouTube's custom scrollbars that take actual space on screen at all times annoyed me so much that I made a userscript that got rid of them. I made the choice to use overlay scrollbars, and I will enforce it if needed.
On macOS, when you use Apple input devices, the scrollbars work like on iOS and Android. They appear on top of the scrollable content when you start scrolling and disappear shortly after you stop. You can make them visible all the time, but then they will take up space like they do in e.g. Windows.
Absolutely! I know there are designers out there, obsessing over every last detail. But I want an easy to navigate, consistent experience. I don't want to wave the mouse around hoping to find the easter-egg that is a link. Or the almost (or actually) invisible scroll bar. Or the "button" that looks just like text. There is an existing, consistent, simple look - divert from that and you're at risk of my going elsewhere because you've ignored the #1 reason to be a web page ... I don't use it because it looks great, I go there to do something, and do it easily.
I get the argument that fully custom scroll bars aren’t great for accessibility in many cases. However, the default behavior out of the browser or OS is pretty terrible in many cases as well.
Scroll bars popping in and out of existence awkwardly reflowing elements around it. Tiny unusable 30px wide horizontal scroll bars inside an input element because an element overflows 0.7px due to font size rounding issues or what not.
Default scroll bars are great for documents, but pretty terrible mostly for slightly more complicated UIs where a lot of info is displayed in small area.
I recently discovered to my dismay that Firefox uses Windows 11's setting for whether to hide the scroll bar. And it's hidden by default. Though FF is happy to hide them by default on its own anyway. I can't imagine how this is a good thing for end users for whom computers are already unpredictable and difficult to understand. Modern UX is a nightmare.
First of all, the OS does not style widgets, the browser does. And scrollbars are completely different in different browsers - they have different sizes, different behavior, different look-and-feels. So either you create versions of your app which match each browser individually, or you re-style the scrollbars to look the same as the rest of the app.
Thirdly, there is an obvious counter to your arguments that shows that one-size-fits-all design is not actually what users always want: games. You wouldn't expect a game to use the system look-and-feel, it rightfully uses a look-and-feel that matches the game itself.
And we can extend this observation further out: if your app is self-contained enough, and you have a distinctive enough style that your users like, then you should re-style everything away from the OS style to your specific unique look.
Should every app do this? Absolutely not. But is there no case outside gaming where an app should? Of course not.
Perhaps, but MacOS and iOS are not the only OSs out there. Also, full screen iOS games have full control of the screen and I/O, and can choose to draw anything they want and implement any interaction they want, they don't have to rely on the system to draw widgets for them.
I believe the point is that if you're unhappy with the default scrollbar, you should get rid of it altogether rather than torture it into doing something it's not meant to do.
Having done e.g. an endless scroll application, the scrollbar was unfit for our use, no matter what we did. The right solution was to remove scrollbar and implement our own scrolling mechanism.
Which is straight up what jmbwell was complaining about, as it breaks their workflow such as tapping on the top to scroll to the beginning and everything else they mentioned.
It breaks more often than it doesn’t. Yes, the page “scrolls”, but it scrolls only a few pixels, while the internal “custom” scrolling implementation doesn’t respond to the event and does not scroll to top, resulting in a terrible UX.
When you scroll on reddit, there is a beginning and no end.
Some applications have neither a beginning nor an end, so scrolling to the beginning makes no sense. At best, you could make "scroll to the beginning" get back to the start of your navigation, but then your scrollbar wouldn't let you go further.
(also if you have both horizontal and vertical scrolling, you're still left with no horizontal options)
There is no beginning in the thing I was talking about. Which is why removing the scrollbar and breaking people's expectations in a way they can see/understand was better than trying to repurpose the scrollbar.
The GP was specifically complaining about apps not respecting their scrollbar choices. They said that apps should defer all scrolling UX to the OS, as that is what the user chose.
> And scrollbars are completely different in different browsers - they have different sizes, different behavior, different look-and-feels.
Yes, and? No matter what it is, it's what the users of said platform are used to. Is there really a benefit to forcing users to re-learn such a critical component?
> You wouldn't expect a game to use the system look-and-feel, it rightfully uses a look-and-feel that matches the game itself.
1. Not everything is a game.
2. Depending on the game, system look&feel can be perfectly fine: SimCity 2000, Aurora, the Rule the Waves series, and probably loads of other simulation games all use it, because their art style doesn't require to re-invent the wheel poorly.
3. Games whose art style do need custom look&feel will most likely be using a fullscreen canvas/WebG(L|PU) widget anyway and will be able to use it regardless of CSS support of the feature.
My point was that a general "no app shall customize scrollbar look and feel" is wrong, as there are certain kinds of apps that do benefit from custom look and feel. Sure, not all games, but also games are not so entirely different from other kinds of apps.
Also, I thought the specific points about CSS and how to achieve custom styling if desired are irrelevant. The arguments I was replying to were about UX, not about details of how that is implemented.
It's very hard to actually write good UX from scratch, particularly stuff like scrollbars that require all sorts of relative resizing, drag listeners, velocity methods, second and tertiary controls (keyboards, drag-selection of text) and often need to handle those things after a variety of user interactions without redrawing their content or slowing anything down by constantly remeasuring the rest of the UI.
Because it's difficult, it's often done poorly, which leads to people thinking it should never be done at all.
To your point about games, I find most custom-written scrollboxes in games to be pretty terrible, but we all kind of appreciate them just for their uniqueness, because as UX items they're generally not something you interact with that much. (Unless you're playing Crusader Kings, in which case ... )
I remember being disgusted and offended by Apple's app developer rules two decades ago, which included dictates such as never implementing your own UX elements like scrollbars. We're still debating whether they were wrong. As long as there are bad ways to build UX elements, some people will do them, and this will serve as proof for a few big companies that it should never be done.
I think in games reimplementing controls is done because of game engines having their own gaming-specific widgets or parts, which are not using the system's widgets themselves. Game creators will make use of the things available in the game engines.
Well like e.g. when I had to write UI elements into first iterations of Star Citizen, those were all in a 2D vector/sprite layer over the 3D world that had to be completely custom coded. Even the shape of the UI was pretty much completely open to interpretation. I have mad respect for people who write their own UI elements and "widgets" into games, given the restrictions that are often involved. Some do it better than others, but therein lies the art of observing and stealing from the best.
You don't have to write good UX from scratch to get non-OS scrollbars, there are CSS rules that let you style scrollbars while keeping most system scrollbar features and accessibility.
No comment on whether or not that's a good idea, though.
> My point was that a general "no app shall customize scrollbar look and feel" is wrong, as there are certain kinds of apps that do benefit from custom look and feel. Sure, not all games, but also games are not so entirely different from other kinds of apps.
But the point is, that your website is not an app. At most it is a web app, and therefore governed by the browser and the user's preferences and choices for the browser.
A website (or website that is a "web app") should fundamentally be a different degree of commitment than installing an application into the user's system. There is a reason for browser sandboxes and for the browser to have its configuration. The browser itself is the actual app and the user should be in control of that, to govern a at least partially unified UX throughout the websites the user visits.
A website should fundamentally be a different degree of commitment than installing an application into the user's system
I agree with that, but this is opinion and not fact. There's a lot of money invested in blurring/obviating this distinction, exactly because installing a real app has more hurdles (both for the developer and for the user).
I don't see why there should be any distinction between apps and web apps in terms of UX constraints, and I don't think one has ever existed even since the invention of the Web. After all, Flash is older than JS and much of what people loved on the earlier Web was in fact made with Flash. Similarly, many famous Geocities sites were heavily customized to illustrate their creators' preference.
The web is much more than productivity focused software, and limiting it to some specific notion of dull uniformity in the names of consistency is honestly sad.
If I want to create a site to represent a detailed exploration and appreciation of the Voynich manuscript, why should I not try to style similarly to the original manuscript? Why should utility trump aesthetics for nay document on the web?
The real problem, in my opinion, is that too many websites do this sort of thing. Is there a place for it? Sure. But it should be something that is rarely done.
But I'm only talking about websites, not web apps. I don't use web apps, so have no opinion on them.
> First of all, the OS does not style widgets, the browser does.
This goes beyond scrollbars. There are hundreds (thousands?) of libraries or entire frameworks to build consistent dropdowns. Even more to create date-pickers and to replace alert dialogs, add modals, and whatnot.
This shows that the browsers don't do a good job offering nice and neat UX on them. Same for scrollbars. Browsers offer native dropdowns (that more-or-less match your OS - depending on browser and OS), datepickers (that at least match your locale) and even native alert dialogs. And many are ugly as hell, have a terrible UX or integrate very poorly. IMO fair points. And often even reasons to replace the native widgets with tons of JS, CSS and dom manipulation. Edit: though I don't think this is the case for scrollbars, I think browsers do a good enough job there.
The one reason that I very much disagree with, it cross-browser or cross-platform consistency. No-one cares that widgets on your website or -app are the same on chrome/windows, icebeaver/weirdlinux and safari/OSX. Because no-one other than the webdeveloper and -designer will ever use them on all those platforms and expect everything to look the same on all these platforms.
> And scrollbars are completely different in different browsers - they have different sizes, different behavior, different look-and-feels. So either you create versions of your app which match each browser individually, or you re-style the scrollbars to look the same as the rest of the app.
Find me a user that sez "This experience sucks...that's the native scrollbar" and I'll give you $100. If you give me $1 for every user who is fine with the native experience they are most comfortable with. If you give me $1000 for every time a custom scrollbar isn't accessible.
Fwiw, I've never visited a site with a custom scrollbar that didn't have other UI / UX issues. The fancy scrollbar didn't makeup for those.
p.s. Gaming is a different aesthetic, a different audience, etc. It's not what should be the user-centric internet.
> p.s. Gaming is a different aesthetic, a different audience, etc. It's not what should be the user-centric internet.
I don't think that games are an entirely different world from web apps. There is some amount of gradation between pure document-like pages at one extreme and games at the other, and a whole spectrum in between (say, an app like Google Earth probably doesn't need regular scroll bars to implement most of its scrolling behavior, while not being a game).
Also, I think users are quite observant of color clashes, and will notice if you have system-styled scroll bars in the middle of a web page that is styled in a specific way. I don't even understand how this is a controversial opinion - especially when we have things like dark mode that was available in numerous apps long before any OS or browser supported it natively - thus requiring the app to re-style all controls.
The "But games don't standardize the UI" is actually a worse argument than it appears on the surface. Since every game is re-inventing the wheel, they're all making inferior wheels. UX/accessibility is so far behind OS/web in full screen games that I'm impressed that disabled people can even play most games at all. It's not uncommon to boot up a brand new game in 2023 that has the menu design and UX consideration of a late 90s website.
I don't think most games would become compatible with a screen reader if their inventory system had a better scroll bar. You are right that game UIs tend to be well behind some common OS elements in terms of accessibility, and even low hanging fruit are sometimes missing, but it is also the case that many (most?) games are fundamentally incompatible with many disabilities and as such improvements in certain specific UX areas are low value. Doesn't excuse the fact that they should do better where it's possible, though.
The difference is that games are a deliberate exercise in non-productivity. You are generally not trying to 'get something done' in a game except what the game itself is asking you to do.
When using a webpage, you generally are trying to 'get something done'.
Besides, games implementing their own widgets can be terrible for accessibility.
The majority of game menus are there to help you get something done. With some exceptions, games are not played inside their menus, and have the same kinds of UX concerns as any regular app.
The main difference between games and many other apps is that games are trying to sell you a fantasy, and look and feel are much more important to keeping you in the right mindset than in some other apps. But there are other apps and even web pages with similar goals which don't quite qualify as games.
>> Microsoft and Apple have already done all that work.
eg. Dark Mode - wasn't created by Browser or OS providers, but developers (as I understand), then OS/Browsers played catch-up. Developers can and sometimes do influence Design "upstream".
The thing that I really don't get is that these designers must be users too. Would they be happy to use what they create? One assumes the answer would be yes, but I'm not sure.
> As a user, I hate when web apps mess with scrolling.
To be clear, this articles talks about styling only.
Tbh, if you like native features of scrollbars, widgets, etc., the most practical way you'll get to keep them in 2023 will be if they can be custom styled.
I have an application that looks terrible if I don't make the scrollbar transparent.
I thought this was going to be about not using those horrible javascript scrollbar libraries, which make the code a lot more complex (I tried them all).
There's a chat on the left side, right side shows media. If I allow scrollbars to render normally the whole site is split in 2, in the middle being a scrollbar, which looks bad especially if not overlay. I've considered not caring about it and just let the scrollbar, but it bothers me. It's my application anyway, the browser is not just a document reader anymore, it's an application framework (as well).
> If I allow scrollbars to render normally the whole site is split in 2, in the middle being a scrollbar, which looks bad especially if not overlay
Well that's your opinion. But I would rather see a scrollbar in the middle to show me that I can actually scroll something. Otherwise it's a hidden feature and hidden features are not features, they're bugs.
Also don't use buttons that don't show me the link I'm navigating to. If you must have a different style, style them around an `a href`, not a `button`.
And actions should be buttons, not links. I'm looking at all of those cookie websites with a 'link' that says 'Confirm choices' and a button that says 'Allow all'. Instinctively we go to the button, not the link.
Weirdly enough I responded on the Image send to Microsoft via MS Edge article about how even Microsoft, the writer of LOTS of documentation on how to make good UIs, abuses all these things.
Now, of course we could argue about how these things just visuals, but that's not completely true. Lots of screen readers depend on the semantics of the document structure to actually identify objects correctly. Button? Action, edit, sign up, delete, .... Something that actually changes something.
No, they don't.
Aria roles are not for making one tag to work like another. (Otherwise what is the point of having different tags with different semantics?).
Aria is for making inaccessible html more accessible.
Links can not be disabled (buttons can) - so they dont rely on js to work;
Buttons rely on js (except for submitting the form).
There is no way to interchange one with another without sacrificing usability.
Scrollbars are frustrating to handle. Getting their actual size if you need to do stuff like compensate for a virtual table is really tedious. And Macs do them entirely different from everyone else, so that’s not nice either.
Several billion people understand and make good use of the standard HTML scroll bars.
For any change, on the first day, only the programmer understands the new scroll bars.
For an Internet user who each month or so goes to dozens, maybe hundreds, of Web sites, all the new scroll bars are something new to learn likely particular to that site. So, for that user, a significant part of the Internet becomes dozens or even hundreds of times harder to use.
Same for standard HTML push buttons, links, check boxes, radio buttons, multi-line text boxes, single line text boxes (and the ones for passwords), etc.
Changes make the site obscure and significantly more work to use.
Web site owners: When I see a Web page with an obscure user interface, commonly I just do a single left click on the X in the upper right corner of the Web browser instance displaying that page.
Beyond an obscure user interface, often I can conclude that the Web site does not want me to see the content on their Web pages because they cover up the content with pop-up windows or expand and contract some header material at the top of the page, material that wastes limited vertical space on my screen.
Another problem is Web pages that follow my mouse pointer and respond to its position without my giving a click. Big interruption in using the site. Nearly always I'm just trying to bring the window to the top of the Z-order so, instead, have to swat like a dozen flying insects the various responses to the mouse click -- again, I do want to see the page and just want to bring it to the top of the Z-order.
Then there is Web site code making the window larger -- again it's like swatting flying insects. No, no, 1000 times no, with rare exceptions, I do NOT want any one page to hog my screen area. The reason is fundamental: In visiting the page, I'm trying to get something DONE, and that requires seeing at least two windows, maybe a few more than two. When one program takes up all or too much of the screen area, I can't see the other windows I need and, thus, can't get the work done.
There is an old remark that goes something like "Just because you could doesn't mean you should."-
> Same for standard HTML push buttons, links, check boxes
Interesting that you mention checkboxes. For a long time native checkboxes on Linux (distro?) would come up impossibly tiny if you had a decent-sized screen. They were hard to hit accurately with a mouse, and impossible with a trackpad. That seems to have been cured now, but I don't know when it was fixed.
> When you style things on the web, you get control over almost the entire experience. From ten thousand feet up, your scope of concern is this:
The mockup scrollbar looks nothing like scrollbars are now.
> Do you need to make someone download that extra data?
>
> Spoilers: you don’t. Scrollbars work without CSS.
No, they don't, because web browsers have been busy removing scrollbars as much as possible. As I type this, there is no scrollbar on my screen because Firefox no longer does that. For a moment, I thought maybe FF still showed at least 1 pixel of the scrollbar, but I scraped it off with my fingernail and it turned out to be a cat hair. The scrollbar appears only for like a second before 'helpfully' fading out, and is a few pixels wide (on a 4k portrait monitor where I'm not exactly hurting for space). Chromium still has a semi-reasonable scrollbar, but I can't vouch for the official Google Chrome. Safari and Mac OS/iOS have, of course, been years ahead of everyone else in the wonderful pro-user innovation of 'hiding scrollbars and making them a pixel wide if absolutely forced to display one'.
> ...This is why Apple introduced a preference to always show scroll bars...Windows followed this path blazed by Apple
Yes, a preference to go back to the old standard behavior, which in designer-speak means "we done f-ked up, but we hate real users and love the sleek minimalist appearance https://asktog.com/atc/the-third-user/ more, so this is our way to get our users to shut up". And 'blazed', in this case, is 'lit on fire many decades of hard-earned UI experience'.
> As an aside, I set the operating systems I use to always show scroll bars.
Which is why you should support custom CSS scollbars to negate browsers & OSes hiding them.
> As I type this, there is no scrollbar on my screen because Firefox no longer does that.
If you’re using Linux: blame GNOME for this; in GTK 3 and 4, they actively removed your ability to get non-overlay scrollbars without each individual app manually supporting the concept. So there’s no global switch or anything like on macOS or Windows. Firefox has a setting “Always show scrollbars”, but precious little other GTK software will support non-overlay scrollbars in any way.
The problem is, there are so many to blame. It's not just GNOME: it's Microsoft, and Apple, and GNOME, and... It can't be fixed by just one entity refusing to go with the flow; the flow is the problem. As long as there seems to be some sort of invisible consensus by designers worldwide that Scollbars Are Bad, the problem will spread and infiltrate systems, even ones which ostensibly default to scrollbars.
('A setting' is also not a fix but a copout as I already pointed out - you know >99% of users will never change it, especially on mobile. Whether open source or closed, maintainers are always the same when it comes to taking the hard path of fixing something's design or the easy path of saying 'you can set an option, CLOSED'.)
I agree with many points but there is definitely a need for custom scrollbars.
The reality is that if you have scrolling in the page (like a column layout for example), you kinda have to customize the scrollbars. If only to not break your layout as scrollbars are completely different everywhere, hidden, different widths, some ugly, some nice, no reliable way to detect the situation, it's a mess.
I would opt for more options: give us better tools to style (around) scrollbars, give us the tools to honor what the user prefers, to know when and when not to blend it in with the UI, to increase contrast, or to just leave it alone.
Just not customizing is not a realistic solution for a lot of situations.
Your UI really shouldn't be so unresponsive that the width of an element's scroll bar throws off your design. As for the aesthetics of the scroll bar: it might look ugly to you, but that's what the user expects their scroll bar to look like!
Designing well for web requires a bit of a paradigm shift compared to designing a print document or even a native app. You have to accept that you're going to be a guest in the user's browser, and that means you don't have control of everything. Failing to accept that just leads to frustration, but if you can embrace it and strive to be a good citizen of the user's browser, the resulting symbiosis can be beautiful in its own right!
> but that's what the user expects their scroll bar to look like!
You base that on..? I’ve had users complain about their native scrollbars more than once. Native scrollbars can make things look very broken.
In terms of responsiveness, true for a normal website, but sometimes impossible in more complex ui elements (like I said, not the page scroll, but in page scrollable elements)
I would really like to see some research on this idea that people prefer native elements, it’s not what I see in user tests and the feedback I get. My experience is that people want a functioning app that doesn’t look broken.
My whole point is: we should be able to provide a great experience that’s accessible and allows the user to give their preferences (like prefers reduced motion).
249 comments
[ 2.1 ms ] story [ 304 ms ] threadThe removal of scrollbars from browsers confused my parents. Instead of having up and down arrows by your content now you're just expected to just know that you scroll with your mouse / trackpad. Similarly, modern versions of Windows will just assume you know that the four squares at the bottom of your screen is where you need to click to start using your computer, and Mac will just assume you know the red dot closes the current window. These patterns probably seem obvious to us as power users, but I find average users get endlessly confused by them.
And it's not just elderly people who get tripped up by this. I've seen kids who have primarily used phones and tablets growing up get confused when they first use a desktop computer because they haven't yet learnt all the required prerequisite UI patterns. Even as a power user if you switch from Windows to Mac (or vice versa) it often takes some time just figure out all of the completely unintuitive modern UI because the UI designer is lazily assuming you already know how to do everything...
Just yesterday my girlfriend (who uses her computer almost every day) asked me for help replying to an email in outlook on her laptop. Confused I asked, "what do you mean you need help replying to an email?". Well, she was confused because she doesn't use outlook much and didn't know she needed to click the small curved arrow icon to reply to an email. For the last 5 minutes she had been stupidly looking for a button that said "reply".
While I completely agree with your sentiment about scroll bars, I feel like this a much bigger issue and one that web developers shouldn't be required to fix. The core issue here is that your OS / browser shouldn't be hiding your scrollbar to begin with... This isn't something web developers should be addressing, but the UI designers who think it's preferable for me to have a browser URL bar that is 80% of my screen width at the expense of the word "back" on my back button.
They're obvious to power users because we have seen them a million times before.
When a web developer does a custom scroll bar that is when "average" users get confused, because suddenly they're presented with something they haven't seen.
It's not too much to expect a user to know how scrolling works by default in their client operating system/browser. It _is_ asking too much to expect users to know how scrolling works when you customise how it works. Web developers should not be touching this stuff.
It goes the other way as well lol. There's lots of ridiculous random gestures for android/iOS
The Apple folk and adjacent circles like to throw around how “design is how it works™”, but design hasn’t been how it works in Macos for a while (and it’s not better anywhere else).
I was once guilty of doing this on a site I made but the users called it out so I fixed it. It's another thing for a UI library to spread this pattern.
Wouldn’t this look completely off with a massive light mode default Chromium scroll bar in the middle of everything? When I was developing that my main goal was to get the UI looking consistent and clean so it would feel good to use, which I think is an underappreciated thing; if your UI doesn’t “feel right” then people won’t enjoy using it no matter how functional it is
To be fair it probably does have contrast issues which I could improve
Note: it’s an Electron app so maybe that’s different
Now the only remaining use case is when designers don't design components around default scrollbars. Sometimes the default one just looks too big compared to the size of the component. But this can be solved with design (don't cram stuff into small fixed boxes that then need to be scrollable).
What’s the difference between styling a scroll bar and, say, a button in an application like this? If you want everything to look how the user prefers and fit into the OS then you shouldn’t really style anything at all
Yes, which is why that design is wrong. Respect @media(prefers-color-scheme). Forcing a light or dark background causes readability issues for some people.
https://user-images.githubusercontent.com/13787163/161954436...
And note that the act of scrolling is much more related to the OS host rather than something the website itself should provide (now, if there was an standard way across every device to scroll to the very top or the very bottom of a view (webpage, list, etcetera...). I am a designer myself but I agree than we should not mess with them. And the plus that it's a bit less of work for us (and devs, when they have to implement those things).
But if scroll bars can be themed with CSS now, that should still give the browser control over things like whether they take up space or not and the actual scrolling behaviour, right? It would just allow the developer to give some styling hints so it doesn’t look completely disconnected from the rest of the page
Whatever style the user currently has installed on their system, if the scrollbars on your app look the same as all the other scrollbars they ever use, they'll recognise them instantly and know how to use them instantly, with zero additional cognitive load.
You users might be using enough of their brain to figure out your app (maybe because they're also being partially distracted by their boss/child/phone/pet/music) already, don't make them spend time thinking about your gorram scrollbar as well.
It can be difficult to visually say "Hey, you! There's more to see if you scroll down in this area" You can try to use gradients with fade-outs, you can try to make it so the top of the last item in a scroll area is just visible enough to make it clear something can be scrolled into view. I've also seen actual text-based messages at the bottom of scroll areas to let users know. But at that point, is it really better than creating your own little scroll bar?
Really I think we just need better APIs from the browsers to customize when a scroll bar is shown (again, not on the page level but within scrollable elements), and what it looks like. This has already gotten much better over the years but there are still some features that would be great to have in this area.
One thing I will say is I really dislike the smooth-scrolling behavior that some sites build in with JS. It's usually broken on macs that already have smooth scrolling and it's just a dumb thing to add.
I'm fairly sure every platform uses smooth scrolling by default, and so I'm absolutely and utterly baffled as to why web devs think they need to implement it in JavaScript.
If you're on a platform without it, or you've explicitly disabled it, there's probably a good reason for it, so re-adding it with JavaScript is taking away agency from the user.
Accessibility. Mention that blind users will be unable to utilize the site without a lot of additional work and you can usually kill it dead.
Custom scrollbars are such a niche thing that usually nobody is married to the idea - I've found it quite easy in the past to kill off those sorts of weird quirks in design with just that word... If you still have issues mention that mobile browsers often do a lot of customization around bounce scrolling and the like. Building this design choice out now likely means that whenever Apple releases a new phone it's quite possible that your site look antiquated and requires some major reworks.
What do you have in mind beyond "always show", "show if needed", and "always hide"? Those have all existed for decades as "overflow: scroll", "overflow: auto", and "overflow: hidden".
If HN allowed emojis, I would reply with just the vomiting emoji.
kidding aside, it is longer that it could be, to get the point across. maybe the browser just needs a similar setting to the macos and windows one, to never use css on scrollbar, and we're good?
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.
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?
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.
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.
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.
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.
I'd say default should be whatever the web designer wanted, if you're not agree you can always use one of the overrider plugins.
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!
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.
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.
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.
So instead of design being the intersection of form and function, design becomes entirely detached from the function.
It does not require the developer to completely rebuild the component behavior from scratch using JavaScript.
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 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.
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...
One of the most frustrating thing on the web is capturing any scrolling behavior, or catching conflicting keystrokes (such as cmd-f on some fora).
I know "considered harmful" has become a cliche, but I almost miss that format now.
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.
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.
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.
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.
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?
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.
That'd be much better if you actually need a different behaviour.
Trying to bend the native scrollbar to your will is an exercise in pain.
What's old is new again... and again... and again... :)
[1] https://bbrks.me/reinventing-scrollbars/
[2] https://news.ycombinator.com/item?id=6246777
No, they're actually in my scope of concern, that is the whole point of your article. The reason they were brought into my scope of concern is that a lot of people had a use case for styling custom scrollbars. I have a use case for it myself. If you're saying "don't abuse your ability as a developer and make inacessible websites" then yeah, okay. But taking options away from people because they might theoretically make bad moves with them is not a good strategy. If you took away every CSS attribute I could use to make inaccessible websites, we wouldn't have anything left. You'd be surprised what I can mess up. Better to teach people how to do it right and why.
This is a meaningless statement, because even native apps don't "look like" native apps. No operating system has a universal style across all native apps, and some (Windows) aren't even internally consistent with the OS's apps.
Imo, an app that isn’t using Cocoa (or carbon for older apps) widgets on macOS isn’t “native”. If you just use the default widget set on macOS, your app will have a consistent style with every other native app. If you use Qt, Swing, Electron, etc., your app will look out of place and break in ways that annoy at least some of your users.
I get your point, though; I'm a Linux desktop user, and have to contend with apps written using a variety of UI framework. For that reason, I tend to try to stick with GTK apps, as I prefer consistency. I have Qt set up to use/emulate GTK's theming as close as possible. No, it's not perfect, but most things on my desktop look pretty consistent.
Except webapps, of course! They break everything when it comes to consistency. I wish that wasn't the case.
What I prefer is consistency with the OS. My OS is my main tool for interacting with the digital realm. My life would be easier if the conventions were more evenly applied. Custom scrollbars concern me that my OS defaults are being overriden: will the field scroll at the expected speed; can I flick it and catch it as I’m used to; is the scale expressive of content size?
Custom scrollbars tell me that the developer doesn’t care about me, they care more about their brand manager and their pay check. This suggests the product they represent wont suit me.
Along with intrusive pop-ups, subscription overlays, and “we value your privacy”, it’s a clear sign I should not engage with that provder.
I've tried to go back & find evidence of this era, to find more examples of these heavily glitzed up components. And wow, so much of this has disappeared entirely off the net. Maybe I'm lacking the right keywords. But this feels like a mega flash in the pan that came & went super fast.
https://pbs.twimg.com/media/Fb5HJBFWQAIH09w.jpg
>> There’s no visual indication that there’s more content present in this window—the only way to discover it is to scroll downwards. However, without an affordance to indicate the presence of additional offscreen content, the chances are low that someone will bother to check.
I appreciate the callout that Apple is an infringer on removing the scrollbars, which is a bad UI practice. For the entire lifespan of the web, overflow content indicators have been (aka scrollbars), for better or worse, an inherent function of the browser.
People were accustomed to long pages like Yahoo's homepage with lots of content below the search bar.
They solved it by adding a footer section with typical copyright text and people understood that the page was finished loading.
I read this, and I get a very good idea of what the rest of the post will contain.
I know we love to talk about optimizing web contents, but a single selector and a few hundred bytes (before minification and compression...) is not significant
As a user, I prefer for my OS to do things my OS does, including styling my widgets. My scrollbars, my scrolling behavior, window chrome, all of it… whether it’s good or bad or right or wrong, that’s between me and my OS.
As a user, I hate when web apps mess with scrolling. It breaks affordances I use, like tapping at the top of the screen to jump to the top of the page, or home/end keys on desktop. It is inevitably a worse experience than native scrolling, no matter how hard you try. Facebook mobile web for example is basically unusable right now because it’s trying to overthink scrolling. If Facebook can’t get it right, I’m not sure what makes anyone else think they can.
And why would anyone want to? Honestly! Microsoft and Apple have already done all that work.
As for scroll bars and other widgets, again, right or wrong, that’s not for some web site to mess with. Sorry if the developer doesn’t like the way it looks… they only have to deal with it while working on it. As a user, I am stuck with the developer’s choices, even if they override my own choices, which I’ve made in my OS, which is where those choices belong.
If you’re going to clobber native experience, I would argue, don’t do it unless there is absolutely no other option. Corollary: there is always another option.
Similarly with the MS/Apple - if they had already done all the work, they would allow you to force your scrollbar choice
> Corollary: there is always another option
What's your other option to only show wide scrollbar in large documents since these are the only ones I actually need scrollbar in?
I disable them in settings. I want to see them all the time.
https://support.apple.com/en-us/guide/mac-help/mchlp1225/mac
Scroll bars popping in and out of existence awkwardly reflowing elements around it. Tiny unusable 30px wide horizontal scroll bars inside an input element because an element overflows 0.7px due to font size rounding issues or what not.
Default scroll bars are great for documents, but pretty terrible mostly for slightly more complicated UIs where a lot of info is displayed in small area.
edit: they are removing the flag from gtk 4: https://bugzilla.gnome.org/show_bug.cgi?id=790677#c6
gtk is effectively a gnome project now, and we all know gnome's attitude toward design and users.
Thirdly, there is an obvious counter to your arguments that shows that one-size-fits-all design is not actually what users always want: games. You wouldn't expect a game to use the system look-and-feel, it rightfully uses a look-and-feel that matches the game itself.
And we can extend this observation further out: if your app is self-contained enough, and you have a distinctive enough style that your users like, then you should re-style everything away from the OS style to your specific unique look.
Should every app do this? Absolutely not. But is there no case outside gaming where an app should? Of course not.
Having done e.g. an endless scroll application, the scrollbar was unfit for our use, no matter what we did. The right solution was to remove scrollbar and implement our own scrolling mechanism.
Some applications have neither a beginning nor an end, so scrolling to the beginning makes no sense. At best, you could make "scroll to the beginning" get back to the start of your navigation, but then your scrollbar wouldn't let you go further.
(also if you have both horizontal and vertical scrolling, you're still left with no horizontal options)
Yes, and? No matter what it is, it's what the users of said platform are used to. Is there really a benefit to forcing users to re-learn such a critical component?
> You wouldn't expect a game to use the system look-and-feel, it rightfully uses a look-and-feel that matches the game itself.
1. Not everything is a game.
2. Depending on the game, system look&feel can be perfectly fine: SimCity 2000, Aurora, the Rule the Waves series, and probably loads of other simulation games all use it, because their art style doesn't require to re-invent the wheel poorly.
3. Games whose art style do need custom look&feel will most likely be using a fullscreen canvas/WebG(L|PU) widget anyway and will be able to use it regardless of CSS support of the feature.
Also, I thought the specific points about CSS and how to achieve custom styling if desired are irrelevant. The arguments I was replying to were about UX, not about details of how that is implemented.
Because it's difficult, it's often done poorly, which leads to people thinking it should never be done at all.
To your point about games, I find most custom-written scrollboxes in games to be pretty terrible, but we all kind of appreciate them just for their uniqueness, because as UX items they're generally not something you interact with that much. (Unless you're playing Crusader Kings, in which case ... )
I remember being disgusted and offended by Apple's app developer rules two decades ago, which included dictates such as never implementing your own UX elements like scrollbars. We're still debating whether they were wrong. As long as there are bad ways to build UX elements, some people will do them, and this will serve as proof for a few big companies that it should never be done.
No comment on whether or not that's a good idea, though.
But the point is, that your website is not an app. At most it is a web app, and therefore governed by the browser and the user's preferences and choices for the browser.
A website (or website that is a "web app") should fundamentally be a different degree of commitment than installing an application into the user's system. There is a reason for browser sandboxes and for the browser to have its configuration. The browser itself is the actual app and the user should be in control of that, to govern a at least partially unified UX throughout the websites the user visits.
I agree with that, but this is opinion and not fact. There's a lot of money invested in blurring/obviating this distinction, exactly because installing a real app has more hurdles (both for the developer and for the user).
The web is much more than productivity focused software, and limiting it to some specific notion of dull uniformity in the names of consistency is honestly sad.
If I want to create a site to represent a detailed exploration and appreciation of the Voynich manuscript, why should I not try to style similarly to the original manuscript? Why should utility trump aesthetics for nay document on the web?
But I'm only talking about websites, not web apps. I don't use web apps, so have no opinion on them.
This goes beyond scrollbars. There are hundreds (thousands?) of libraries or entire frameworks to build consistent dropdowns. Even more to create date-pickers and to replace alert dialogs, add modals, and whatnot.
This shows that the browsers don't do a good job offering nice and neat UX on them. Same for scrollbars. Browsers offer native dropdowns (that more-or-less match your OS - depending on browser and OS), datepickers (that at least match your locale) and even native alert dialogs. And many are ugly as hell, have a terrible UX or integrate very poorly. IMO fair points. And often even reasons to replace the native widgets with tons of JS, CSS and dom manipulation. Edit: though I don't think this is the case for scrollbars, I think browsers do a good enough job there.
The one reason that I very much disagree with, it cross-browser or cross-platform consistency. No-one cares that widgets on your website or -app are the same on chrome/windows, icebeaver/weirdlinux and safari/OSX. Because no-one other than the webdeveloper and -designer will ever use them on all those platforms and expect everything to look the same on all these platforms.
Find me a user that sez "This experience sucks...that's the native scrollbar" and I'll give you $100. If you give me $1 for every user who is fine with the native experience they are most comfortable with. If you give me $1000 for every time a custom scrollbar isn't accessible.
Fwiw, I've never visited a site with a custom scrollbar that didn't have other UI / UX issues. The fancy scrollbar didn't makeup for those.
p.s. Gaming is a different aesthetic, a different audience, etc. It's not what should be the user-centric internet.
I don't think that games are an entirely different world from web apps. There is some amount of gradation between pure document-like pages at one extreme and games at the other, and a whole spectrum in between (say, an app like Google Earth probably doesn't need regular scroll bars to implement most of its scrolling behavior, while not being a game).
Also, I think users are quite observant of color clashes, and will notice if you have system-styled scroll bars in the middle of a web page that is styled in a specific way. I don't even understand how this is a controversial opinion - especially when we have things like dark mode that was available in numerous apps long before any OS or browser supported it natively - thus requiring the app to re-style all controls.
Oh yes I do.
https://store.steampowered.com/app/2008100
When using a webpage, you generally are trying to 'get something done'.
Besides, games implementing their own widgets can be terrible for accessibility.
The main difference between games and many other apps is that games are trying to sell you a fantasy, and look and feel are much more important to keeping you in the right mindset than in some other apps. But there are other apps and even web pages with similar goals which don't quite qualify as games.
in my experience it is generally designers or business people who don't like it, the developer generally argues your line.
eg. Dark Mode - wasn't created by Browser or OS providers, but developers (as I understand), then OS/Browsers played catch-up. Developers can and sometimes do influence Design "upstream".
To be clear, this articles talks about styling only.
Tbh, if you like native features of scrollbars, widgets, etc., the most practical way you'll get to keep them in 2023 will be if they can be custom styled.
You have an application that works terrible if you make the scrollbar transparent.
Transparent scrollbars are not intuitive.
Well that's your opinion. But I would rather see a scrollbar in the middle to show me that I can actually scroll something. Otherwise it's a hidden feature and hidden features are not features, they're bugs.
And actions should be buttons, not links. I'm looking at all of those cookie websites with a 'link' that says 'Confirm choices' and a button that says 'Allow all'. Instinctively we go to the button, not the link.
Weirdly enough I responded on the Image send to Microsoft via MS Edge article about how even Microsoft, the writer of LOTS of documentation on how to make good UIs, abuses all these things.
Now, of course we could argue about how these things just visuals, but that's not completely true. Lots of screen readers depend on the semantics of the document structure to actually identify objects correctly. Button? Action, edit, sign up, delete, .... Something that actually changes something.
Link: navigation...
Aria is for making inaccessible html more accessible. Links can not be disabled (buttons can) - so they dont rely on js to work; Buttons rely on js (except for submitting the form). There is no way to interchange one with another without sacrificing usability.
For any change, on the first day, only the programmer understands the new scroll bars.
For an Internet user who each month or so goes to dozens, maybe hundreds, of Web sites, all the new scroll bars are something new to learn likely particular to that site. So, for that user, a significant part of the Internet becomes dozens or even hundreds of times harder to use.
Same for standard HTML push buttons, links, check boxes, radio buttons, multi-line text boxes, single line text boxes (and the ones for passwords), etc.
Changes make the site obscure and significantly more work to use.
Web site owners: When I see a Web page with an obscure user interface, commonly I just do a single left click on the X in the upper right corner of the Web browser instance displaying that page.
Beyond an obscure user interface, often I can conclude that the Web site does not want me to see the content on their Web pages because they cover up the content with pop-up windows or expand and contract some header material at the top of the page, material that wastes limited vertical space on my screen.
Another problem is Web pages that follow my mouse pointer and respond to its position without my giving a click. Big interruption in using the site. Nearly always I'm just trying to bring the window to the top of the Z-order so, instead, have to swat like a dozen flying insects the various responses to the mouse click -- again, I do want to see the page and just want to bring it to the top of the Z-order.
Then there is Web site code making the window larger -- again it's like swatting flying insects. No, no, 1000 times no, with rare exceptions, I do NOT want any one page to hog my screen area. The reason is fundamental: In visiting the page, I'm trying to get something DONE, and that requires seeing at least two windows, maybe a few more than two. When one program takes up all or too much of the screen area, I can't see the other windows I need and, thus, can't get the work done.
There is an old remark that goes something like "Just because you could doesn't mean you should."-
Interesting that you mention checkboxes. For a long time native checkboxes on Linux (distro?) would come up impossibly tiny if you had a decent-sized screen. They were hard to hit accurately with a mouse, and impossible with a trackpad. That seems to have been cured now, but I don't know when it was fixed.
The mockup scrollbar looks nothing like scrollbars are now.
> Do you need to make someone download that extra data? > > Spoilers: you don’t. Scrollbars work without CSS.
No, they don't, because web browsers have been busy removing scrollbars as much as possible. As I type this, there is no scrollbar on my screen because Firefox no longer does that. For a moment, I thought maybe FF still showed at least 1 pixel of the scrollbar, but I scraped it off with my fingernail and it turned out to be a cat hair. The scrollbar appears only for like a second before 'helpfully' fading out, and is a few pixels wide (on a 4k portrait monitor where I'm not exactly hurting for space). Chromium still has a semi-reasonable scrollbar, but I can't vouch for the official Google Chrome. Safari and Mac OS/iOS have, of course, been years ahead of everyone else in the wonderful pro-user innovation of 'hiding scrollbars and making them a pixel wide if absolutely forced to display one'.
> ...This is why Apple introduced a preference to always show scroll bars...Windows followed this path blazed by Apple
Yes, a preference to go back to the old standard behavior, which in designer-speak means "we done f-ked up, but we hate real users and love the sleek minimalist appearance https://asktog.com/atc/the-third-user/ more, so this is our way to get our users to shut up". And 'blazed', in this case, is 'lit on fire many decades of hard-earned UI experience'.
> As an aside, I set the operating systems I use to always show scroll bars.
Which is why you should support custom CSS scollbars to negate browsers & OSes hiding them.
If you’re using Linux: blame GNOME for this; in GTK 3 and 4, they actively removed your ability to get non-overlay scrollbars without each individual app manually supporting the concept. So there’s no global switch or anything like on macOS or Windows. Firefox has a setting “Always show scrollbars”, but precious little other GTK software will support non-overlay scrollbars in any way.
('A setting' is also not a fix but a copout as I already pointed out - you know >99% of users will never change it, especially on mobile. Whether open source or closed, maintainers are always the same when it comes to taking the hard path of fixing something's design or the easy path of saying 'you can set an option, CLOSED'.)
The reality is that if you have scrolling in the page (like a column layout for example), you kinda have to customize the scrollbars. If only to not break your layout as scrollbars are completely different everywhere, hidden, different widths, some ugly, some nice, no reliable way to detect the situation, it's a mess.
I would opt for more options: give us better tools to style (around) scrollbars, give us the tools to honor what the user prefers, to know when and when not to blend it in with the UI, to increase contrast, or to just leave it alone.
Just not customizing is not a realistic solution for a lot of situations.
Designing well for web requires a bit of a paradigm shift compared to designing a print document or even a native app. You have to accept that you're going to be a guest in the user's browser, and that means you don't have control of everything. Failing to accept that just leads to frustration, but if you can embrace it and strive to be a good citizen of the user's browser, the resulting symbiosis can be beautiful in its own right!
You base that on..? I’ve had users complain about their native scrollbars more than once. Native scrollbars can make things look very broken.
In terms of responsiveness, true for a normal website, but sometimes impossible in more complex ui elements (like I said, not the page scroll, but in page scrollable elements)
I would really like to see some research on this idea that people prefer native elements, it’s not what I see in user tests and the feedback I get. My experience is that people want a functioning app that doesn’t look broken.
My whole point is: we should be able to provide a great experience that’s accessible and allows the user to give their preferences (like prefers reduced motion).