7 ms·

Is There Too Much CSS Now?

32 points by notmysql_ 4y ago

marginalia_nu 4y ago
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' Why do designers hate scroll bars :-(
- wildrhythms 4y ago
  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. :)
  - marginalia_nu 4y ago
    I primarily use the scroll bar when I scroll :-( The scroll wheel is so sluggish and the cursor keys are a lot slower still. Also I'm not an apple user.
    - byhemechi 4y ago
      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
- louky 4y ago
  Exactly, and I've been running lubuntu recently had the defaults are insane with skinny/nonexistent scrollbars. On an OS level There's nothing!
- FoomFries 4y ago
  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.
  - marginalia_nu 4y ago
    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.
- jfengel 4y ago
  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.
  - marginalia_nu 4y ago
    > 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.
Waterluvian 4y ago
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.
- Iv 4y ago
  The thing that gives me incomfort is the knowledge that we have a turing-complete language to manage display preferences. I feel that there has to be a better way.
  - Waterluvian 4y ago
    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?
  - alwillis 4y ago
    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.
Iv 4y ago
[insert meme "Always has been"]
AtlasBarfed 4y ago
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. /s
- unsupp0rted 4y ago
  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.
hcarvalhoalves 4y ago
Software development doesn’t know the words “enough” or “sufficient”.
pkrumins 4y ago
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.
- tmnvix 4y ago
  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.
- deleted 4y ago
  [deleted]
- 9dev 4y ago
  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“.
- asddubs 4y ago
  so no flexbox or grid? no thank you

32 points by notmysql_ 4y ago

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' Why do designers hate scroll bars :-(

wildrhythms 4y ago
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. :)
- marginalia_nu 4y ago
  I primarily use the scroll bar when I scroll :-( The scroll wheel is so sluggish and the cursor keys are a lot slower still. Also I'm not an apple user.
  - byhemechi 4y ago
    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
louky 4y ago
Exactly, and I've been running lubuntu recently had the defaults are insane with skinny/nonexistent scrollbars. On an OS level There's nothing!
FoomFries 4y ago
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.
- marginalia_nu 4y ago
  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.
jfengel 4y ago
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.
- marginalia_nu 4y ago
  > 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.

Waterluvian 4y ago

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.

Iv 4y ago
The thing that gives me incomfort is the knowledge that we have a turing-complete language to manage display preferences. I feel that there has to be a better way.
- Waterluvian 4y ago
  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?
- alwillis 4y ago
  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.

Iv 4y ago

[insert meme "Always has been"]

AtlasBarfed 4y ago

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. /s

unsupp0rted 4y ago
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.

hcarvalhoalves 4y ago

Software development doesn’t know the words “enough” or “sufficient”.

pkrumins 4y ago

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.

tmnvix 4y ago
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.
deleted 4y ago
[deleted]
9dev 4y ago
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“.
asddubs 4y ago
so no flexbox or grid? no thank you