Why are they making it possible to make scrollbars thinner?! They're already so thin they're almost impossible to see, let alone click on most modern UIs.
What we really need is 'scrollbar-width: thick-ol-windows-95-bar'
Real answer: Apple hides scrollbars. Not just on iOS- on Mac OS they hide by default, and are only visible when actively scrolling. The vast majority of users don't notice them not being there, so nobody complains and designers keep hiding them.
Another fun thing: On Mac OS you can enable scrollbars to always show; but doing this adds a ~18px scroll gutter on every scrollable element, and thus breaks some scrolling web elements where the designers clearly only designed around the default. :)
obviously this isn't a solution to the issue of scrollbars being too small, but middle click scrolling is actually pretty good if you want to scroll quickly without dragging the scrollbar
Most of the time scrollbars should be designed away. Unless the experience is moving at an undetermined rate to fly past the desired content multiple times, there are better tools. Page keys, scroll wheels (and all of the synonymous gesture experiences), search, collapsing and expanding content, etc.
The bar seems to be more familiarity and less functionality to me.
The scroll bar is great. It allows you to exactly where you want to go in a way you no other option permits.
To scroll through a document the size of this thread, I need to paw at the scroll wheel 10 times. It's at the same time slow and imprecise. With the scroll bar, it's a single gesture, it's quick and immediate with pixel precision.
Neither paging, search or expanding/collapsing elements permit this level of control. They're all much slower, and to make matters worse, often implementation defined.
Scroll bars always work the same in every window and every application. Overshooting the mark is a non-issue because scrolling is so fast correction is trivial and immediate.
The alternatives also have a big problem with focus-ambiguity. If I page-down in the text box I'm typing this into, it will page the text input, and not the document. Using the scroll bar to adjust the view, there is no such ambiguity, since the mouse cursor uniquely identifies which element I want to scroll.
The scroll bar is a surprisingly large component. It's bigger than any button. It's bigger than most text boxes. And most of the time, you're not looking at it.
That's why designers don't like it. It's just an unbalanced use of pixels. It's visual clutter.
Unfortunately, none of the alternatives are great, either. The thin ones are hard to use when you do want them. Making them appear and disappear is distracting. Some applications make use of the space (letters in a long alphabetical list suggesting where to scroll, error indicators in an editor), but it's nonstandard and not always applicable.
So designers keep looking for better alternatives. Ideally, you do away with scrolling, but that's not always feasible.
> The scroll bar is a surprisingly large component. It's bigger than any button. It's bigger than most text boxes. And most of the time, you're not looking at it. That's why designers don't like it. It's just an unbalanced use of pixels. It's visual clutter.
Is there really a shortage of screen space? Scroll bars were introduced on like 14" monitors with a 640x480 resolution. Wasn't a problem then. Why is it we're running out of pixels on a 42" 4K monitor?
I just don't understand why interfaces must be invisible. If anything, a scroll bar provides contextual clues as to what sort of an interface you are looking at. It's something that can be scrolled. It also lets you know where it begins and ends, neither pieces of information are rarely obvious with contemporary GUIs.
Don't underestimate the power of design conventions in making an interface intuitive.
I have this strong emotion of comfort associated with just knowing a project or problem can be solved. Whether it’s programming or renovating my home, I seek confirmation that every sub-task can be done before I embark on the project. This usually requires little experiments.
Being able to totally override anything in Python (but rarely ever doing so) gives me that comfort.
Seeing a small section of my back deck totally renovated before doing the actual project gives me that comfort.
Having a million css options that I’ll rarely use gives me that comfort.
I dunno if others have this feeling? For me it’s not just rational or preparatory, it’s emotionally driven. I feel anxious about a project until I know I have all the tools and parts to complete it, even if inefficiently.
But isn’t that argument just an organizational one? You don’t have to use the parts you don’t want.
And narrowing the toolset is impossible without dictating terms to others on what tools they don’t get.
One loose analogy is that 99% of stuff in Home Depot I won’t need. But it all makes my walk a bit longer and makes finding stuff harder and there’s probably some tools I didn’t know about that would make my life easier. But should I advocate that a lot of it should be eliminated?
The thing that gives me incomfort is the knowledge that we have a turing-complete language to manage display preferences.
It’s not accurate to imply what CSS does is only “managing display preferences”.
CSS is the presentation (color, layout, typography, animation, speech) and state management layer for HTML and SVG, among other markup languages.
I much rather have agreed upon specifications instead of having to invent hacks and work arounds for things that should be standard in 2022.
It took 20+ years to get layout based on columns and rows (CSS Grid); before that, layout comprised of hacks (floats, absolute positioning) and features being misused, like tables.
Container queries, CSS Nesting and the parent selector—-:has()—-results in less and easier to understand code with fewer hacks. It also means doing more without reaching for JavaScript.
CSS is in a good place finally and I for one hope it continues.
I have had multiple conversations with multiple devs about it being ok to use a table tag when the display is an actual table i.e. columns and rows of data with headers etc. It’s semantically correct! One occasion was for a project wherein the lead rejected my code because I used a table tag for tabular data. I was told to use floating divs instead.
I guess the point of my story is that people will misuse tools regardless of what is available to them.
I should also mention that these new CSS features enable developers the option to stop using CSS frameworks that are often bloated with features you may not need or want.
Back in the day, developers would use a CSS framework just to manage grid issues, which had their own limitations.
With CSS Grid, we do things that were difficult or impossible with much less code.
I suggest we have these things called "tags" which might wrap up CSS settings into a generally usable form. So rather than 1,000,000 <div> and a bunch of css differentiating them, perhaps a "tag" encapsulates some common behavior. The "tags" could have "attributes" to adjust specific parameters on their behavior.
I use Vuetify for this. There’s a million lines of CSS under the hood but I end up writing maybe 5 lines of CSS per project, not counting all the layout and color classes I attach to elements.
Tailwind is similar, except that Vuetify components are appearance + functionality. Whereas Tailwind is appearance-only.
If anyone likes CSS2, then I’m hiring. We use vanilla CSS2 (and vanilla HTML4 and vanilla JavaScript via <script> tag — no node modules or bundlers) as it simply works. Message me if interested.
Definitely my preferred approach. If I'm building a website, creating and managing a build process is almost always an encumbrance.
I work with some younger developers that honed their craft after things like SCSS and modern JS frameworks became commonplace. They can't seem to fathom the idea of building even a simple website without node.js.
For many projects - sure - a JS framework, a CSS framework, SCSS, etc, have their place, but I'm convinced many developers are killing themselves with unnecessary complexity. Just wait until you revisit that old blog site you made with tailwind after a few years without updating the mountain of JS dependencies. Oh boy...
In my opinion all of that extra complexity needs to be justified, and for a very large number of basic websites I don't believe it can be.
None of that is to say I don't use (and enjoy using) things like React and Svelte. I am however loving the resurgence in simpler approaches like HTMX.
Without knowing what you actually do, that sounds like the Amish way of coding — defining an arbitrary point in time where you deem technology to have been „good“.
24 comments
[ 10.1 ms ] story [ 79.0 ms ] threadWhat we really need is 'scrollbar-width: thick-ol-windows-95-bar'
Why do designers hate scroll bars :-(
Another fun thing: On Mac OS you can enable scrollbars to always show; but doing this adds a ~18px scroll gutter on every scrollable element, and thus breaks some scrolling web elements where the designers clearly only designed around the default. :)
The scroll wheel is so sluggish and the cursor keys are a lot slower still.
Also I'm not an apple user.
The bar seems to be more familiarity and less functionality to me.
To scroll through a document the size of this thread, I need to paw at the scroll wheel 10 times. It's at the same time slow and imprecise. With the scroll bar, it's a single gesture, it's quick and immediate with pixel precision.
Neither paging, search or expanding/collapsing elements permit this level of control. They're all much slower, and to make matters worse, often implementation defined.
Scroll bars always work the same in every window and every application. Overshooting the mark is a non-issue because scrolling is so fast correction is trivial and immediate.
The alternatives also have a big problem with focus-ambiguity. If I page-down in the text box I'm typing this into, it will page the text input, and not the document. Using the scroll bar to adjust the view, there is no such ambiguity, since the mouse cursor uniquely identifies which element I want to scroll.
That's why designers don't like it. It's just an unbalanced use of pixels. It's visual clutter.
Unfortunately, none of the alternatives are great, either. The thin ones are hard to use when you do want them. Making them appear and disappear is distracting. Some applications make use of the space (letters in a long alphabetical list suggesting where to scroll, error indicators in an editor), but it's nonstandard and not always applicable.
So designers keep looking for better alternatives. Ideally, you do away with scrolling, but that's not always feasible.
Is there really a shortage of screen space? Scroll bars were introduced on like 14" monitors with a 640x480 resolution. Wasn't a problem then. Why is it we're running out of pixels on a 42" 4K monitor?
I just don't understand why interfaces must be invisible. If anything, a scroll bar provides contextual clues as to what sort of an interface you are looking at. It's something that can be scrolled. It also lets you know where it begins and ends, neither pieces of information are rarely obvious with contemporary GUIs.
Don't underestimate the power of design conventions in making an interface intuitive.
Being able to totally override anything in Python (but rarely ever doing so) gives me that comfort.
Seeing a small section of my back deck totally renovated before doing the actual project gives me that comfort.
Having a million css options that I’ll rarely use gives me that comfort.
I dunno if others have this feeling? For me it’s not just rational or preparatory, it’s emotionally driven. I feel anxious about a project until I know I have all the tools and parts to complete it, even if inefficiently.
I feel that there has to be a better way.
And narrowing the toolset is impossible without dictating terms to others on what tools they don’t get.
One loose analogy is that 99% of stuff in Home Depot I won’t need. But it all makes my walk a bit longer and makes finding stuff harder and there’s probably some tools I didn’t know about that would make my life easier. But should I advocate that a lot of it should be eliminated?
It’s not accurate to imply what CSS does is only “managing display preferences”.
CSS is the presentation (color, layout, typography, animation, speech) and state management layer for HTML and SVG, among other markup languages.
I much rather have agreed upon specifications instead of having to invent hacks and work arounds for things that should be standard in 2022.
It took 20+ years to get layout based on columns and rows (CSS Grid); before that, layout comprised of hacks (floats, absolute positioning) and features being misused, like tables.
Container queries, CSS Nesting and the parent selector—-:has()—-results in less and easier to understand code with fewer hacks. It also means doing more without reaching for JavaScript.
CSS is in a good place finally and I for one hope it continues.
I guess the point of my story is that people will misuse tools regardless of what is available to them.
Back in the day, developers would use a CSS framework just to manage grid issues, which had their own limitations.
With CSS Grid, we do things that were difficult or impossible with much less code.
/s
Tailwind is similar, except that Vuetify components are appearance + functionality. Whereas Tailwind is appearance-only.
I work with some younger developers that honed their craft after things like SCSS and modern JS frameworks became commonplace. They can't seem to fathom the idea of building even a simple website without node.js.
For many projects - sure - a JS framework, a CSS framework, SCSS, etc, have their place, but I'm convinced many developers are killing themselves with unnecessary complexity. Just wait until you revisit that old blog site you made with tailwind after a few years without updating the mountain of JS dependencies. Oh boy...
In my opinion all of that extra complexity needs to be justified, and for a very large number of basic websites I don't believe it can be.
None of that is to say I don't use (and enjoy using) things like React and Svelte. I am however loving the resurgence in simpler approaches like HTMX.