|
|
|
|
|
|
by rvense
2044 days ago
|
|
|
How is it ad hoc? You're creating a class .button, but you're using the Tailwind-specified design system. This is how the framework is meant to be used! Atomic/utility-first CSS doesn't mean that you shouldn't make classes. It just means that you should make them where they make sense. Don't make a new class just to add a margin to something,or whatever. If the margin is literally all this element needs, use the utility class directly. If it's the only place you'll use this combination of classes and naming the combination doesn't add anything, you might as well just keep it inline. But if you find yourself repeating a bunch of utility classes, make a class with a semantic name once you start seeing the pattern. In some cases, like buttons, you might see that pattern before you've even started. That's fine. You should definitely have a button class (or three). What you (probably) shouldn't have a is .info-page__navigation__aside__second_button that just includes the button class and adds a margin, or whatever... like we did at my old job. Urgh. I refer to this as "might as well be inline CSS" - making extremely specific classes that are only used once. If your CSS classes aren't reusable, all you gain from not having it inline is the joy of maintaining two text files, and manually look up the cross references. Tailwind solves this perfect, IME. |
|
|
Only if you are using a component framework or something that works like it though. Otherwise you should make semantic-style classes, yeah.
It‘s ad-hoc because you can not predict what a class contains (tailwind classes) or how it is spread through your codebase (BEM classes)