Adam Wathan has (very cleverly) constructed Tailwind with CSS Cascade Layers, making it extraordinarily highly effective for organizing kinds by precedence.
@layer theme, base, parts, utilities;
@import 'tailwindcss/theme.css' layer(theme);
@import 'tailwindcss/utilities.css' layer(utilities);
The core of Tailwind are its utilities. This implies you might have two decisions:
- The default selection
- The unorthodox selection
The default selection
The default selection is to observe Tailwind’s really helpful layer order: place parts first, and Tailwind utilities final.
So, if you happen to’re constructing parts, you must manually wrap your parts with a @layer
directive. Then, overwrite your part kinds with Tailwind, placing Tailwind because the “most necessary layer”.
/* Write your parts */
@layer parts {
.part {
/* Your CSS right here */
}
}
...
That’s an honest approach of doing issues.
However, being the dangerous boy I’m, I don’t take the default method because the “finest” one. Over a yr of (main) experimentation with Tailwind and vanilla CSS, I’ve come throughout what I consider is a greater answer.
The Unorthodox Alternative
Earlier than we go on, I’ve to let you know that I’m writing a course known as Unorthodox Tailwind — this reveals you every thing I learn about utilizing Tailwind and CSS in synergistic methods, leveraging the strengths of every.
Shameless plug apart, let’s dive into the Unorthodox Alternative now.
On this case, the Unorthodox Alternative is to jot down your kinds in an unnamed layer — or any layer after utilities, actually — in order that your CSS naturally overwrites Tailwind utilities.
Of those two, I choose the unnamed layer choice:
/* Unnamed layer choice */
@layer theme, base, parts, utilities;
/* Write your CSS usually right here */
.part { /* ... */ }
/* Named layer choice */
/* Use no matter layer title you give you. I merely used css right here as a result of it made most sense for explaining issues */
@layer theme, base, parts, utilities, css;
@layer css {
.part { /* ... */ }
}
I’ve many the reason why I do that:
- I don’t like so as to add pointless CSS layers as a result of it makes code tougher to jot down — extra keystrokes, having to recollect the particular layer I used it in, and many others.
- I’m fairly expert with ITCSS, selector specificity, and all of the good-old-stuff you’d anticipate from a seasoned front-end developer, so writing CSS in a single layer doesn’t scare me in any respect.
- I can do complicated stuff which can be exhausting or inconceivable to do in Tailwind (like theming and animations) in CSS.
Your mileage might range, after all.
Now, if in case you have adopted my reasoning up to now, you’d have observed that I exploit Tailwind very otherwise:
- Tailwind utilities usually are not the “most necessary” layer.
- My unnamed CSS layer is a very powerful one.
I do that so I can:
- Construct prototypes with Tailwind (shortly, simply, particularly with the instruments I’ve created).
- Shift these properties to CSS once they get extra complicated — so I don’t should learn messy utility-littered HTML that makes my coronary heart sink. Not as a result of utility HTML is dangerous, however as a result of it takes numerous mind processing energy to determine what’s occurring.
Lastly, right here’s the good factor about Tailwind being in a utility layer: I can at all times !necessary
a utility to present it energy.
...
Whoa, maintain on, wait a minute! Isn’t this fallacious, you may ask?
Nope. The !necessary
key phrase has historically been used to override courses. On this case, we’re leveraging on the !necessary
function in CSS Layers to say the Tailwind utility is extra necessary than any CSS within the unnamed layer.
That is completely legitimate and is a built-in function for CSS Layers.
Moreover, the !necessary
is so express (and used so little) that it is sensible for one-off quick-and-dirty changes (with out making a model new selector for it).
Tailwind utilities are extra highly effective than they appear
Tailwind utilities usually are not a 1:1 map between a category and a CSS property. Constructed-in Tailwind utilities principally appear to be this so it can provide folks a fallacious impression.
Tailwind utilities are extra like handy Sass mixins, which suggests we are able to construct efficient instruments for layouts, theming, typography, and extra, via them.
You will discover out about these ideas inside Unorthodox Tailwind.
Thanks for studying and I hope you’re having fun with a brand new approach of (or utilizing) Tailwind!