Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't use custom CSS scrollbars

ericwbailey.website

Post reply on HN
Print view View original

71–80 of 250 posts

Re: Don't use custom CSS scrollbars

#71

Post by graup »

madeofpalk wrote: post #19
circuit10 wrote: post #8

Earlier quoted context omitted.

https://user-images.githubusercontent.com/13787163/161954436... Wouldn’t this look completely off with a massive light mode default Chromium scroll bar in the middle of everything? When I was developing that my main goal was to get the UI looking consistent and clean so it would feel good to use, which I think is an underappreciated thing; if your UI doesn’t “feel right” then people won’t enjoy using it no matter how…

Use CSS color-scheme: dark to indicate that system widgets, such as scroll bars, should be dark https://developer.mozilla.org/en-US/docs/Web/CSS/color-schem...

TIL. This actually solves my main need for custom scrollbars.

Now the only remaining use case is when designers don't design components around default scrollbars. Sometimes the default one just looks too big compared to the size of the component. But this can be solved with design (don't cram stuff into small fixed boxes that then need to be scrollable).

Re: Don't use custom CSS scrollbars

#72

Post by post-it »

Izkata wrote: post #60
willio58 wrote: post #6

On pages, I fully agree. Within components, I also agree but I've found it hard to push back when a design calls for scrollbars because the alternative is... what? It can be difficult to visually say "Hey, you! There's more to see if you scroll down in this area" You can try to use gradients with fade-outs, you can try to make it so the top of the last item in a scroll area is just visible enough to make it clear som…

> Really I think we just need better APIs from the browsers to customize when a scroll bar is shown (again, not on the page level but within scrollable elements) What do you have in mind beyond "always show", "show if needed", and "always hide"? Those have all existed for decades as "overflow: scroll", "overflow: auto", and "overflow: hidden".

`overflow: hidden` hides the actual content. GP wants the element to be scrollable with a hidden scrollbar.

Re: Don't use custom CSS scrollbars

#73

Post by Drew_ »

kelnos wrote: post #52
karaterobot wrote: post #24

> Scrollbars are part of the area of the browser that is outside your scope of concern. No, they're actually in my scope of concern, that is the whole point of your article. The reason they were brought into my scope of concern is that a lot of people had a use case for styling custom scrollbars. I have a use case for it myself. If you're saying "don't abuse your ability as a developer and make inacessible websites"…

Taking all the flexibility away would be fantastic. I wish all webapps looked as close as possible to native apps, and couldn't style things like buttons.

Safari, Edge and Chrome don't style any HTML elements like their native counter parts.

Re: Don't use custom CSS scrollbars

#74

Post by marcosdumay »

Izkata wrote: post #60
willio58 wrote: post #6

On pages, I fully agree. Within components, I also agree but I've found it hard to push back when a design calls for scrollbars because the alternative is... what? It can be difficult to visually say "Hey, you! There's more to see if you scroll down in this area" You can try to use gradients with fade-outs, you can try to make it so the top of the last item in a scroll area is just visible enough to make it clear som…

> Really I think we just need better APIs from the browsers to customize when a scroll bar is shown (again, not on the page level but within scrollable elements) What do you have in mind beyond "always show", "show if needed", and "always hide"? Those have all existed for decades as "overflow: scroll", "overflow: auto", and "overflow: hidden".

There is somebody on another thread asking for "stick to the visible margin of the element". But I guess most people want to change the scrolling behavior or appearance.

Re: Don't use custom CSS scrollbars

#76

Post by nikau »

preommr wrote: post #21

> Don't use custom CSS scrollbars Alright, I guess I'll go back to using js scrollbars instead /s I hate articles like this because they present highly opinionated solutions as something definite even though it has a narrow focus on what the author cares about. Web apps can be incredibly powerful and convenient, sometimes a scrollbar is in the middle of the page like with that codepen. In those situations, being able…

Sure let's just reenable blink and marquee in that case

Re: Don't use custom CSS scrollbars

