What you need to do is heavily use the `extends` property of your tailwind.config.js so it applies the paddings and margins you seek to ALL properties.
I'm curious what you're adding to your custom config to make it so bloated? I've been using Tailwind on a number of sites, big and small, and have yet to run into any situations like you've described.
The custom stuff in our config was mostly the need to create standard styles for components. Eg. button large, button small, etc. to correspond with our design system.
For example, here's tailwind code required to create a button large: bg-violet-100 text-violet-700 text-base font-semibold px-6 py-2 rounded-lg
How the hell does that help with consistency? You have to copy paste that mess every time you create a new button, and then guess what happens if the button you copied from needed special margin? Try debugging that if something looks wrong. Also try turning that into dark mode.
Now you've got to search through the spaghetti to find what's custom about this button and fix it every time.
You know what's easier? Creating a ".btn-lg" style to fit our design system, and just typing .btn-lg each time. It also has the bonus of making your code actually readable.
Maybe this is solved with the groups functionality in the latest tailwind, but this is just one of the frustrations I eventually developed.
No, your designers should already be working to scales for size, colour etc. which you can implement in Tailwind. If they don't, now's a good time to start.
> How the hell does that help with consistency? You have to copy paste that mess every time you create a new button
You're extremely not supposed to copy-paste that. You're supposed to extract it somehow, either with your Javascript component framework, or by making a semantic class with the @apply directive.
https://tailwindcss.com/docs/extracting-components
The difference is that Tailwind allows you do some quick work without coming up with abstractions. So you work bottom up instead of top down.
> then guess what happens if the button you copied from needed special margin?
That's the beauty of it! You have a button class, and then if your button needs "a little extra" you add the button class and the margin utility.
At my previous job, when this situation came up, the normal way was to make a BEM class specific to the location, import the button in that (with a SCSS mix-in) and add the margin. So the HTML would have a class name that was specific to this one button, but you didn't know what it added: class="info-page__navigation__button". With Tailwind, you get 'class="btn mx-2"' and you can basically see what it's going to look like.
If I’m using React components, tailwind makes even less sense.
I’ve already separated my button large out as a component, guess what happens in a mature design system? The system gets updated and changed to fit the needs of the product.
So what happens when you need to change button large in tailwind? You need to restyle the button with the spaghetti mess (maybe add something to the config), then re-extract the mess into a tailwind component. Now you’ve got components within components just to emulate the abilities CSS has right out of the box.
Guess what you could have done? Just had a .btn-lg class in an old school style sheet where you updated to the new font weight and padding and you’re done!
There is no need for this layer of complexity and abstraction of CSS. CSS is literally the easiest thing in the entire stack. Why do you want to make it so complicated?
Rube Goldberg machines are extremely elegant in their beauty, but they are not the most efficient way to get something done.
I absolutely do have a .btn class in my Tailwind projects, that's a given. For consistency, it's built from the utility classes that Tailwind provides, but buttons are kind of a pathological case in many ways, they're really not how you should evaluate a framework. When I put two buttons next to each other, I don't make a new class for one of the to get some spacing, I just slap a "ml-4" on one of them, and that matches all my other spacings.
But the real magic is when I'm building up my mid-level components, I don't have to try to come up with names or abstractions for the CSS, I just make things look and work right, and as I notice patterns I can break them out into semantic classes as needed. It's a great way to work and the results have been good for me.
In my mind, the real mess is a bunch of poorly named CSS classes that end up being specific to the place where they're used. Specificity battles, 40 character BEM selectors, mismatched margins sizes and randomized colour palettes. Setting up a Tailwind configuration is a very ergonomic way of turning your basic design system into CSS.
In other wards instead of doing <button class=“btn-lg><button/> you're doing <Button {...specs}/>.
This is also what CSS does for you natively. Tailwind is a beautiful, elegant, and ultimately unnecessary layer of complication.
It feels powerful and fast to beginners, and then you go through a design system overhaul with it, and start wishing you had just used bootstrap style class names and avoided the whole mess.
When it comes to code reuse, either extract the button to a component that you reuse, or extract it to a class in tailwind.
.btn { @apply px-4 py-2 rounded }
If you’re using components then you just create the button in a single place and reuse it. If you have custom requirements for the button then you override it.
It’s really quite simple and easy to do everything you’re describing. I’d read the docs and watch some videos on it and start working with it instead of against it.
Or don’t use it at all, makes no difference to me!
.btn { padding: 4rem 2rem; border-radius: 2rem; }
.btn { @apply px-4 py-2 rounded }
Agree with that. Wish the custom theme mechanism becomes mature enough like React components.
Until then the best bet i found was to use our own styles along with tailwind class names
Otherwise you’re just fighting against the framework.
Why not? They usually benefit from having consistency in the design and that's where utility classes work best.
However, tachyons is even worse than Tailwind in that it offers far too few classes for margins, padding, widths, etc. so you end up having to build everything custom anyways.
And you can't just "try" one of these frameworks once or twice, you have to memorize their particular syntax or you lose all of the benefits of using them. After spending hours learning tachyons syntax and googling about 17,000 times, I had forgotten the tailwind way. And when I went back to tailwind I had to google every time I wanted to add a style again.
Ultimately, CSS frameworks don't save you time unless you pick 1, customize it to your needs, and do front-end stuff full-time so you don't forget the syntax.
We use what they give us, it works.
As in
color: c(cool-gray-800); background-color: c(cool-gray-100); font-family: ff(sans-serif); padding: s(m);
Where c, s and ff are SCSS functions returning a value defined in scss maps.
If you find the tailwind definitions useful, they’re easy to borrow.
This is precisely where Tailwind breaks down IMO. It's fast for landing pages and smaller sites--but when implementing a real design system across a complex web app, Tailwind is a nightmare. We've had to add so much custom stuff to the config file it's basically the same mess our CSS was before.
I've been-there-done-that with the whole CSS framework world (have used Bootstrap, Tachyons, Bulma, Tailwind in many projects) and have completely reverted back to custom stylesheets with a few select utility classes that make sense.
Padding, margins, widths, heights do not make sense as utility classes IMO.
Type scales, type modifiers (like font-weight), and commonly used things like margin-x-auto and 100% width do.
I wish there was a CSS framework that only contained a minimal set of common utilities (like the ones mentioned above) and required no complex build process BS or NPM.
I just want a simple boilerplate, nothing else.