7 ms·

To each their own, but I personally learned to hate this approach. In my experience, it leads to a CSS spaghetti full of overrides and `!important` just to get

To each their own, but I personally learned to hate this approach. In my experience, it leads to a CSS spaghetti full of overrides and `!important` just to get all the utility classes to play nicely across a site. And of course the markup becomes less readable. I prefer to just write classes for specific components with some modifier classes to toggle variations. People resist this because they've been taught to avoid repetition, but I've found that repetition is a good trade-off for things just making more sense because it's really not that hard to go in and change the same pattern repeated among CSS selectors if there's a site-wide design change. If you really hate repetition, you can still use CSS variables and SCSS mixins. But the end product of the CSS definitions should be styles that are easy to use, don't tangle with each other, and make it clear what an element represents. What I describe becomes even more practical if you separate your CSS concerns into concepts like "layout" and "component" or "design". That way the styles that handle your page layout and responsiveness don't get tangled with the styles that handle the appearance of elements. Here's a blog post I wrote that goes into more detail about my approach to CSS: https://tenbit.co/blog/my-approach-to-writing-maintainable-css/ https://tenbit.co/blog/my-approach-to-writing-maintainable-c... (I only recently discovered that the page heading is kinda broken on mobile. Sorry.)

deltron3030 7y ago
>To each their own, but I personally learned to hate this approach. In my experience, it leads to a CSS spaghetti full of overrides and `!important` just to get all the utility classes to play nicely across a site. And of course the markup becomes less readable. The entire point of utility CSS frameworks is that you barely mess with the css, the css is already baked in, you just pick from it within html. >What I describe becomes even more practical if you separate your CSS concerns into concepts like "layout" and "component" or "design". That way the styles that handle your page layout and responsiveness don't get tangled with the styles that handle the appearance of elements. Frameworks like tachyons or tailwind have basically inverted the specificity/explicity/reach pyramid that is known from soft CSS frameworks like ITCSS. Their css file is quite similar.
- harimau777 7y ago
  I could see that working if the designers commit to limiting themselves to what is in the CSS. However, in my experience they generally want pixel perfect implementation of any design they come up with. As soon as that happens, I think that utility CSS becomes a major liability.
  - deltron3030 7y ago
    Design systems that UI designers come up with can be baked into the utility css stylesheet in advance, before devs or other designers access it through html. Kinda like a living style guide, but in code. That's really the point, the css stylesheet is basically an intermediary step and single source of truth for the styles in the design. Then when stuff is being built devs don't have to think about styling, only layout and applying the correct values that are predefined in the css. That said, if you're on your own, have your own boilerplate and design skills that you can apply in real time and know css/html, you might be better off with regular css.
    - dsego 7y ago
      Design systems that UI designers come up with... and then break them later every chance they get, because unlike what developers believe, design is not always lego blocks and styles will be tweaked to fit the context. A developer sees the sum of all UI components on a page, but the designer sees missing accents or not enough spacing and will adjust those to fix issues or achieve a particular look... the result being new styles for that page.
      - csande17 7y ago
        +1. A lot of design systems assume that, for instance, there are only a few amounts of vertical padding you'll ever want to have on an element. But sometimes, the designer really will tell you that something needs 10 pixels of padding, your 8-pixel "p-2" value is too small, and your 12-pixel "p-3" value is too large.
meerita 7y ago
> To each their own, but I personally learned to hate this approach. In my experience, it leads to a CSS spaghetti full of overrides and `!important` just to get all the utility classes to play nicely across a site. And of course the markup becomes less readable. I wrote many many CSS lines in my life and !Important is part of OOCSS world more than utility first. How do you write !Important in a functional space? It's kinda impossible unless you want to overwrite things too much from outside the funcional classes. That would be a problem and it would tell you that your approach was not good from start.
hinkley 7y ago
We have bad terminology and insufficient training I think. We are deep into metric dysfunction now thinking the repetition of very small blocks of text is wasteful, even shameful. That’s not the duplication that matters. The duplication that matters is the effort. Having to do the same action over and over, and ensuring the same result occurs. That’s expensive. That’s draining. Trying to deduplicate code that is structurally similar but has different aims just creates a problem later on.
- dwaltrip 7y ago
  > Trying to deduplicate code that is structurally similar but has different aims just creates a problem later on. This is one of the most important lessons I've learned in software. Abstractions work well when the snippets in question have similar, coupled requirements. The proposed abstraction must target the shared requirements, or it will soon cause more problems than it solves as the snippets diverge due to their different purposes. Structural similarity alone provides very limited opportunity for a robust abstraction. A rough heuristic that may indicate one of these problematic abstractions is the number of special cases and if-elses that are continually being added to make it work.
- harimau777 7y ago
  The issue, at least as I understand it, isn't so much in the fact that code is being duplicated. Rather, the problems that I see are: - Having lots of utility classes applied to the tags in HTML make it difficult to read. In particular, when it becomes necessary to split a tag onto multiple lines the HTML can become less effective at visually indicating how tags are nested. - Including styling in HTML obscures the intent of the HTML. For example, is this div here because this is actually a new semantic section or just because we needed somewhere to put utility classes?