#77

Post by sapling-ginger »

kelnos wrote: post #52
karaterobot wrote: post #24

> Scrollbars are part of the area of the browser that is outside your scope of concern. No, they're actually in my scope of concern, that is the whole point of your article. The reason they were brought into my scope of concern is that a lot of people had a use case for styling custom scrollbars. I have a use case for it myself. If you're saying "don't abuse your ability as a developer and make inacessible websites"…

Taking all the flexibility away would be fantastic. I wish all webapps looked as close as possible to native apps, and couldn't style things like buttons.

> looked as close as possible to native apps

This is a meaningless statement, because even native apps don't "look like" native apps. No operating system has a universal style across all native apps, and some (Windows) aren't even internally consistent with the OS's apps.

Re: Don't use custom CSS scrollbars

#78

Post by em_te »

adamredwoods wrote: post #37

>> Apple learned the lesson about visible scrollbars the hard way when it introduced its ultra-minimal, disappearing scrollbar indicators. >> There’s no visual indication that there’s more content present in this window—the only way to discover it is to scroll downwards. However, without an affordance to indicate the presence of additional offscreen content, the chances are low that someone will bother to check. I ap…

Moreover, Google said they did a study when they first released their minimalist homepage design and when people saw lots of white space below the search bar, they assumed the page wasn't finished loading yet and more content was to come.

People were accustomed to long pages like Yahoo's homepage with lots of content below the search bar.

They solved it by adding a footer section with typical copyright text and people understood that the page was finished loading.

Re: Don't use custom CSS scrollbars

#80

Post by chrismorgan »

> Modifying the scrollbar via CSS means the scrollbar will effectively disappear when a Forced Color mode theme is applied. Again, if you can’t see it, you won’t know it’s there.

> Much like with Forced Colors Mode, custom CSS scrollbars will not honor the presence of an enabled Increased Contrast Mode.

These both just sound like browser bugs. In those modes, of course the browser should be ignoring or further modifying scrollbar colour changes.

MDN on scrollbar-color: “Note: @media (forced-colors: active) sets scrollbar-color to auto.” (However, I can’t find any spec citation for this, not in Media Queries Level 5 or CSS Scrollbars Styling Module Level 1.)

—⁂—

Here’s my take:

• Don’t use scrollbar-color on the document area, but treat this outermost scrollbar as browser chrome. In the early days of scrollbar-color it helped to set a suitable color-scheme setting in order to reliably get light or dark scrollbars as appropriate, but I don’t think any browser really needs that any longer (though it’s still a good idea, especially for other controls).

• It’s OK to use scrollbar-color on scroll areas within the document, so long as you maintain suitable contrast. Transparent tracks are a little risky, but at least acceptable in most inner scroll areas.

• On scrollbar-width, there’s a reason the values are `auto | thin | none`. As the spec says https://w3c.github.io/csswg-drafts/css-scrollbars/#scrollbar...>: “The primary purpose of this property is not to allow authors to chose a particular scrollbar aesthetic for their pages, but to let them indicate for certain small or cramped elements of their pages that a smaller scrollbar would be desirable.” If you have a scrolling sidebar, for example, `scrollbar-width: thin` is completely reasonable. Other than that, there’s nothing useful to touch.

• Never use the older ::-webkit-scrollbar* pseudoelements (which are the only way to get things like 1px wide scrollbars, like the article speaks of). Their degree of control was a mistake https://w3c.github.io/csswg-drafts/css-scrollbars/#out-of-sc...>, and their implementation never got beyond half-baked anyway, so that touching them at all harms scrollbar accessibility on at least Windows with non-overlay scrollbars (you lose the arrows at the ends).

• With all of these new scrollbar CSS properties, note how thoroughly they’re defined as hints. If certain accessibility modes make scrollbar tweaks break things, that’s very probably the browser’s fault. And it’s an unhappy situation when authors have to consider browser bugs (though it certainly does happen sometimes).

Post reply on HN