4 ms·

I used to write only in Sass for these same reasons, but switched back to CSS. CSS now has variables (if you really need them -- chances are you don't). The r

I used to write only in Sass for these same reasons, but switched back to CSS. CSS now has variables (if you really need them -- chances are you don't). The redundancy of writing a selector multiple times is sightly annoying, but I don't think it rises to the level of value I need to include a new dependency in my app or build pipeline.

intertextuality 7y ago
That still doesn't account for mixins, which turn out to be very handy. Some examples here.[0] [0]: https://css-tricks.com/custom-user-mixins/ https://css-tricks.com/custom-user-mixins/ These are preferable because you can compose them as needed for elements, instead of having to make extra classes. > CSS now has variables (if you really need them -- chances are you don't). I fail to see how you could -not- need variables. Not many, mind you, but using none at all boggles the mind. For starters, DRY code is fairly fundamental. When you update a referenced variable you only need to do it in 1 place. Relying on "find and replace" leads to "oops I accidentally missed one, now we have a bug that could have been totally avoided". It also helps with consistency for site theming/branding. You can define $primaryColor, $primaryHighlight, $secondaryColor, $textColor, $backgroundColor, etc, and reference these down the line instead of copy/pasting and getting bugs if the specs change.
- boomlinde 7y ago
  > When you update a referenced variable you only need to do it in 1 place. Relying on "find and replace" leads to "oops I accidentally missed one, now we have a bug that could have been totally avoided". Isn't that the point of selecting classes in the first place? That said, I understand the utility in using it for things like individual colors, as you described.
  - intertextuality 7y ago
    Classes do suffice if you follow the convention of "small, atom-like css classes". I personally hate this style and prefer compositional css classes for a component or a structured object.

intertextuality 7y ago

That still doesn't account for mixins, which turn out to be very handy. Some examples here.[0] [0]: https://css-tricks.com/custom-user-mixins/ https://css-tricks.com/custom-user-mixins/ These are preferable because you can compose them as needed for elements, instead of having to make extra classes. > CSS now has variables (if you really need them -- chances are you don't). I fail to see how you could -not- need variables. Not many, mind you, but using none at all boggles the mind. For starters, DRY code is fairly fundamental. When you update a referenced variable you only need to do it in 1 place. Relying on "find and replace" leads to "oops I accidentally missed one, now we have a bug that could have been totally avoided". It also helps with consistency for site theming/branding. You can define $primaryColor, $primaryHighlight, $secondaryColor, $textColor, $backgroundColor, etc, and reference these down the line instead of copy/pasting and getting bugs if the specs change.

boomlinde 7y ago
> When you update a referenced variable you only need to do it in 1 place. Relying on "find and replace" leads to "oops I accidentally missed one, now we have a bug that could have been totally avoided". Isn't that the point of selecting classes in the first place? That said, I understand the utility in using it for things like individual colors, as you described.
- intertextuality 7y ago
  Classes do suffice if you follow the convention of "small, atom-like css classes". I personally hate this style and prefer compositional css classes for a component or a structured object.