I am of the opinion that you should not mess with my scrollbars. I like them to be visible and wide, because (a) I like to know a page's length and my current progress, and (b) I'm a bit blind and I don't want to hunt for an 'unobtrusive' scrollbar.
There are options at the system level, I find it great that most browsers follow them and sites cannot willy-nilly change them without my consent.
I like macOS/iOS's hidden scrollbars personally, but I agree with you about not wanting pages to be able to override scrollbar behavior in any manner. The way my scrollbars work is perfectly fine and, more importantly, predictable, and I don't need web pages changing that on their creators' masturbatory whims.
Too bad Google once again leads the way of being a prominent example of a bad idea with its custom scroll bars on many of its properties.
I used to like MacOS's subtler than Windows approach to scrollbars, but they became too subtle. They were lovely in Snow Leopard: Gently aqua coloured, arrows, large enough for middle aged (or overworked, and in a hurry) eyes. Obvious.
Then they went to Lion and ruined them: grey and almost invisible by design. Magical mystery popping into existence when you hover where it ought to be. Probably. I think this is when they inverted the magic mouse scroll behaviour to pretend like your iMac was an iPhone.
I've had the setting flipped to always show them since they added that nonsense. It looks a bit more subtle, and isn't brightly colored, but it serves the important role of showing at a glance how long the page is.
The backwards scrolling is way more obnoxious though, and I rage every time I use someone else's Mac or do a fresh install.
Aye, me too. Though I prefer when they were a little more obvious - now they're a background visual indicator, and essentially deprecated as a control, for being too narrow.
Most of the times I encounter backward scrolling on someone else's Mac, it's only there because they never realised Settings let you invert it to sane and useful!
The “backward” scrolling (a better name might be “content scrolling” as compared to “window scrolling”) was changed because the “forward” way does not work for scrolling content on a multi-touch display. If the content moves in the opposite direction from the finger, it completely breaks the illusion that the fingers are directly controlling the content.
People switching back and forth between Macs and iPhones or iPads initially found it very inconvenient/frustrating to have window scrolling on a touchpad and content scrolling on a touchscreen.
It was decided that switching the Mac to be consistent with iOS would cause momentary frustration for Mac users (it requires a few days of retraining to get used to) but would be less frustrating for most users than preserving two inconsistent behaviors into perpetuity.
The option to keep the Mac on window scrolling was included to mollify those few Mac users unwilling to spend a few days or weeks re-training themselves to a reversed gesture.
The problem is that my mental model for scrolling on a touchpad is different than scrolling on a phone/tablet. My finger isn't touching the content, it's touching a scroll device. It never stops feeling backwards to use a touchpad and have the scroll go backwards.
On a macbook with a big touchpad it sure as heck feels like touching the content. Esp. with fluid gestures (not abrupt like windows) and pinching it feels very physical. And then flicking with two fingers and the inertia of the page that keeps on scrolling because you pushed it very hard feels satisfying. On windows it just feels fake.
Anecdotally, several people I have talked to about this had no problem with the new behavior (after a relatively short re-training time), but did find switching between touchcreens and touchpads with opposite behaviors frustrating.
If you do have a problem, then you can switch it in System Preferences. Everyone wins.
The biggest problem, in my opinion, is that there appear to be two settings, one for trackpad, and one for a mouse scrollwheel. You can find them in different locations. They change the same value, though. You can't have natural trackpad scrolling and "pull the wheel towards you to scroll down" scrolling at the same time without a 3rd-party application.
> they inverted the magic mouse scroll behaviour to pretend like your iMac was an iPhone.
These are UI/UX conventions. Everything is "pretend".
For example, users whose mental model of scrolling tracks the viewport will want to scroll up to move the content down. The viewport goes in the opposite direction of the content.
Fair enough.
However such users don't seem to want the same for horizontal scrolling. Tracking the viewport left moves the content to the right and vice versa. But horizontal scrolling in macOS always tracks the content regardless of the setting in System Preferences > Trakcpad > Scroll direction: Natural.
The exception (turning it off for "inverted" scrolling or "viewport tracking") is only for vertical scrolling, not horizontal, which suggests the mental model can be adapted though users who prefer viewport tracking report they cannot adjust.
Sure, perhaps if I had known nothing else... Except it's not a convention any other platform ever followed.
Of the few people I've bumped into who had it set to natural, and had for some considerable time, well even those were happy to learn it could be changed, and didn't want to go back. So there's probably something makes it feel odd, and stay feeling odd, for many. What I couldn't say, but not just restricted to those who spent time on other platforms too, like me. Of people whose machines I get to use from time to time at work, they're all set to unnatural too. We're nearly all iPhone users. So it's not just me being odd and rare edge case. :)
Personally, I don't want the same mental model between phone and desktop, as the metaphors are different. UI should look different, act different, suited to using each device. The Win 8 on, Lion on desire to make my laptop "feel" more like a mobile, continues to feel like a huge mistake.
I agree with this, so based on the article I think that browsers should respect the Windows setting since it's an expression of the user's preferences. Other than that, I have a strong preference that webpages don't try to style the scrollbar (with exceptions when it really makes sense).
One site I've thought it made sense was in Discord, which acts as a properly themed web app and where the clash of certain native scrollbars would be jarring (eg: bright scrollbars on a dark theme). That said the scroll bar it uses for the user list is microscopic compared to the one used for the message log, which is a baffling decision.
For every other regular site, and even most web apps, I always prefer native, for Windows.
Well, no problem in making all those styling rules opt-in. When it really makes sense, you can choose to use the author's UI. Apply that for colors too.
Applications should respect the DE settings for UI. Browsers are the main culprits here, but only because CAD software isn't widely used. Oh, and there's MS Office, that will respect absolutely nothing. All of those are in the wrong. But everywhere the DE is powerless to enforce its style onto applications, so this is a much harder problem to fix;
Personally I think the main page's scrollbar should be handled by the OS. For any element inside the page, I think it's ok for the site to handle how the scroll works to make it consistent with the page's design.
I have some dev tools that do infinite scrolling and I wish I had the authors here to tell them how fucking stupid I think they are.
If the page is long enough for infinite scrolling, I'm probably going to have a slightly error-prone recollection of the exact string of text I'm looking for. Taking search away from me makes this worse.
There's a bit of psychology that says when someone is experiencing a strong emotion, good or bad, they will associate it with a person nearby, whether they deserve it or not. This has applications from espionage to team building to crisis management.
One of the wrinkles of this is that if someone is already or almost experiencing a strong emotion and you add to it in any way, you've made yourself a target.
One of the things I tell mentees about code and test quality (especially the latter) is that in the grand scheme of things, nobody (read: a tiny fraction) is going to look at your code for fun. They're going to look at it because something bad happened, near it or in it.
Assume the person reading your code is already having a bad day. Don't make it worse. Especially if it ends up having nothing to do with you.
The infinite scroll bozos, at least in the scope of productivity tools, are making my not-great day worse. The ones that 'fix' this by hijacking CTRL-F and do their own half-assed implementation of search are just doubling down. If you're going to listen on CTRL-F, maybe force-update the entire list instead?
Atlassian for one. Their old code viewer was a disaster but that might have been Bitbucket’s fault. The repository list lazy loads, and if you’re at a big enough company the repositories get into multiple projects and it’s always disorganized. Which project is this repo in again? Time to hunt around and oh yeah CTRL-F doesn’t work unless you remember to scroll to the bottom repeatedly.
Most of the time the scrollbar is so damn narrow that sometimes I am having troubles positioning my cursor on it, seriously! It is hidden by default, AND narrow. I have difficulties making it appear and use it for scrolling. I move my cursor by one pixel, and it disappears again, sometimes I have to fsck around with it for way too long.
Yeah, the unobtrusive scrollbars make sense only if you're using a multitouch touchpad or Apple's mouse — as soon as I have to use e.g. some office's basic mouse, chasing those unobtrusive becomes a major pain, to the point I wish Macs would switch to traditional scrollbars if I connect a "plain" mouse. Not that it matters: modern websites tend to completely break scrollbars.
I completely agree. I'm questioning whether I'm curmudgeon for feeling this way, but the only time I notice scrolling customizations is when they mess up scrolling--which is surprisingly often and also seems intentional most of the time.
I understand the motivation for controlling the experience, but I really think designers are undervaluing consistency. It feels like the car I drive every day acts different on one road. Sure, there's a very tiny chance it's an improvement if a lot of time and thought has been invested, but in all likelihood it's just very jarring.
The core problem, as I see it, is of someone else deciding that "unobtrusive" scrollbars are better.
On a mac, to actually grab the scroller for scrubbing, you need to scroll a bit to make it visible and then manage to bring your cursor into a tiny area using the trackpad within a few seconds before the scroller disappears. If you miss, clicking activates window resizing.
UIs need to be functional first. Being pretty should never trump being functional.
I mean, if I write an app and hide a "dysfunctional prettiness [Y/n]" configuration somewhere in settings, is that a good thing?
I'd argue there are at least two better options that are trivial to implement, and surely more if one cares to do UX due diligence when trying some novel design.
With Mac they can generally influence the scrolling interface by making one of the best trackpads and magic mice standard, where scrolling is a critical part and not an afterthought, plus lots of visuals showing how to scroll with it.
You really don’t need to click and drag the scrollbar very often if at all. Especially for page scrolling which the article explained - it’s more important for overflowed objects, especially horizontal ones. And if you need to scroll there’s no guarantee that having 25px control design vs 50px (guessing) like windows would help, the click area tends to be a wide as the bar part not the control.
I'd argue there are at least two better options...
Wasn't your original complaint that someone decided what was "better"? Or are you complaining that they didn't take your choice? Point being that someone that decided otherwise thought they had a good reason for their decision, too. In this case, it could be argued that trackpads reduce the need for the scrollbars. (I have no idea what the real argument for such UI behavior is.)
I'm talking in generalities. The status quo used to be "scrollbars are visible things". If you're going to change the status quo, it behooves avoiding a dark pattern (like e.g. privacy settings turned off by default). The two better options for UX changes (generally) are to leave it alone, or to create a configuration that defaults to the old way of doing things. You probably heard again and again of some random company doing some major redesign with good intentions and ending up pissing off users.
In my experience, the backdrop in many of those cases is that UX changes get rolled out because people need to justify their jobs or they think X is prettier/popular. You don't hear nearly as much about people doing UX research as you do of people cranking out React things, and it would be extremely benevolent to assume developers do in fact do expensive, time consuming UX sessions w/ users.
If we talk specifically about scrollbars, maybe a good litmus test is this:
- if the default was no scrollbar whatsoever, would that be a problem for you?
- if the default was a read-only scrollbar (e.g. it merely reports whereabouts in the page you are, but does not respond to mouse events), would that be a problem for you?
If the answer to either of those is "no", you probably aren't actually using it. They could conceivably be configurations too, but why?
Consider this hypothetical parallel: why not hide the "Help" menu item in apps? Personally, I don't use it and it would clean up the UI, so it must be fine, right? Well, not necessarily. Because if you bother to do UX sessions w/ users, you may find that people looking to use that specific feature will have expectations about where it should be.
People changed their interaction after mice and trackpads started to universally include a built-in scroll wheel / scroll gesture.
In 1990, everyone scrolled up or down by clicking little buttons at the ends (or at one end) of the scrollbar, or by dragging the scrollbar up and down. By 2019, these buttons are unnecessary and have been removed, and the main purpose of the scrollbar is to passively report the position in the page. Dragging it up and down still works, but few people bother.
I did not know this, but I am apparently one of those few people who use a scrollbar to point to a location where I need to be. Either in source code, manuals, even on some vendors web pages I know the tech specs and the link to the datasheet is 2/3 of the page so I drag or click the scrollbar. In documents, or on webpage I have a mental image of where the scrollbar was when I read it, like page numbers in a book and I use it a lot. And no this is not substituted by scrolling with a mouse wheel or heaven forbid a track-pad. If I know I need to find something at 'M' I do not want to go through all the stacks starting at 'A'. Just saying we have been organizing content for a lot longer than the UX people telling us what we do not need.
Scrollbars are a tool and they should be functional: visible, properly sized and interactive. It helps if a scrollbar looks and functions the same on all our content, because it takes less mental strain to use.
It may be that you don't like scrollbars for your content. The obvious solution is to make your content fit so it does not require scrollbars. If you cannot manage that you will have to live with the fact that scrollbars are there as a functional tool and make sure it is kept functional.
In analogy: If I sell furniture you have to self assemble I can choose to design it to not require tools. If it does require tools I should make sure people can actually use those tools to assemble and not try to hide that tools should be used by pretending the thing to put nails in is not a hammer.
I have almost forgotten that it’s even an option to click and drag! On my trackpad I use two-finger scroll, and my scroll-shell mouse can handle horizontal scroll just fine.
But honestly even then it’s not common for me to run into those. I’m a keyboard user, so the thing I get persnickety over is whether or not you got your focus order right, if you steal keyboard focus senselessly, or if you made a UI that only responds to mouse clicks.
Being pretty helps the first impression in an Apple store, and for first few days.
When a user realizes that a scrollbar may be a useful feature, but it's somehow hard to obtain, it's too late to complain, and the Stockholm syndrome kicks in.
> On a mac, to actually grab the scroller for scrubbing, you need to scroll a bit to make it visible and then manage to bring your cursor into a tiny area using the trackpad
This complaint looks disingenuous to me. If you're using a trackpad, you already have scrolling built in and the scrollbar is there primarily for visual feedback.
The reason that scrollbars can now be invisible by default is exactly _because_ of the ubiquity of touchpads and mice with built-in scrolling.
Scrolling yes, but not scrubbing. The latter is a feature that people use for navigating very large pages (e.g. I may remember the rough location of some section of some programming language spec that I'm looking to consult, but the spec is 500 pages long)
> This complaint looks disingenuous to me. If you're using a trackpad, you already have scrolling built in and the scrollbar is there primarily for visual feedback.
For short scrolling, that's fine. For long documents, you're sitting there flailing.
You can say it's disingenuous, but I used to hit that issue fairly regularly. I've seen that complaint more than once, so I assume a large subset of users did as well. Habits built over years won't vanish just because you add a track pad.
It now widens when you move the cursor near it, so they have mitigated the issue.
Sure, it's the dev's website. But the browser is my user agent, not your developer agent. It is fundamental to the purpose of a web browser that it should prioritize the wishes of the end user over those of the server.
This is exactly what's going to happen. If the site's owner for some reason looked for my business — well, the developer's priorities were different, tough luck!
Ooh, that's a bit much. The website dev is pushing their side.
No user of the site is forcing anything onto any other user of the site.
Perhaps we can have an HTTP header or something that says to the site, please don't mess with browser behaviour. Omit that and the site has got implicit permission.
The website dev is generally the one paying for and providing the website... Why is it you expect the provider to bend to the whims of the user? The user doesn't need to use the website.
That's like saying Crest should make orange toothpaste because you don't like the color. Don't buy their non-orange toothpaste.
I know, I read it. But it doesn't work like it says it does. I have Firefox with Windows 10, and the final result ('only styles obtrusive scrollbars') is way too unobtrusive for my tastes.
It sorts of look like the Windows 10 scrollbars, but is 1/5th or one quarter the size of a regular scrollbar, and is hidden among the background of the page. Not what I prefer, and what I set up in my OS settings.
Multiple scrollable areas in a window is pretty annoying in my experience. Depending on what you last clicked on and where your cursor is can result in different areas being scrolled.
That just depends on the implementation. I can think of plenty use cases for online applications which need multiple scrollbars. Sometimes you can't fit every element in one view.
I don't see how that kind of SPA is any different than a heavy pro app. Those apps often come up with their own UI scheme that people either love or hate (and usually completely ignores system preferences). A few common examples (I specifically chose Apple to illustrate) are Aperture, Logic Pro, Final Cut Pro.
You're already buying into the whole app and there's good reason to not like the design decisions they made. I also think many companies overvalue the need for it.
That's completely irrelevant. I can't imagine how ugly Blender or Photoshop's UI would become if they used my stock system scrollbars. What you're arguing over is merely a matter of preference. Some people can do it right, and pointing at the wrong examples is pointless.
But that's my point. It has a place in a very, very narrow number of applications. For those it's an all-in decision where the UI significantly changes and it's ignoring your operating system.
Photoshop for most of its history used the OS' UI paradigms. Only in the past decade or so has it adopted its own. I'm pretty sure it used the OS' scroll bars at least until CS5 around 2010.
Are you suggesting you would rather these UIs devote an unknown amount of screen real estate to various bulky OS scrollbars? That makes concise and predictable design for complex applications very difficult.
This "very, very narrow" number of applications you are suggesting is exactly what I was talking about. Those are the ones who need custom scrollbar solutions, and the way to get that done now is obtuse, brittle and hard to maintain.
> Are you suggesting you would rather these UIs devote an unknown amount of screen real estate to various bulky OS scrollbars? That makes concise and predictable design for complex applications very difficult.
In all likelihood, I probably would. I chose my OS and one reason was those conventions. Especially on the web, developers seem to make very poor decisions on when to override things like scrolling. It's reasonable if, like you said, the UI is very complex and if I'm going to spend hours using it. In practice, they mess up conventions on a single scrolling page I'm spending 2 minutes on and it's usually a clue to avoid that site in the future.
> Those are the ones who need custom scrollbar solutions, and the way to get that done now is obtuse, brittle and hard to maintain.
That /has/ to be expected if you're stomping on the conventions. If you're changing the scrollbar, you're likely significantly changing the whole UI.
> It's reasonable if, like you said, the UI is very complex and if I'm going to spend hours using it. In practice, they mess up conventions on a single scrolling page I'm spending 2 minutes on and it's usually a clue to avoid that site in the future.
Scrolljacking and replacing the scrollbar are two very different things. And the problem is that there isn't a streamlined, consistent way to replace the scrollbar, so it's always a hacky mess.
This article seems to make the assumption that the scrollbar has no value unless you are actively scrolling, but that's not the case for me. It's an important indicator that there is content left to scroll and also how far along you are in a document. I'm also not sure I like the idea of "we will make them super small and hard to use" because on my desktop I have enough screen real estate to handle losing a few pixels to the scrollbar. It's not like I'm on an old phone and every pixel is sacred.
I feel like I'm the only user on the planet who still uses "click to scroll" regularly. If I'm reading a thousand-page document, navigating by incrementally scrolling up or down is painfully slow, and using home/end key functionality requires reaching for the keyboard (and possibly using keyboard shortcuts on a laptop) and still doesn't allow me to instantly jump to the middle of the page, for example.
The fact that this is also not the OS default (clicking usually _incrementally_ scrolls towards where you click, instead of jumping) is infuriating.
Not just Firefox, all programs in Windows 10 allow shift+click to jump. The only exceptions are new UWP style scrollbars (the ones that are affected by the "Automatically hide scrollbars in Windows" setting). Fortunately I don't use any of those, other than start menu and settings. Interestingly (as mentioned in the article) EdgeHTML based Edge is not one of them, scrollbar is always visible regardless, and shift+click works.
Besides having to um, drag the mouse, is there an issue with simply dragging the visible scroll thumb/knob/thingy down or up? That said, my preferred way to get to a part of a page is CTRL+F, which really should be updated to automatically OCR images at some point in the future. It's a shame we call sites inaccessible in 2019 when we can sometimes fix such problems automatically. I'm not saying it's a permanent or good fix, but nobody's going to go into web.archive.org to update the alt text that wasn't provided in the first place... there are browser extensions, and JAWS apparently does it, but we shouldn't need to turn to commercial tools, it should be baked into the OS and browsers so it can be used more easily. And for sites that override Ctrl+F, there should be a way to override that in the addressbar as if it's a privacy/security setting, on a per-site basis. Actually, you could add such a setting for scrollbars too, but there should be limits somewhere or the settings list would just become about:config or the Registry. /endrant
> The fact that this is also not the OS default (clicking usually _incrementally_ scrolls towards where you click, instead of jumping) is infuriating.
Why? Incremental scrolling works fine for pages and files of any length, whereas click-and-jump only works well for short pages.
Try to use click-and-jump with a long document, like a book, or a long header file. You move the mouse a few pixels, click and bam it's scrolled 3,000 lines. I'd much rather have to do an extra click when reading a short page than play silly games with the scrollbar on long documents.
I like jump-to-scroll in conjunction with a mouse wheel for page-by-page scrolling. Unfortunately this combo is not as common as you'd expect, since most jump-to-scroll systems are ancient and predate the concept of the scroll wheel. Page up/Page down is an alternative to the scroll wheel, but somewhat less ergonomic when you're already clicking around a document.
At least there are some modern examples that get it right, like Firefox.
Plus, I find it pretty rare that I have a document that compresses the scroll bar that badly.
I'm not trying to argue that people who prefer a particular behaviour are wrong, just to point out why it's a valid technical choice. You may find it pretty rare that you have a document that compresses the scroll bar that badly, but there are billions of computer users in the world. An interface that's usable by everyone may be the proverbial least common denominator, but at least in this case, it is the least dysfunctional.
Not to mention how much space is already completely blank on the sides of most websites because they've constrained all the content to a narrow band in the center.
I recently enabled a feature in Sublime Text and VSCode to make the minimap always show which part of the document is on screen. By default, it only shows this when you hover the minimap.
> For designers accustomed to Mac environments but designing multi-platform web experiences, trying to make everyone happy in a way that doesn’t place a lot of performance burden on the end user can be tricky.
Well here's a recipe that, since the dawn of the GUI more than 30 years ago, has guaranteed the success of this endeavour: don't override anything that's provided by the platform.
It's extremely easy to do in a web page, it requires absolutely no coding whatsoever. You don't need to do anything, and the result looks exactly as each users expects on their platform. It also places no performance burden. And it's guaranteed to make everyone happy -- except for people who are already unhappy with their platform, which you can't really help anyway.
Can we please, please, PLEASE put an end to this endless, user-hostile masquerade?
> Minimize the real estate that a scrollbar can occupy. Windows scrollbars are obtrusive and very wide by default.
Wide and obtrusive? I'm not twenty anymore and my eyes definitely don't work as well as when I was twenty. I find them not wide at all, and definitely not obtrusive. So do many people my age or older.
You know what sucks? Thin, subtly-colored, automatically-hidden scrollbars that obscure how much is left from the current page, are hard to see when they do pop up, are hard to find and click (you don't know where the scrollbar is going to pop up when you move your mouse to the edge of the window). * Points finger at GTK and shudders *
> Respect changes to user preferences. If a user has selected non-default options for scrollbar behavior, respect those preferences when possible.
Why "when possible"? Why not all the time? If a user has gone through the trouble of configuring a non-default setting for the scrollbars, an UI element that's taken for granted to the extent that many computer users don't even know its name, does anyone honestly think it's a good idea to override these settings sometimes?
Why? What kind of information do you think you could present for the user, were it not for that pesky scrollbar?
The point that they didn't raise is that scrollbars effect the size and position of things in the browser. Try setting 100vw on an element when you have obtrusive scrollbars, the result will be a page which now has horizontal scrolling, leading to terrible UX.
That’s because the vw and vh units are obtuse, being the full viewport dimensions inclusive of document element scrollbars, and there’s no workaround for that. (There used to be in Firefox, but when the dust settled and all the browsers decided to iron out their inconsistencies, they dropped Firefox’s behaviour as potentially surprising, despite it being the only sane thing out there, and haven’t talked much about making a unit that’s actually useful for this effect.) The effect of this is that the vw and vh units are pretty close to never the right thing. I have before used CSS Custom Properties to achieve a sane result, putting `:root { --scrollbar-width: 17px }` into the document based on a JavaScript calculation, with `--vw: calc(1vw - 0.01 * var(--scrollbar-width))`, so that then you can do `calc(50 * var(--vw))` and it’s like 50vw but sane. But this technique requires JavaScript, so I don’t consider it acceptable in all places.
"Any sufficiently complicated web application contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of the browser's native behaviour."
To which I would add the adjectives outdated and brittle. It is possible, with care, to replicate almost any UX behaviour that is native to the browser or its underlying platform, but:
1. When the browser or platform changes, the "greenspunned" behaviour does not keep up, so you are either stuck with outdated behaviour, or you have to go back and update your web app to keep up.
2. Most of the high-fidelity implementations rely on a tottering jenga pile of hacks and workarounds that break in unpredictable ways when changes are made to the site's appearance (e.g. a rebranding exercise) or to the browser's underlying behaviour.
I've become very conservative about doing anything like this myself. I have extreme difficulty coming up with business justification for reïmplementing standard behaviour.
It is not my job to make scroll bars, buttons that depress when you mouse down, and especially, custom text input fields that—thanks to my meddling—don't support standard behaviour like native spell checking, copy and paste.
Now please excuse me, I've lined up a row of Geritol and Jack Daniel's ("Gerry & Jack's") shots, and it's time for a drink.
"How to change the scrollbar style", or, as I would like to call it, "it's more important that my site looks pretty than that it's usable".
Yes, if you come from MacOS, the scrollbars seem obtrusive. When you come from Windows, the entire layout of Finder looks weird as hell as well. It's what people are used to.
For anyone who wants to disable scrollbar fuckery in Firefox, you can toggle these settings in about:config
- layout.css.scrollbar-color.enabled
- layout.css.scrollbar-width.enabled
Obtrusive = useful, works as intended but it's offensive to design guys so lets swap it for an unobtrusive one.
Unobtrusive = beautiful, thin, glossy, glassy, & invisible but using it feels like lottery, or whackamole. You'll also need steady hands like a surgeon or a advanced robot to use cos its just too tiny for mouse, much less finger control. So, instead of drag-scroll, people end up tapping the scroll bar to jump around the page.
But that's not all. The user gets tired and taps the backspace button. Alas, instead of moving back, it goes to a different page because the all knowing designer messed with that too.
After a few confused back/forward presses, the user closes the tab or the browser, if the designer messed with the tab closing process.
But it's all right cos user engagement has improved!
Yes pleeease load some more megabytes of CSS and JS garbage such that the scrollbar is as tiny as possible, and most likely janky and laggy on anything but top-end machines. And when your code invariable fails to load, because of interrupts or unavailability, there's no scrolling at all.
And people without perfect eyesight or older folks can't use the side at all.
Thank you front-end designers for your continuing efforts to ruin everything good about the internet. No tech group has collectively produced so much garbage in the last decade!
> For designers accustomed to Mac environments but designing multi-platform web experiences, trying to make everyone happy in a way that doesn’t place a lot of performance burden on the end user can be tricky.
Or you could just leave things at their defaults and stop messing with native chrome and UI elements. Now that you've styled it "unobtrusively" for Windows, that's one UI element that's completely inconsistent with the rest of the OS, and for what purpose? Does a usable user interface element actually need to be a tiny capsule because that's what Apple does?
The protocols certainly influence the designs but there’s always a level of flexibility in the clients (ie, browsers) which the app devs will still have to wrangle.
Some devs value consistency across platforms so their app always looks and functions the same. But I personally think it’s best to default to the system’s UI. Sure I can make it look Mac-esque on desktop Firefox on Windows but I’d rather it look and function exactly like every other windowed application they use on the platform.
There’s also nothing inherent in using JS heavy frontends like React which encourages non-standard browser behaviour. You can still present complex interactive elements while keeping scrolling and other usability stuff like back buttons, copy/pasting, form input behaviour (not breaking LastPass and browser autocomplete for ex), not losing form data on submit after validation errors, etc. You have to go out of your way to explicitly modify default browser behaviour, usually via 3rd party libraries added on to these frameworks.
Personally I found it was far more common in the jQuery world, which is still rampant among those awful prebuilt themes people and companies always use for their websites.
Knowing that even if the hack works now it could break on future versions of the browser or different OS. So that also assumes the website will be an actively developped website forever.
> Knowing that even if the hack works now it could break on future versions of the browser or different OS. So that also assumes the website will be an actively developped website forever.
This rather is a hack to make your job much more secure.
It's also a fun bit of "everything old is new again". The scrollbar color CSS this points out for Firefox originated somewhere in IE 3-6 when Windows 9X was briefly encouraging fun with scrollbar colors to better match content and there was a lot of applications that did so on Windows (it was the early WinAMP, Napster, etc era). Other platforms complained about how "tacky" such CSS was, and by the time Firefox implemented it most people thought it was a bad idea of the BLINK/MARQUEE school. It's almost strange this time to see it from the other direction of macOS web devs wanting more Mac-like scroll bars everywhere.
When you have a dark-theme-ish website, then the bright scrollbars suck, especially if you got more than one (e.g. two scrollable columns). So you need to do something or else a lot of users will complain or just leave.
I've seen you post this particular issue twice in this thread. Perhaps it's not the scrollbars' fault that setting an element's width to 100vw (which is 100% of viewport width) usually requires a scroll? The scrollbars are a symptom that you are setting your child element width too high. Try 100% instead, which should make it 100% of the parent size.
If your intent is to set an element to 100% viewport width with no scrollbar, that's trivially easy to do without jacking around with scrollbar styles.
Seems like the Mac-based designers were a bit too fixated on the issue of scrollbar appearance and this tech team had to figure out a workaround.
Speaking of web scrollbars: One of the many reasons I hate modal dialogs ('lightboxes') on webpages is that they mess up scrolling behavior. Sometimes they accidentally close themselves if you hit the scrollbar, sometimes something else happens...
Interestingly in mobile web design, having a scrollable box inside a document doesn't really work that great (in fact I am typing this on HN on my phone and the fact that this text input is too small for my comment & scrollable makes it tricky to read and edit.) So this forces us to think about other ways to make boxes expandable. One solution I've used is showing eg. 40px of the box then a button to expand it in place in the page, where it can be browsed using the document scrolling behavior, instead of showing a 200px height box with its own scrollbar.)
As a desktop user of Firefox on Linux I found the two demos with the modified scrollbars subjectively worse than default. As a user I use the scroll bar to (1) identify if a section can be scrolled, (2) identify where in the section I am with regards to the scroll height, and if needed (3) manually scroll by clicking on the scroll bar and dragging with the mouse. The two demos retain these three capabilities but for me make them more difficult and less efficient.
I agree with what other users have said: please do not touch my scrollbars.
I like obtrusive scrollbars that the browser provides. As well as toolbars and full menus, and separate search and address bars, and address bars that actually have the full address in them, and status bar that tells me a useful status. Most importantly none of those elements should be able to be affected by the site im visiting.
If modern UI designers were making a car they would replace the fuel gauge with just the light saying you need gas, the RPMs would be gone completely, and the speedometer would just say to hurry up or slow down.
Especially given the sizes of today’s desktop monitors and their ability to use various grays and low key colors to draw items, there’s nothing “undesirably prominent” about permanently showing user controls.
In fact, there’s a case to be made to show more controls. That’s why we got tool bars, and why Microsoft turbo-charged it to the ribbon.
My rule is, whenever I find myself putting things into categories with names that are judgemental/subjective, that's usually a sign that my thinking on the subject is flawed somehow. Calling them "obtrusive" and "unobtrusive" scrollbars is just another way to call them "bad" and "good" scrollbars; it says more about the biases of the author than it does about the scrollbars themselves.
Reply to self: many programs have realized this, too, and added _enormous_ scroll bars, in the form of a “Show Thumbnails” feature (examples: MS Word and PowerPoint, Mac OS Preview and Pages) or as a “minimap” (https://en.wikipedia.org/wiki/Mini-map#Code_Minimap_in_Text_...)
> Obtrusive scrollbars: scrollbars that take up screen real estate. These do not overlay on top of the content, but appear next to it.
> Unobtrusive scrollbars: scrollbars that sit on top of the content. These don’t subtract screen real estate away from the container they belong to.
See, I would call "scrollbars covering content" to be obtrusive and "scrollbars outside of the content area" to be unobtrusive...
The main scroll bar in my browser should be completely off limits, and treated as part of the browser and not the page. Divs inside the page with their own scrollbars are another matter, but even then...
As a webdev (albeit a noob) I just leave the scroll bar to its own devices with ONE EXCEPTION.
I hate the "pop" you get when the scroll bar isn't there, and then suddenly there is enough content to scroll and the scroll bar shifts everything to the left. It's not easy to account for for a given page when that may or may not occur when say you show some new content and then suddenly things shift left.
It's a pain visually so I just force it to appear regardless.
>Minimize the real estate that a scrollbar can occupy. Windows scrollbars are obtrusive and very wide by default.
Wide scrollbars are a blessing. Better to lose a couple pixels, a fraction of a percent of screen space, than have to constantly line up your cursor over a tiny, yet essential and frequently-used UI tool. I can't stand those dainty little ovals on Mac OS, it's like having to constantly slow down whatever I'm trying to do to thread a needle. It blows my mind that everyone is constantly trying to throw away effortlessly responsive function for such stupidly picky details of form, according to an arbitrary standard of pure aesthetics. Scrollbars should always remain visible and wide.
This was interesting until he started mentioning CSS, then it was no no no no no through the end of the article. Do not mess with scrollbars.
In the same class of annoying bullshit: don't mess with text boxes with JavaScript. You won't get it right, there's so many little interactions the system text boxes can do that yours won't and it'll throw a massive wrench into things when I can't use yours the way I'm used to.
The same applies to JavaScript for smooth scrolling. There's a browser preference, turn it off for yourself and then keep your nose out of my web browser.
The "know-better" attitude of some web devs is terrible.
> Obtrusive scrollbars: scrollbars that take up screen real estate. These do not overlay on top of the content, but appear next to it.
> Unobtrusive scrollbars: scrollbars that sit on top of the content. These don’t subtract screen real estate away from the container they belong to.
I work mostly on the front end, and I recently ran into a bug where a scrollbar would alternate between these two behaviors depending on screen width, the page's CSS, and when the DOM was redrawn.
I'm generally interested in moving away from FE work, and I must admit that part of it is to increase the distance between me and scrollbars.
Annoyingly on Chrome the flag to enable auto-hiding scrollbars on Windows is being deprecated and in Chrome Canary is already at the point you have to enable the flag to enable soon to be removed flags to even select it anymore.
This seems to be moving in the opposite direction from how the platforms it runs on are evolving :/.
> Moreover, touch devices have popularized hiding the scrollbar, making it invisible until an overflowing element is scrolled, trading design aesthetics for confusion on containers that don’t appear to be overflowing/scrollable at all.
Not a touch device, but I couldn't find a file in Finder because it was off-window and the window had no scroll bars, implying I'm seeing everything.
Something I noticed the other day. If you watch the credits for Ralph Breaks the Internet, it has a scroll bar on the right that accurately reflects the current position in relation to the entire credit roll.
These articles make me feel like I'm the only person on Earth who's never had a problem with my scrollbars. Do they have to fix things that aren't broken for people?
Mac scrollbars are terrible for accessibility. They're way too small, larger scrollbars help users with dexterity/mobility disabilities. I like the windows behavior because for me its reliable, I know where it "is," and yeah I object to "scrolljacking."
After trying the demo and comparing those two implementations I came to conclusion that I really like standard system scrollbars waaay more. Thanks for respecting my own settings and please don't style scrollbars.
> The scrollbar is under attack. Scrolljacking hijacks the default scrolling behavior, breaking the implied contract between document length and scrollbar height.
…
...so here's how we hijacked system-provided scrollbars to fit our needs.
> On Windows 10, a similar preference exists in Settings → Display → Simplify and personalize Windows. Unfortunately even with this preference checked, it had no effect on scrollbar behavior in Firefox, Chrome, in Internet Explorer and Edge—whether Chromium or EdgeHTML based.
So either this option isn't exposed to applications or browsers (including MS' own) aren't making use of it. Either way this is an issue that I'd like to see resolved.
There's another alternative: it's just broke. Considering how frequently Microsoft breaks its own OS while blundering around trying to implement the latest who-gives-a-shit anti-feature in time for their bi-annual in-place reinstall shitshow, it wouldn't be surprising.
>it isn't exposed to browsers
well, I have a strong position that it should not be exposed to browser. Exposure of system settings/preferences should be minimized as this provides additional user-profiling opportunities.
Exposed to the browser doesn't have to mean it's exposed to websites. The browser has access to all sorts of system settings that websites aren't allowed to view. Although admittedly it's hard to disguise scrollbar behaviour if it affects the page width.
No one has surpassed the SGI scrollbars from ancient times. When you moved it, it left an indent of where you were so you could go back easily or compare two pages. Also could middle click to go directly instead of page. That’s still available on some floss desktops but gnome broke that at some point. Still works under mate.
I checked out the demo, it turns out this is for something reminiscent of frames rather than the main scrollbar.
Just stop, don't have internal or nested scrollbars at all. Having part of the page scroll independently of the rest is a usability nightmare anyway, especially when you consider how it interacts with zooming.
While the content is interesting, by far the most useful thing I learned from this article is that you can turn off unobtrusive scrollbars on a mac. I have to use one at work, and turning off this feature makes me hate my computer less by a significant amount :)
I think the proposal for scrollbar-width:thin is good enough for cases where you have a secondary scrollable area in your site or application. Styles beyond that will just become too confusing.
You can have my scrollbar when you pull it from my cold, dead, GUI. If I don't have a scrollbar visible (with or without cursor), I'd better be in console.
The iOs hidden scrollbar is a pain. As a web developer, it caused issues because Safari will reflow the content when the scroll bars appear and disappear since the amount of space they take up changes.
Oh believe me, for the information dense designs I’m working from, and needing to support a baseline desktop resolution, every pixel matters! I would never want to take that out on someone’s scrollbars tho. Scrollbars are sacred.
All well and good for you but our author here is working with 40-50% whitespace anyway! Why the hell does he need to hide and minimize fundamental features to reclaim more fucking whitespace? Aaaaargh, designers are from a different species!
if you use firefox on android, about:config has a "scrollbar timeout" setting that you can set to 0 or -1... now you will have an always visible scrollbar.
you must force close firefox before it takes effect.
I am of the opinion that you should not mess with my scrollbars. I like them to be visible and wide, because (a) I like to know a page's length and my current progress, and (b) I'm a bit blind and I don't want to hunt for an 'unobtrusive' scrollbar.
There are options at the system level, I find it great that most browsers follow them and sites cannot willy-nilly change them without my consent.
I like macOS/iOS's hidden scrollbars personally, but I agree with you about not wanting pages to be able to override scrollbar behavior in any manner. The way my scrollbars work is perfectly fine and, more importantly, predictable, and I don't need web pages changing that on their creators' masturbatory whims.
Too bad Google once again leads the way of being a prominent example of a bad idea with its custom scroll bars on many of its properties.
I used to like MacOS's subtler than Windows approach to scrollbars, but they became too subtle. They were lovely in Snow Leopard: Gently aqua coloured, arrows, large enough for middle aged (or overworked, and in a hurry) eyes. Obvious.
Then they went to Lion and ruined them: grey and almost invisible by design. Magical mystery popping into existence when you hover where it ought to be. Probably. I think this is when they inverted the magic mouse scroll behaviour to pretend like your iMac was an iPhone.
I've had the setting flipped to always show them since they added that nonsense. It looks a bit more subtle, and isn't brightly colored, but it serves the important role of showing at a glance how long the page is.
The backwards scrolling is way more obnoxious though, and I rage every time I use someone else's Mac or do a fresh install.
Aye, me too. Though I prefer when they were a little more obvious - now they're a background visual indicator, and essentially deprecated as a control, for being too narrow.
Most of the times I encounter backward scrolling on someone else's Mac, it's only there because they never realised Settings let you invert it to sane and useful!
The “backward” scrolling (a better name might be “content scrolling” as compared to “window scrolling”) was changed because the “forward” way does not work for scrolling content on a multi-touch display. If the content moves in the opposite direction from the finger, it completely breaks the illusion that the fingers are directly controlling the content.
People switching back and forth between Macs and iPhones or iPads initially found it very inconvenient/frustrating to have window scrolling on a touchpad and content scrolling on a touchscreen.
It was decided that switching the Mac to be consistent with iOS would cause momentary frustration for Mac users (it requires a few days of retraining to get used to) but would be less frustrating for most users than preserving two inconsistent behaviors into perpetuity.
The option to keep the Mac on window scrolling was included to mollify those few Mac users unwilling to spend a few days or weeks re-training themselves to a reversed gesture.
The problem is that my mental model for scrolling on a touchpad is different than scrolling on a phone/tablet. My finger isn't touching the content, it's touching a scroll device. It never stops feeling backwards to use a touchpad and have the scroll go backwards.
Interesting, it very quickly became so normal to me it felt odd we'd ever done it the other way. I find it very weird working the other way now.
On a macbook with a big touchpad it sure as heck feels like touching the content. Esp. with fluid gestures (not abrupt like windows) and pinching it feels very physical. And then flicking with two fingers and the inertia of the page that keeps on scrolling because you pushed it very hard feels satisfying. On windows it just feels fake.
Anecdotally, several people I have talked to about this had no problem with the new behavior (after a relatively short re-training time), but did find switching between touchcreens and touchpads with opposite behaviors frustrating.
If you do have a problem, then you can switch it in System Preferences. Everyone wins.
The biggest problem, in my opinion, is that there appear to be two settings, one for trackpad, and one for a mouse scrollwheel. You can find them in different locations. They change the same value, though. You can't have natural trackpad scrolling and "pull the wheel towards you to scroll down" scrolling at the same time without a 3rd-party application.
> they inverted the magic mouse scroll behaviour to pretend like your iMac was an iPhone.
These are UI/UX conventions. Everything is "pretend".
For example, users whose mental model of scrolling tracks the viewport will want to scroll up to move the content down. The viewport goes in the opposite direction of the content.
Fair enough.
However such users don't seem to want the same for horizontal scrolling. Tracking the viewport left moves the content to the right and vice versa. But horizontal scrolling in macOS always tracks the content regardless of the setting in System Preferences > Trakcpad > Scroll direction: Natural.
The exception (turning it off for "inverted" scrolling or "viewport tracking") is only for vertical scrolling, not horizontal, which suggests the mental model can be adapted though users who prefer viewport tracking report they cannot adjust.
Sure, perhaps if I had known nothing else... Except it's not a convention any other platform ever followed.
Of the few people I've bumped into who had it set to natural, and had for some considerable time, well even those were happy to learn it could be changed, and didn't want to go back. So there's probably something makes it feel odd, and stay feeling odd, for many. What I couldn't say, but not just restricted to those who spent time on other platforms too, like me. Of people whose machines I get to use from time to time at work, they're all set to unnatural too. We're nearly all iPhone users. So it's not just me being odd and rare edge case. :)
Personally, I don't want the same mental model between phone and desktop, as the metaphors are different. UI should look different, act different, suited to using each device. The Win 8 on, Lion on desire to make my laptop "feel" more like a mobile, continues to feel like a huge mistake.
> But horizontal scrolling in macOS always tracks the content regardless of the setting in System Preferences > Trakcpad > Scroll direction: Natural.
I don't think this is correct.
The setting affects both vertical and horizontal scrolling.
The joke is that they call that ‘natural’ scrolling. That is literally the most unnatural movement I can imagine.
You can change the default OS X behavior in System Preferences -> General. I like to have scrollbars always showing.
I agree with this, so based on the article I think that browsers should respect the Windows setting since it's an expression of the user's preferences. Other than that, I have a strong preference that webpages don't try to style the scrollbar (with exceptions when it really makes sense).
> I have a strong preference that webpages don't try to style the scrollbar (with exceptions when it really makes sense).
That's the crux of the problem: the only time a website makes changes to the scrollbar is when the author thinks it makes sense.
I just disagree all of the time.
One site I've thought it made sense was in Discord, which acts as a properly themed web app and where the clash of certain native scrollbars would be jarring (eg: bright scrollbars on a dark theme). That said the scroll bar it uses for the user list is microscopic compared to the one used for the message log, which is a baffling decision.
For every other regular site, and even most web apps, I always prefer native, for Windows.
Well, no problem in making all those styling rules opt-in. When it really makes sense, you can choose to use the author's UI. Apply that for colors too.
Applications should respect the DE settings for UI. Browsers are the main culprits here, but only because CAD software isn't widely used. Oh, and there's MS Office, that will respect absolutely nothing. All of those are in the wrong. But everywhere the DE is powerless to enforce its style onto applications, so this is a much harder problem to fix;
Personally I think the main page's scrollbar should be handled by the OS. For any element inside the page, I think it's ok for the site to handle how the scroll works to make it consistent with the page's design.
I really dislike these, they're too narrow and difficult to scroll manually
I have some dev tools that do infinite scrolling and I wish I had the authors here to tell them how fucking stupid I think they are.
If the page is long enough for infinite scrolling, I'm probably going to have a slightly error-prone recollection of the exact string of text I'm looking for. Taking search away from me makes this worse.
There's a bit of psychology that says when someone is experiencing a strong emotion, good or bad, they will associate it with a person nearby, whether they deserve it or not. This has applications from espionage to team building to crisis management.
One of the wrinkles of this is that if someone is already or almost experiencing a strong emotion and you add to it in any way, you've made yourself a target.
One of the things I tell mentees about code and test quality (especially the latter) is that in the grand scheme of things, nobody (read: a tiny fraction) is going to look at your code for fun. They're going to look at it because something bad happened, near it or in it.
Assume the person reading your code is already having a bad day. Don't make it worse. Especially if it ends up having nothing to do with you.
The infinite scroll bozos, at least in the scope of productivity tools, are making my not-great day worse. The ones that 'fix' this by hijacking CTRL-F and do their own half-assed implementation of search are just doubling down. If you're going to listen on CTRL-F, maybe force-update the entire list instead?
Please name these tools, thank you.
Atlassian for one. Their old code viewer was a disaster but that might have been Bitbucket’s fault. The repository list lazy loads, and if you’re at a big enough company the repositories get into multiple projects and it’s always disorganized. Which project is this repo in again? Time to hunt around and oh yeah CTRL-F doesn’t work unless you remember to scroll to the bottom repeatedly.
Most of the time the scrollbar is so damn narrow that sometimes I am having troubles positioning my cursor on it, seriously! It is hidden by default, AND narrow. I have difficulties making it appear and use it for scrolling. I move my cursor by one pixel, and it disappears again, sometimes I have to fsck around with it for way too long.
Yeah, stop messing with my scrollbar.
Yeah, the unobtrusive scrollbars make sense only if you're using a multitouch touchpad or Apple's mouse — as soon as I have to use e.g. some office's basic mouse, chasing those unobtrusive becomes a major pain, to the point I wish Macs would switch to traditional scrollbars if I connect a "plain" mouse. Not that it matters: modern websites tend to completely break scrollbars.
I completely agree. I'm questioning whether I'm curmudgeon for feeling this way, but the only time I notice scrolling customizations is when they mess up scrolling--which is surprisingly often and also seems intentional most of the time.
I understand the motivation for controlling the experience, but I really think designers are undervaluing consistency. It feels like the car I drive every day acts different on one road. Sure, there's a very tiny chance it's an improvement if a lot of time and thought has been invested, but in all likelihood it's just very jarring.
The article covers these points in great detail and spends significant time avoiding exactly what you describe with it's final workaround.
The core problem, as I see it, is of someone else deciding that "unobtrusive" scrollbars are better.
On a mac, to actually grab the scroller for scrubbing, you need to scroll a bit to make it visible and then manage to bring your cursor into a tiny area using the trackpad within a few seconds before the scroller disappears. If you miss, clicking activates window resizing.
UIs need to be functional first. Being pretty should never trump being functional.
On a Mac, this is configurable. The article talks about this, and about respecting user configuration when possible.
> configurable
I mean, if I write an app and hide a "dysfunctional prettiness [Y/n]" configuration somewhere in settings, is that a good thing?
I'd argue there are at least two better options that are trivial to implement, and surely more if one cares to do UX due diligence when trying some novel design.
Are you sure it’s dysfunctional?
With Mac they can generally influence the scrolling interface by making one of the best trackpads and magic mice standard, where scrolling is a critical part and not an afterthought, plus lots of visuals showing how to scroll with it.
You really don’t need to click and drag the scrollbar very often if at all. Especially for page scrolling which the article explained - it’s more important for overflowed objects, especially horizontal ones. And if you need to scroll there’s no guarantee that having 25px control design vs 50px (guessing) like windows would help, the click area tends to be a wide as the bar part not the control.
I'd argue there are at least two better options...
Wasn't your original complaint that someone decided what was "better"? Or are you complaining that they didn't take your choice? Point being that someone that decided otherwise thought they had a good reason for their decision, too. In this case, it could be argued that trackpads reduce the need for the scrollbars. (I have no idea what the real argument for such UI behavior is.)
I'm talking in generalities. The status quo used to be "scrollbars are visible things". If you're going to change the status quo, it behooves avoiding a dark pattern (like e.g. privacy settings turned off by default). The two better options for UX changes (generally) are to leave it alone, or to create a configuration that defaults to the old way of doing things. You probably heard again and again of some random company doing some major redesign with good intentions and ending up pissing off users.
In my experience, the backdrop in many of those cases is that UX changes get rolled out because people need to justify their jobs or they think X is prettier/popular. You don't hear nearly as much about people doing UX research as you do of people cranking out React things, and it would be extremely benevolent to assume developers do in fact do expensive, time consuming UX sessions w/ users.
If we talk specifically about scrollbars, maybe a good litmus test is this:
- if the default was no scrollbar whatsoever, would that be a problem for you?
- if the default was a read-only scrollbar (e.g. it merely reports whereabouts in the page you are, but does not respond to mouse events), would that be a problem for you?
If the answer to either of those is "no", you probably aren't actually using it. They could conceivably be configurations too, but why?
Consider this hypothetical parallel: why not hide the "Help" menu item in apps? Personally, I don't use it and it would clean up the UI, so it must be fine, right? Well, not necessarily. Because if you bother to do UX sessions w/ users, you may find that people looking to use that specific feature will have expectations about where it should be.
People changed their interaction after mice and trackpads started to universally include a built-in scroll wheel / scroll gesture.
In 1990, everyone scrolled up or down by clicking little buttons at the ends (or at one end) of the scrollbar, or by dragging the scrollbar up and down. By 2019, these buttons are unnecessary and have been removed, and the main purpose of the scrollbar is to passively report the position in the page. Dragging it up and down still works, but few people bother.
I did not know this, but I am apparently one of those few people who use a scrollbar to point to a location where I need to be. Either in source code, manuals, even on some vendors web pages I know the tech specs and the link to the datasheet is 2/3 of the page so I drag or click the scrollbar. In documents, or on webpage I have a mental image of where the scrollbar was when I read it, like page numbers in a book and I use it a lot. And no this is not substituted by scrolling with a mouse wheel or heaven forbid a track-pad. If I know I need to find something at 'M' I do not want to go through all the stacks starting at 'A'. Just saying we have been organizing content for a lot longer than the UX people telling us what we do not need.
Scrollbars are a tool and they should be functional: visible, properly sized and interactive. It helps if a scrollbar looks and functions the same on all our content, because it takes less mental strain to use.
It may be that you don't like scrollbars for your content. The obvious solution is to make your content fit so it does not require scrollbars. If you cannot manage that you will have to live with the fact that scrollbars are there as a functional tool and make sure it is kept functional. In analogy: If I sell furniture you have to self assemble I can choose to design it to not require tools. If it does require tools I should make sure people can actually use those tools to assemble and not try to hide that tools should be used by pretending the thing to put nails in is not a hammer.
I have almost forgotten that it’s even an option to click and drag! On my trackpad I use two-finger scroll, and my scroll-shell mouse can handle horizontal scroll just fine.
But honestly even then it’s not common for me to run into those. I’m a keyboard user, so the thing I get persnickety over is whether or not you got your focus order right, if you steal keyboard focus senselessly, or if you made a UI that only responds to mouse clicks.
It's configurable operating-system wide, and the system default is to hide the scrollbar, which is terrible.
Being pretty helps the first impression in an Apple store, and for first few days.
When a user realizes that a scrollbar may be a useful feature, but it's somehow hard to obtain, it's too late to complain, and the Stockholm syndrome kicks in.
> On a mac, to actually grab the scroller for scrubbing, you need to scroll a bit to make it visible and then manage to bring your cursor into a tiny area using the trackpad
This complaint looks disingenuous to me. If you're using a trackpad, you already have scrolling built in and the scrollbar is there primarily for visual feedback.
The reason that scrollbars can now be invisible by default is exactly _because_ of the ubiquity of touchpads and mice with built-in scrolling.
Scrolling yes, but not scrubbing. The latter is a feature that people use for navigating very large pages (e.g. I may remember the rough location of some section of some programming language spec that I'm looking to consult, but the spec is 500 pages long)
> This complaint looks disingenuous to me. If you're using a trackpad, you already have scrolling built in and the scrollbar is there primarily for visual feedback.
For short scrolling, that's fine. For long documents, you're sitting there flailing.
You can say it's disingenuous, but I used to hit that issue fairly regularly. I've seen that complaint more than once, so I assume a large subset of users did as well. Habits built over years won't vanish just because you add a track pad.
It now widens when you move the cursor near it, so they have mitigated the issue.
You're (IMO) missing the point. I decide because it my machine. It is not your machine; respect that and everyone will be happy.
The opposite is true as well - it's the web developers website. If you don't like how they style the scrollbars...don't use it.
Sure, it's the dev's website. But the browser is my user agent, not your developer agent. It is fundamental to the purpose of a web browser that it should prioritize the wishes of the end user over those of the server.
> It is fundamental to the purpose of a web browser that it should prioritize the wishes of the end user over those of the server.
No it isn't. It's fundamental to your preference. Your preference doesn't supersede others'. Don't use a website if you don't like it.
This is exactly what's going to happen. If the site's owner for some reason looked for my business — well, the developer's priorities were different, tough luck!
Interesting point (upvoted too).
Are you a web dev?
No, and I generally agree with the sentiment that poor UX is bad for the user.
I just disagree with users pushing their palate onto others. That's not how it should work.
Ooh, that's a bit much. The website dev is pushing their side.
No user of the site is forcing anything onto any other user of the site.
Perhaps we can have an HTTP header or something that says to the site, please don't mess with browser behaviour. Omit that and the site has got implicit permission.
The website dev is generally the one paying for and providing the website... Why is it you expect the provider to bend to the whims of the user? The user doesn't need to use the website.
That's like saying Crest should make orange toothpaste because you don't like the color. Don't buy their non-orange toothpaste.
I know, I read it. But it doesn't work like it says it does. I have Firefox with Windows 10, and the final result ('only styles obtrusive scrollbars') is way too unobtrusive for my tastes.
It sorts of look like the Windows 10 scrollbars, but is 1/5th or one quarter the size of a regular scrollbar, and is hidden among the background of the page. Not what I prefer, and what I set up in my OS settings.
>I like to know a page's length
This is not your concern, you should spend more time looking at the ads. /s
But what about an SPA with potentially multiple scrollable areas? Sometimes a simple, sleek visual indicator makes for more readable UI.
Multiple scrollable areas in a window is pretty annoying in my experience. Depending on what you last clicked on and where your cursor is can result in different areas being scrolled.
That just depends on the implementation. I can think of plenty use cases for online applications which need multiple scrollbars. Sometimes you can't fit every element in one view.
I don't see how that kind of SPA is any different than a heavy pro app. Those apps often come up with their own UI scheme that people either love or hate (and usually completely ignores system preferences). A few common examples (I specifically chose Apple to illustrate) are Aperture, Logic Pro, Final Cut Pro.
You're already buying into the whole app and there's good reason to not like the design decisions they made. I also think many companies overvalue the need for it.
That's completely irrelevant. I can't imagine how ugly Blender or Photoshop's UI would become if they used my stock system scrollbars. What you're arguing over is merely a matter of preference. Some people can do it right, and pointing at the wrong examples is pointless.
But that's my point. It has a place in a very, very narrow number of applications. For those it's an all-in decision where the UI significantly changes and it's ignoring your operating system.
Photoshop for most of its history used the OS' UI paradigms. Only in the past decade or so has it adopted its own. I'm pretty sure it used the OS' scroll bars at least until CS5 around 2010.
Are you suggesting you would rather these UIs devote an unknown amount of screen real estate to various bulky OS scrollbars? That makes concise and predictable design for complex applications very difficult.
This "very, very narrow" number of applications you are suggesting is exactly what I was talking about. Those are the ones who need custom scrollbar solutions, and the way to get that done now is obtuse, brittle and hard to maintain.
> Are you suggesting you would rather these UIs devote an unknown amount of screen real estate to various bulky OS scrollbars? That makes concise and predictable design for complex applications very difficult.
In all likelihood, I probably would. I chose my OS and one reason was those conventions. Especially on the web, developers seem to make very poor decisions on when to override things like scrolling. It's reasonable if, like you said, the UI is very complex and if I'm going to spend hours using it. In practice, they mess up conventions on a single scrolling page I'm spending 2 minutes on and it's usually a clue to avoid that site in the future.
> Those are the ones who need custom scrollbar solutions, and the way to get that done now is obtuse, brittle and hard to maintain.
That /has/ to be expected if you're stomping on the conventions. If you're changing the scrollbar, you're likely significantly changing the whole UI.
> It's reasonable if, like you said, the UI is very complex and if I'm going to spend hours using it. In practice, they mess up conventions on a single scrolling page I'm spending 2 minutes on and it's usually a clue to avoid that site in the future.
Scrolljacking and replacing the scrollbar are two very different things. And the problem is that there isn't a streamlined, consistent way to replace the scrollbar, so it's always a hacky mess.
There are products where the users do really want this experience. Finance folk love dense information displays.
This article seems to make the assumption that the scrollbar has no value unless you are actively scrolling, but that's not the case for me. It's an important indicator that there is content left to scroll and also how far along you are in a document. I'm also not sure I like the idea of "we will make them super small and hard to use" because on my desktop I have enough screen real estate to handle losing a few pixels to the scrollbar. It's not like I'm on an old phone and every pixel is sacred.
I feel like I'm the only user on the planet who still uses "click to scroll" regularly. If I'm reading a thousand-page document, navigating by incrementally scrolling up or down is painfully slow, and using home/end key functionality requires reaching for the keyboard (and possibly using keyboard shortcuts on a laptop) and still doesn't allow me to instantly jump to the middle of the page, for example.
The fact that this is also not the OS default (clicking usually _incrementally_ scrolls towards where you click, instead of jumping) is infuriating.
In Firefox you can ctrl+click or shift+click the scroll track to switch between incremental and absolute scroll behaviour. Maybe not all OSes though.
Not just Firefox, all programs in Windows 10 allow shift+click to jump. The only exceptions are new UWP style scrollbars (the ones that are affected by the "Automatically hide scrollbars in Windows" setting). Fortunately I don't use any of those, other than start menu and settings. Interestingly (as mentioned in the article) EdgeHTML based Edge is not one of them, scrollbar is always visible regardless, and shift+click works.
Besides having to um, drag the mouse, is there an issue with simply dragging the visible scroll thumb/knob/thingy down or up? That said, my preferred way to get to a part of a page is CTRL+F, which really should be updated to automatically OCR images at some point in the future. It's a shame we call sites inaccessible in 2019 when we can sometimes fix such problems automatically. I'm not saying it's a permanent or good fix, but nobody's going to go into web.archive.org to update the alt text that wasn't provided in the first place... there are browser extensions, and JAWS apparently does it, but we shouldn't need to turn to commercial tools, it should be baked into the OS and browsers so it can be used more easily. And for sites that override Ctrl+F, there should be a way to override that in the addressbar as if it's a privacy/security setting, on a per-site basis. Actually, you could add such a setting for scrollbars too, but there should be limits somewhere or the settings list would just become about:config or the Registry. /endrant
> The fact that this is also not the OS default (clicking usually _incrementally_ scrolls towards where you click, instead of jumping) is infuriating.
Why? Incremental scrolling works fine for pages and files of any length, whereas click-and-jump only works well for short pages.
Try to use click-and-jump with a long document, like a book, or a long header file. You move the mouse a few pixels, click and bam it's scrolled 3,000 lines. I'd much rather have to do an extra click when reading a short page than play silly games with the scrollbar on long documents.
I like jump-to-scroll in conjunction with a mouse wheel for page-by-page scrolling. Unfortunately this combo is not as common as you'd expect, since most jump-to-scroll systems are ancient and predate the concept of the scroll wheel. Page up/Page down is an alternative to the scroll wheel, but somewhat less ergonomic when you're already clicking around a document.
At least there are some modern examples that get it right, like Firefox.
Plus, I find it pretty rare that I have a document that compresses the scroll bar that badly.
I'm not trying to argue that people who prefer a particular behaviour are wrong, just to point out why it's a valid technical choice. You may find it pretty rare that you have a document that compresses the scroll bar that badly, but there are billions of computer users in the world. An interface that's usable by everyone may be the proverbial least common denominator, but at least in this case, it is the least dysfunctional.
option+clicking the scrollbar does that. doesn't prevent you from having to reach for the keyboard though..
Not to mention how much space is already completely blank on the sides of most websites because they've constrained all the content to a narrow band in the center.
I recently enabled a feature in Sublime Text and VSCode to make the minimap always show which part of the document is on screen. By default, it only shows this when you hover the minimap.
> For designers accustomed to Mac environments but designing multi-platform web experiences, trying to make everyone happy in a way that doesn’t place a lot of performance burden on the end user can be tricky.
Well here's a recipe that, since the dawn of the GUI more than 30 years ago, has guaranteed the success of this endeavour: don't override anything that's provided by the platform.
It's extremely easy to do in a web page, it requires absolutely no coding whatsoever. You don't need to do anything, and the result looks exactly as each users expects on their platform. It also places no performance burden. And it's guaranteed to make everyone happy -- except for people who are already unhappy with their platform, which you can't really help anyway.
Can we please, please, PLEASE put an end to this endless, user-hostile masquerade?
> Minimize the real estate that a scrollbar can occupy. Windows scrollbars are obtrusive and very wide by default.
Wide and obtrusive? I'm not twenty anymore and my eyes definitely don't work as well as when I was twenty. I find them not wide at all, and definitely not obtrusive. So do many people my age or older.
You know what sucks? Thin, subtly-colored, automatically-hidden scrollbars that obscure how much is left from the current page, are hard to see when they do pop up, are hard to find and click (you don't know where the scrollbar is going to pop up when you move your mouse to the edge of the window). * Points finger at GTK and shudders *
> Respect changes to user preferences. If a user has selected non-default options for scrollbar behavior, respect those preferences when possible.
Why "when possible"? Why not all the time? If a user has gone through the trouble of configuring a non-default setting for the scrollbars, an UI element that's taken for granted to the extent that many computer users don't even know its name, does anyone honestly think it's a good idea to override these settings sometimes?
Why? What kind of information do you think you could present for the user, were it not for that pesky scrollbar?
The point that they didn't raise is that scrollbars effect the size and position of things in the browser. Try setting 100vw on an element when you have obtrusive scrollbars, the result will be a page which now has horizontal scrolling, leading to terrible UX.
That’s because the vw and vh units are obtuse, being the full viewport dimensions inclusive of document element scrollbars, and there’s no workaround for that. (There used to be in Firefox, but when the dust settled and all the browsers decided to iron out their inconsistencies, they dropped Firefox’s behaviour as potentially surprising, despite it being the only sane thing out there, and haven’t talked much about making a unit that’s actually useful for this effect.) The effect of this is that the vw and vh units are pretty close to never the right thing. I have before used CSS Custom Properties to achieve a sane result, putting `:root { --scrollbar-width: 17px }` into the document based on a JavaScript calculation, with `--vw: calc(1vw - 0.01 * var(--scrollbar-width))`, so that then you can do `calc(50 * var(--vw))` and it’s like 50vw but sane. But this technique requires JavaScript, so I don’t consider it acceptable in all places.
"Any sufficiently complicated web application contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of the browser's native behaviour."
To which I would add the adjectives outdated and brittle. It is possible, with care, to replicate almost any UX behaviour that is native to the browser or its underlying platform, but:
1. When the browser or platform changes, the "greenspunned" behaviour does not keep up, so you are either stuck with outdated behaviour, or you have to go back and update your web app to keep up.
2. Most of the high-fidelity implementations rely on a tottering jenga pile of hacks and workarounds that break in unpredictable ways when changes are made to the site's appearance (e.g. a rebranding exercise) or to the browser's underlying behaviour.
I've become very conservative about doing anything like this myself. I have extreme difficulty coming up with business justification for reïmplementing standard behaviour.
It is not my job to make scroll bars, buttons that depress when you mouse down, and especially, custom text input fields that—thanks to my meddling—don't support standard behaviour like native spell checking, copy and paste.
Now please excuse me, I've lined up a row of Geritol and Jack Daniel's ("Gerry & Jack's") shots, and it's time for a drink.
"How to change the scrollbar style", or, as I would like to call it, "it's more important that my site looks pretty than that it's usable".
Yes, if you come from MacOS, the scrollbars seem obtrusive. When you come from Windows, the entire layout of Finder looks weird as hell as well. It's what people are used to.
For anyone who wants to disable scrollbar fuckery in Firefox, you can toggle these settings in about:config - layout.css.scrollbar-color.enabled - layout.css.scrollbar-width.enabled
How is finder's UI related to scrollbars?
He was just making a point, that stuff kinda feels weird when you are not used to it, not that finders UI is weird.
It's an example of UI design conflicting with your expectations as a user are about how things should look and work.
Obtrusive = useful, works as intended but it's offensive to design guys so lets swap it for an unobtrusive one.
Unobtrusive = beautiful, thin, glossy, glassy, & invisible but using it feels like lottery, or whackamole. You'll also need steady hands like a surgeon or a advanced robot to use cos its just too tiny for mouse, much less finger control. So, instead of drag-scroll, people end up tapping the scroll bar to jump around the page.
But that's not all. The user gets tired and taps the backspace button. Alas, instead of moving back, it goes to a different page because the all knowing designer messed with that too.
After a few confused back/forward presses, the user closes the tab or the browser, if the designer messed with the tab closing process.
But it's all right cos user engagement has improved!
> Alas, instead of moving back, it goes to a different page because the all knowing designer messed with that too.
Well, that (all that incredibly important) bounce rate won't go down by itself!
The backspace button no longer works to go back, you need to press alt+backspace
That's chrome only. However, the history jacking applies even if you use the browser's back button.
Yes pleeease load some more megabytes of CSS and JS garbage such that the scrollbar is as tiny as possible, and most likely janky and laggy on anything but top-end machines. And when your code invariable fails to load, because of interrupts or unavailability, there's no scrolling at all. And people without perfect eyesight or older folks can't use the side at all.
Thank you front-end designers for your continuing efforts to ruin everything good about the internet. No tech group has collectively produced so much garbage in the last decade!
> For designers accustomed to Mac environments but designing multi-platform web experiences, trying to make everyone happy in a way that doesn’t place a lot of performance burden on the end user can be tricky.
Or you could just leave things at their defaults and stop messing with native chrome and UI elements. Now that you've styled it "unobtrusively" for Windows, that's one UI element that's completely inconsistent with the rest of the OS, and for what purpose? Does a usable user interface element actually need to be a tiny capsule because that's what Apple does?
I agree with the sentiment but the web is so ridiculously inconsistent already that drawing the line to styling scrollbars feels pointless to me.
This was your monthly "the web was a mistake, gopher should've won" propaganda message. You can now return to your 30MB React.js project.
The question is about what’s consistent for the user not the application developer
Gopher was arguably more consistent in both regards. But pretty vs functional wasn't even a tradeoff you could really consider.
The protocols certainly influence the designs but there’s always a level of flexibility in the clients (ie, browsers) which the app devs will still have to wrangle.
Some devs value consistency across platforms so their app always looks and functions the same. But I personally think it’s best to default to the system’s UI. Sure I can make it look Mac-esque on desktop Firefox on Windows but I’d rather it look and function exactly like every other windowed application they use on the platform.
There’s also nothing inherent in using JS heavy frontends like React which encourages non-standard browser behaviour. You can still present complex interactive elements while keeping scrolling and other usability stuff like back buttons, copy/pasting, form input behaviour (not breaking LastPass and browser autocomplete for ex), not losing form data on submit after validation errors, etc. You have to go out of your way to explicitly modify default browser behaviour, usually via 3rd party libraries added on to these frameworks.
Personally I found it was far more common in the jQuery world, which is still rampant among those awful prebuilt themes people and companies always use for their websites.
If gopher had a way to send a request with a body it could have done better, I think. You can't build a BBS/Forum with just gopher.
To be fair, if Gopher had won then the industry would surely have found a way to make it as shitty as the web is now.
Knowing that even if the hack works now it could break on future versions of the browser or different OS. So that also assumes the website will be an actively developped website forever.
> Knowing that even if the hack works now it could break on future versions of the browser or different OS. So that also assumes the website will be an actively developped website forever.
This rather is a hack to make your job much more secure.
It's also a fun bit of "everything old is new again". The scrollbar color CSS this points out for Firefox originated somewhere in IE 3-6 when Windows 9X was briefly encouraging fun with scrollbar colors to better match content and there was a lot of applications that did so on Windows (it was the early WinAMP, Napster, etc era). Other platforms complained about how "tacky" such CSS was, and by the time Firefox implemented it most people thought it was a bad idea of the BLINK/MARQUEE school. It's almost strange this time to see it from the other direction of macOS web devs wanting more Mac-like scroll bars everywhere.
When you have a dark-theme-ish website, then the bright scrollbars suck, especially if you got more than one (e.g. two scrollable columns). So you need to do something or else a lot of users will complain or just leave.
Obtrusive scroll bars by default screw up certain CSS rules like 100vw. So that's why it matters.
I've seen you post this particular issue twice in this thread. Perhaps it's not the scrollbars' fault that setting an element's width to 100vw (which is 100% of viewport width) usually requires a scroll? The scrollbars are a symptom that you are setting your child element width too high. Try 100% instead, which should make it 100% of the parent size.
If your intent is to set an element to 100% viewport width with no scrollbar, that's trivially easy to do without jacking around with scrollbar styles.
Seems like the Mac-based designers were a bit too fixated on the issue of scrollbar appearance and this tech team had to figure out a workaround.
Speaking of web scrollbars: One of the many reasons I hate modal dialogs ('lightboxes') on webpages is that they mess up scrolling behavior. Sometimes they accidentally close themselves if you hit the scrollbar, sometimes something else happens...
Interestingly in mobile web design, having a scrollable box inside a document doesn't really work that great (in fact I am typing this on HN on my phone and the fact that this text input is too small for my comment & scrollable makes it tricky to read and edit.) So this forces us to think about other ways to make boxes expandable. One solution I've used is showing eg. 40px of the box then a button to expand it in place in the page, where it can be browsed using the document scrolling behavior, instead of showing a 200px height box with its own scrollbar.)
As a desktop user of Firefox on Linux I found the two demos with the modified scrollbars subjectively worse than default. As a user I use the scroll bar to (1) identify if a section can be scrolled, (2) identify where in the section I am with regards to the scroll height, and if needed (3) manually scroll by clicking on the scroll bar and dragging with the mouse. The two demos retain these three capabilities but for me make them more difficult and less efficient.
I agree with what other users have said: please do not touch my scrollbars.
I like obtrusive scrollbars that the browser provides. As well as toolbars and full menus, and separate search and address bars, and address bars that actually have the full address in them, and status bar that tells me a useful status. Most importantly none of those elements should be able to be affected by the site im visiting.
If modern UI designers were making a car they would replace the fuel gauge with just the light saying you need gas, the RPMs would be gone completely, and the speedometer would just say to hurry up or slow down.
”let’s get a few definitions out of the way:
Obtrusive scrollbars…”
That’s where the error is made. https://www.merriam-webster.com/dictionary/obtrusive lists two meanings for “obtrusive”, both with a negative connotation.
Especially given the sizes of today’s desktop monitors and their ability to use various grays and low key colors to draw items, there’s nothing “undesirably prominent” about permanently showing user controls.
In fact, there’s a case to be made to show more controls. That’s why we got tool bars, and why Microsoft turbo-charged it to the ribbon.
My rule is, whenever I find myself putting things into categories with names that are judgemental/subjective, that's usually a sign that my thinking on the subject is flawed somehow. Calling them "obtrusive" and "unobtrusive" scrollbars is just another way to call them "bad" and "good" scrollbars; it says more about the biases of the author than it does about the scrollbars themselves.
That's an insightful comment and a good (IMO) way of slowing down the outrage train, if only by a tiny bit. Thanks.
Reply to self: many programs have realized this, too, and added _enormous_ scroll bars, in the form of a “Show Thumbnails” feature (examples: MS Word and PowerPoint, Mac OS Preview and Pages) or as a “minimap” (https://en.wikipedia.org/wiki/Mini-map#Code_Minimap_in_Text_...)
Say NO to sneaky scroll bars!
> Obtrusive scrollbars: scrollbars that take up screen real estate. These do not overlay on top of the content, but appear next to it.
> Unobtrusive scrollbars: scrollbars that sit on top of the content. These don’t subtract screen real estate away from the container they belong to.
See, I would call "scrollbars covering content" to be obtrusive and "scrollbars outside of the content area" to be unobtrusive...
The main scroll bar in my browser should be completely off limits, and treated as part of the browser and not the page. Divs inside the page with their own scrollbars are another matter, but even then...
As a webdev (albeit a noob) I just leave the scroll bar to its own devices with ONE EXCEPTION.
I hate the "pop" you get when the scroll bar isn't there, and then suddenly there is enough content to scroll and the scroll bar shifts everything to the left. It's not easy to account for for a given page when that may or may not occur when say you show some new content and then suddenly things shift left.
It's a pain visually so I just force it to appear regardless.
I've had luck with:
overflow-y:scroll;
>Minimize the real estate that a scrollbar can occupy. Windows scrollbars are obtrusive and very wide by default.
Wide scrollbars are a blessing. Better to lose a couple pixels, a fraction of a percent of screen space, than have to constantly line up your cursor over a tiny, yet essential and frequently-used UI tool. I can't stand those dainty little ovals on Mac OS, it's like having to constantly slow down whatever I'm trying to do to thread a needle. It blows my mind that everyone is constantly trying to throw away effortlessly responsive function for such stupidly picky details of form, according to an arbitrary standard of pure aesthetics. Scrollbars should always remain visible and wide.
This was interesting until he started mentioning CSS, then it was no no no no no through the end of the article. Do not mess with scrollbars.
In the same class of annoying bullshit: don't mess with text boxes with JavaScript. You won't get it right, there's so many little interactions the system text boxes can do that yours won't and it'll throw a massive wrench into things when I can't use yours the way I'm used to.
The same applies to JavaScript for smooth scrolling. There's a browser preference, turn it off for yourself and then keep your nose out of my web browser.
The "know-better" attitude of some web devs is terrible.
I really wish browsers wouldn't let websites mess with the scrollbar style, or any of the chrome. This entire post is ridiculous.
Do not hijack my scrollbars or my back button. You do you get kicked in the nuts (if we ever meet).
(I'm not actually condoning violence, just giving an example of how annoying you are for frustrating me)
Seems like a slippery slope. I’d never advise messing with a scroll bar on a web page.
> Obtrusive scrollbars: scrollbars that take up screen real estate. These do not overlay on top of the content, but appear next to it.
> Unobtrusive scrollbars: scrollbars that sit on top of the content. These don’t subtract screen real estate away from the container they belong to.
I work mostly on the front end, and I recently ran into a bug where a scrollbar would alternate between these two behaviors depending on screen width, the page's CSS, and when the DOM was redrawn.
I'm generally interested in moving away from FE work, and I must admit that part of it is to increase the distance between me and scrollbars.
Annoyingly on Chrome the flag to enable auto-hiding scrollbars on Windows is being deprecated and in Chrome Canary is already at the point you have to enable the flag to enable soon to be removed flags to even select it anymore.
This seems to be moving in the opposite direction from how the platforms it runs on are evolving :/.
> Moreover, touch devices have popularized hiding the scrollbar, making it invisible until an overflowing element is scrolled, trading design aesthetics for confusion on containers that don’t appear to be overflowing/scrollable at all.
Not a touch device, but I couldn't find a file in Finder because it was off-window and the window had no scroll bars, implying I'm seeing everything.
Nice example of something I wrote about yesterday: perfect ux is impossible: https://erik.itland.no/perfect-ux-is-impossible
(It started as a rant but I have tried to clean it up a bit.)
And yes, agree with the majority here: leave my scrollbars alone, if I want a Mac I can ask my boss to get one for me.
Something I noticed the other day. If you watch the credits for Ralph Breaks the Internet, it has a scroll bar on the right that accurately reflects the current position in relation to the entire credit roll.
It was quite useful!
If you want me to instantly close your website/app, then sure, go ahead and mess with my scrollbar.
These articles make me feel like I'm the only person on Earth who's never had a problem with my scrollbars. Do they have to fix things that aren't broken for people?
Mac scrollbars are terrible for accessibility. They're way too small, larger scrollbars help users with dexterity/mobility disabilities. I like the windows behavior because for me its reliable, I know where it "is," and yeah I object to "scrolljacking."
After trying the demo and comparing those two implementations I came to conclusion that I really like standard system scrollbars waaay more. Thanks for respecting my own settings and please don't style scrollbars.
> The scrollbar is under attack. Scrolljacking hijacks the default scrolling behavior, breaking the implied contract between document length and scrollbar height.
…
...so here's how we hijacked system-provided scrollbars to fit our needs.
> On Windows 10, a similar preference exists in Settings → Display → Simplify and personalize Windows. Unfortunately even with this preference checked, it had no effect on scrollbar behavior in Firefox, Chrome, in Internet Explorer and Edge—whether Chromium or EdgeHTML based.
So either this option isn't exposed to applications or browsers (including MS' own) aren't making use of it. Either way this is an issue that I'd like to see resolved.
There's another alternative: it's just broke. Considering how frequently Microsoft breaks its own OS while blundering around trying to implement the latest who-gives-a-shit anti-feature in time for their bi-annual in-place reinstall shitshow, it wouldn't be surprising.
>it isn't exposed to browsers well, I have a strong position that it should not be exposed to browser. Exposure of system settings/preferences should be minimized as this provides additional user-profiling opportunities.
Exposed to the browser doesn't have to mean it's exposed to websites. The browser has access to all sorts of system settings that websites aren't allowed to view. Although admittedly it's hard to disguise scrollbar behaviour if it affects the page width.
No one has surpassed the SGI scrollbars from ancient times. When you moved it, it left an indent of where you were so you could go back easily or compare two pages. Also could middle click to go directly instead of page. That’s still available on some floss desktops but gnome broke that at some point. Still works under mate.
I checked out the demo, it turns out this is for something reminiscent of frames rather than the main scrollbar.
Just stop, don't have internal or nested scrollbars at all. Having part of the page scroll independently of the rest is a usability nightmare anyway, especially when you consider how it interacts with zooming.
All These Elements Are Yours, Except Scrollbars. Attempt No CSS Styling There. Use Them Together. Use Them in Meaning.
https://mastodon.cloud/@dredmorbius/102742105247305430
While the content is interesting, by far the most useful thing I learned from this article is that you can turn off unobtrusive scrollbars on a mac. I have to use one at work, and turning off this feature makes me hate my computer less by a significant amount :)
I think the proposal for scrollbar-width:thin is good enough for cases where you have a secondary scrollable area in your site or application. Styles beyond that will just become too confusing.
If you design web sites and feel the need to fuck your users over like this, you need to straighten your priorities.
As someone who creates accessible sites for a living, this wouldn't fly.
You can have my scrollbar when you pull it from my cold, dead, GUI. If I don't have a scrollbar visible (with or without cursor), I'd better be in console.
I feel like a lot of these things are "I'm a mac-based designer and the world is moving away from mac-based design so change the world"
Sounds like this might have to be considered at the level of the OS binaries or the browser binaries instead of the level of HTML/CSS.
On Windows+Firefox the scrollbar is too thin to be used with a mouse.
The iOs hidden scrollbar is a pain. As a web developer, it caused issues because Safari will reflow the content when the scroll bars appear and disappear since the amount of space they take up changes.
just use width:100vw on body and voila Unobtrusive
I recommend you just don't alter the user's scrollbar for your own taste preferences.
Why does horizontal space matter on desktop anyway?
Yes, please stop. Changing the scrollbar is another unwanted overreach that ruins my user experience.
Oh believe me, for the information dense designs I’m working from, and needing to support a baseline desktop resolution, every pixel matters! I would never want to take that out on someone’s scrollbars tho. Scrollbars are sacred.
>information dense designs
All well and good for you but our author here is working with 40-50% whitespace anyway! Why the hell does he need to hide and minimize fundamental features to reclaim more fucking whitespace? Aaaaargh, designers are from a different species!
>Why does horizontal space matter on desktop anyway?
Because some people like to tile their screens into two halves.
We had scroll bars when desktops where 640x480.
The very idea of scrollbars was popularized with a desktop that was 512x342!
if you use firefox on android, about:config has a "scrollbar timeout" setting that you can set to 0 or -1... now you will have an always visible scrollbar.
you must force close firefox before it takes effect.
Wow
for a second I thought its /r/jokes
This is probably only interesting for web developers. Maybe a sub-hackernews would make hacker news better? Wait... that's old.reddit.com.
I’m not a web developer and I found it interesting enough to read.