Live data from Hacker News

Don't use custom CSS scrollbars

ericwbailey.website

171–180 of 250 posts

Re: Don't use custom CSS scrollbars

#171
Another fun one is scroll-triggered animations, as one would commonly find on an Apple product detail page, as just an example.

The problem is that it assumes smooth scrolling input, typically a touchpad or a touch-only device. The experience completely breaks down into wild stuttering when scrolling with friction: mouse-wheel that scrolls with discrete steps or the classic "drag the scollbar" interaction.

Even when using smooth scrolling input it sucks, as you carefully need to time/verify your scroll speed as content appears/disappears based on force applied.

Re: Don't use custom CSS scrollbars

#172

Earlier quoted context omitted.

> And scrollbars are completely different in different browsers - they have different sizes, different behavior, different look-and-feels. Yes, and? No matter what it is, it's what the users of said platform are used to. Is there really a benefit to forcing users to re-learn such a critical component? > You wouldn't expect a game to use the system look-and-feel, it rightfully uses a look-and-feel that matches the gam…

My point was that a general "no app shall customize scrollbar look and feel" is wrong, as there are certain kinds of apps that do benefit from custom look and feel. Sure, not all games, but also games are not so entirely different from other kinds of apps. Also, I thought the specific points about CSS and how to achieve custom styling if desired are irrelevant. The arguments I was replying to were about UX, not about…

It's very hard to actually write good UX from scratch, particularly stuff like scrollbars that require all sorts of relative resizing, drag listeners, velocity methods, second and tertiary controls (keyboards, drag-selection of text) and often need to handle those things after a variety of user interactions without redrawing their content or slowing anything down by constantly remeasuring the rest of the UI.

Because it's difficult, it's often done poorly, which leads to people thinking it should never be done at all.

To your point about games, I find most custom-written scrollboxes in games to be pretty terrible, but we all kind of appreciate them just for their uniqueness, because as UX items they're generally not something you interact with that much. (Unless you're playing Crusader Kings, in which case ... )

I remember being disgusted and offended by Apple's app developer rules two decades ago, which included dictates such as never implementing your own UX elements like scrollbars. We're still debating whether they were wrong. As long as there are bad ways to build UX elements, some people will do them, and this will serve as proof for a few big companies that it should never be done.

Re: Don't use custom CSS scrollbars

#173
Custom scrollbars, as in "I'll hijack the scroll events and draw custom stuff on the side of the element" kind of custom, yeah, that's bad and buggy and annoying. Being able to style native scrollbars is a godsend which satisfies designers and brand people and prevents the first kind of custom scrollbars.

Re: Don't use custom CSS scrollbars

#174
> Scrollbars are part of the area of the browser that is outside your scope of concern.

This is simply wrong. You might have a scrollbar in your content, which indeed is the scope of concern for the developer.

Re: Don't use custom CSS scrollbars

#175
post #56

Earlier quoted context omitted.

> Codepen also doesn't allow me to scroll past the beginning/end of the file, which feels jarring and just wrong with a touch scroll device. Stuff like this often happens because of a lack of native styling options. Can’t change the appearance of the scroll bar (for, yes, often dumb reasons)? OK then we’ll use a giant JS library that poorly replicates every aspect of scrolling. At least with native scroll styling, ug…

This doesn’t make any sense. The native behavior is what OP wants. No one needs to recreate the native behavior, it is already available

The person you're reacting to is making a distinction between a native (in the context of browser) scrollbar with the ability to change its presentational style (but not behavior) and a completely custom JS driven scrollbar with likely different behavior from the native experience.

Re: Don't use custom CSS scrollbars

#178

Earlier quoted context omitted.

Yes 100%, apps should follow the theme for components set by the user.

I would go even further: websites should not be the ultimate decider on any style-related decision. Including colors, font faces, text size, margins, padding, content width, and any other UI elements. Website should be able to suggest these things, but browsers should default to the user’s preference or the system’s configuration. The user should have the final say on how the User Agent displays HTML content. Browser…

It's relatively easy to force your custom stylesheets to any website. Whether it will work at all is another question.

I believe what you suggest could work only with semantic HTML without any advanced styling - no floating elements, no flexbox/grid, no absolute/relative positioning etc. This then means return to static text based websites which is fine for many use cases, but not for all.

Ideally, rich web apps which actually need all the CSS/APIs could use them, while the text-based sites would keep custom styling/JS to minimum (which would allow reasonable user-defined styling). But it's impossible to force this dichotomy in practice.

Re: Don't use custom CSS scrollbars

#179
post #20

Earlier quoted context omitted.

There's been an ongoing trend in UI design in recent years to assume more and more of the user. The removal of scrollbars from browsers confused my parents. Instead of having up and down arrows by your content now you're just expected to just know that you scroll with your mouse / trackpad. Similarly, modern versions of Windows will just assume you know that the four squares at the bottom of your screen is where you…

In general it feels like a lot of UI design these days is optimizing for looking pretty in screenshots and photos rather than being useful as a tool, it's honestly gotten really frustrating in recent years.

A month or so ago, a screenshot of Snow-Leopad-era OS X standard UI controls made the rounds on the fediverse. One forgets so fast with incremental change, but when you take it in with some distance, it’s truly devastating how things have regressed since that time.

The Apple folk and adjacent circles like to throw around how “design is how it works™”, but design hasn’t been how it works in Macos for a while (and it’s not better anywhere else).

Re: Don't use custom CSS scrollbars

#180
post #41

I recognize that web developers want full control over the user experience, usually to the point of reimplementing all of the native UI widgets provided by the user’s OS. As a user, I prefer for my OS to do things my OS does, including styling my widgets. My scrollbars, my scrolling behavior, window chrome, all of it… whether it’s good or bad or right or wrong, that’s between me and my OS. As a user, I hate when web…

First of all, the OS does not style widgets, the browser does. And scrollbars are completely different in different browsers - they have different sizes, different behavior, different look-and-feels. So either you create versions of your app which match each browser individually, or you re-style the scrollbars to look the same as the rest of the app. Thirdly, there is an obvious counter to your arguments that shows t…

> First of all, the OS does not style widgets, the browser does.

This goes beyond scrollbars. There are hundreds (thousands?) of libraries or entire frameworks to build consistent dropdowns. Even more to create date-pickers and to replace alert dialogs, add modals, and whatnot.

This shows that the browsers don't do a good job offering nice and neat UX on them. Same for scrollbars. Browsers offer native dropdowns (that more-or-less match your OS - depending on browser and OS), datepickers (that at least match your locale) and even native alert dialogs. And many are ugly as hell, have a terrible UX or integrate very poorly. IMO fair points. And often even reasons to replace the native widgets with tons of JS, CSS and dom manipulation. Edit: though I don't think this is the case for scrollbars, I think browsers do a good enough job there.

The one reason that I very much disagree with, it cross-browser or cross-platform consistency. No-one cares that widgets on your website or -app are the same on chrome/windows, icebeaver/weirdlinux and safari/OSX. Because no-one other than the webdeveloper and -designer will ever use them on all those platforms and expect everything to look the same on all these platforms.

Post reply on HN