jeffkeen 7y ago
I'm with you. I think Trello's CSS guide they put out a few years back was the sanest approach to writing manageable CSS I've found. It's something I try to follow in every project. https://github.com/trello/trellisheets/blob/master/styleguide.md https://github.com/trello/trellisheets/blob/master/styleguid...
andrei_says_ 7y ago
I think it’s a good option if: - you build js components - you don’t know css that well - you don’t want the cognitive load of naming styles, esp. as a team. I do know CSS, do not use react, and am used to BEM, so this is not a solution for me.

deltron3030 7y ago

>To each their own, but I personally learned to hate this approach. In my experience, it leads to a CSS spaghetti full of overrides and `!important` just to get all the utility classes to play nicely across a site. And of course the markup becomes less readable. The entire point of utility CSS frameworks is that you barely mess with the css, the css is already baked in, you just pick from it within html. >What I describe becomes even more practical if you separate your CSS concerns into concepts like "layout" and "component" or "design". That way the styles that handle your page layout and responsiveness don't get tangled with the styles that handle the appearance of elements. Frameworks like tachyons or tailwind have basically inverted the specificity/explicity/reach pyramid that is known from soft CSS frameworks like ITCSS. Their css file is quite similar.

harimau777 7y ago
I could see that working if the designers commit to limiting themselves to what is in the CSS. However, in my experience they generally want pixel perfect implementation of any design they come up with. As soon as that happens, I think that utility CSS becomes a major liability.
- deltron3030 7y ago
  Design systems that UI designers come up with can be baked into the utility css stylesheet in advance, before devs or other designers access it through html. Kinda like a living style guide, but in code. That's really the point, the css stylesheet is basically an intermediary step and single source of truth for the styles in the design. Then when stuff is being built devs don't have to think about styling, only layout and applying the correct values that are predefined in the css. That said, if you're on your own, have your own boilerplate and design skills that you can apply in real time and know css/html, you might be better off with regular css.
  - dsego 7y ago
    Design systems that UI designers come up with... and then break them later every chance they get, because unlike what developers believe, design is not always lego blocks and styles will be tweaked to fit the context. A developer sees the sum of all UI components on a page, but the designer sees missing accents or not enough spacing and will adjust those to fix issues or achieve a particular look... the result being new styles for that page.
    - csande17 7y ago
      +1. A lot of design systems assume that, for instance, there are only a few amounts of vertical padding you'll ever want to have on an element. But sometimes, the designer really will tell you that something needs 10 pixels of padding, your 8-pixel "p-2" value is too small, and your 12-pixel "p-3" value is too large.

meerita 7y ago

> To each their own, but I personally learned to hate this approach. In my experience, it leads to a CSS spaghetti full of overrides and `!important` just to get all the utility classes to play nicely across a site. And of course the markup becomes less readable. I wrote many many CSS lines in my life and !Important is part of OOCSS world more than utility first. How do you write !Important in a functional space? It's kinda impossible unless you want to overwrite things too much from outside the funcional classes. That would be a problem and it would tell you that your approach was not good from start.

hinkley 7y ago

We have bad terminology and insufficient training I think. We are deep into metric dysfunction now thinking the repetition of very small blocks of text is wasteful, even shameful. That’s not the duplication that matters. The duplication that matters is the effort. Having to do the same action over and over, and ensuring the same result occurs. That’s expensive. That’s draining. Trying to deduplicate code that is structurally similar but has different aims just creates a problem later on.

dwaltrip 7y ago
> Trying to deduplicate code that is structurally similar but has different aims just creates a problem later on. This is one of the most important lessons I've learned in software. Abstractions work well when the snippets in question have similar, coupled requirements. The proposed abstraction must target the shared requirements, or it will soon cause more problems than it solves as the snippets diverge due to their different purposes. Structural similarity alone provides very limited opportunity for a robust abstraction. A rough heuristic that may indicate one of these problematic abstractions is the number of special cases and if-elses that are continually being added to make it work.
harimau777 7y ago
The issue, at least as I understand it, isn't so much in the fact that code is being duplicated. Rather, the problems that I see are: - Having lots of utility classes applied to the tags in HTML make it difficult to read. In particular, when it becomes necessary to split a tag onto multiple lines the HTML can become less effective at visually indicating how tags are nested. - Including styling in HTML obscures the intent of the HTML. For example, is this div here because this is actually a new semantic section or just because we needed somewhere to put utility classes?

jeffkeen 7y ago

I'm with you. I think Trello's CSS guide they put out a few years back was the sanest approach to writing manageable CSS I've found. It's something I try to follow in every project. https://github.com/trello/trellisheets/blob/master/styleguide.md https://github.com/trello/trellisheets/blob/master/styleguid...

andrei_says_ 7y ago

I think it’s a good option if: - you build js components - you don’t know css that well - you don’t want the cognitive load of naming styles, esp. as a team. I do know CSS, do not use react, and am used to BEM, so this is not a solution for me.