I'm a selftaught (web) developer. On sunny days, you can find me hiking through the Teutoburg Forest, on rainy days coding or with a good fiction novel in hand.
What even this article is missing: Global CSS variables. I'm talking about the color-brand or text-small that exist above your modular style scope.
Granted, you can extend Tailwind with your own classes. But I don't want to play hide and seek with colors when receiving feedback from a client. Imagine they want each h1 tag in gray-200 colors now instead of gray-300 when:
in dark-mode
the text is hovered
the user is on a mobile device
The only change I'd like to make is the variable --text-color-primary and be done with it. The rest will be handled by SCSS utility functions.
so separating styles or having them "inlined" is pretty much the same from the "outside world"
Can't agree. CSS is, indeed, a layer on top of structured HTML. It can-and imo. has to-be abstracted to make it maintainable. And changeable within a reasonable amount of time. Within a CSS structure, I then separate again-between variables, base styles, component styles, utility styles, and so forth.
This is (almost) also true for components. But extending components by, say variants with Tailwind or Stilify, will undoubtedly lead to unreadable templates.
The same applies to styles, if you need a style to be shared between different modules, then those styles shouldn't be locked inside a single module, and instead, be shared
I think I caught you here. The idea of sharing is only possible if you actually do separate by concerns. For instance, inline styles cannot be shared. Stilify CSS can, because it feels like reverse-engineered inline styles.
then those styles shouldn't be locked inside a single module,
And I'm fully with you: Why declare styles in your HTML while you can do the same in CSS?
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
First off:
That thanks goes back to you, on top of it (I can't believe I write this): Thank you for staying on topic.
I do understand your points, and while I can't relate, I figure: The concept doesn't have to work for me as long as it does for you.
A few closing words from my side:
It was the first quote I stumbled across. If I were to pick something more substantial, I'd go for Adam Wathan's article in which he speaks about his transition from "Semantic CSS" to "Utility first".
What even this article is missing: Global CSS variables. I'm talking about the
color-brandortext-smallthat exist above your modular style scope.Granted, you can extend Tailwind with your own classes. But I don't want to play hide and seek with colors when receiving feedback from a client. Imagine they want each h1 tag in gray-200 colors now instead of gray-300 when:
The only change I'd like to make is the variable
--text-color-primaryand be done with it. The rest will be handled by SCSS utility functions.Can't agree. CSS is, indeed, a layer on top of structured HTML. It can-and imo. has to-be abstracted to make it maintainable. And changeable within a reasonable amount of time. Within a CSS structure, I then separate again-between variables, base styles, component styles, utility styles, and so forth.
This is (almost) also true for components. But extending components by, say variants with Tailwind or Stilify, will undoubtedly lead to unreadable templates.
I think I caught you here. The idea of sharing is only possible if you actually do separate by concerns. For instance, inline styles cannot be shared. Stilify CSS can, because it feels like reverse-engineered inline styles.
And I'm fully with you: Why declare styles in your HTML while you can do the same in CSS?