🤔 What's the best way to structure your classes and markup when building UIs with Tailwind CSS?
Here are some of the rules I follow to build things that are consistent, easy to understand, and straightforward to componentize 👇
Sort classes generally from the outside in (in terms of the box model) putting things that affect layout before things that don't, while also trying to group related classes.
This lets you see the things that are going to have the biggest impact quickly.
☝️This is a bit of an art, but hoping to automate in the near future!
I've been working on nailing the recommended class order a bit lately — check out my list so far on GitHub:
Group responsive classes together by screen size, following the same order that the classes would override each other in.
This makes it easy to see all the classes that would be applied at a breakpoint at the same time.
Group state variants together, and do that within each breakpoint — again to make related changes easy to find.
Use screen size prefixes even in situations where it's not technically necessary because a class has no effect without being paired with another class.
It's a few more characters, but it's much more clear to other people on the team.
Prefer top and left margins over bottom and right margins.
Why? Because having a rule just makes it one less thing to ever think about, and you'll move faster.
Exception: If a margin is needed because of an optional element that is sometimes shown and sometimes not, always put the margin on that element, even if it means using a bottom or right margin.
This makes the code simpler and eliminates extra conditional logic.
When the complexity and effort is equal, always prefer the solution that makes elements easy to delete.
This makes things easier to componentize and reuse.
Always put margins on the outer-most element possible.
If you don't, people will wonder why and assume it's for some special purpose, which slows people down when trying to understand the code.
Always try to make elements in a loop identical, using techniques like negative margin and `flow-root` on a parent element to counteract unintended spacing.
This lets you avoid dynamic/conditional logic and makes things easier to break up.
Use the `space-x/y-{n}` utilities (or `gap` if you can!) to handle the space between items instead of repeating yourself.
This makes it easier to adjust the spacing, and better captures your intent for other people reading the code.
Don't use the `space-x/y-{n}` utilities for adding space between just two items, especially when those items each contain many lines of code.
This can make it annoying to find where the spacing is coming from in complex templates.
Implement the same visual patterns using the same code patterns, even if it's possible to optimize in some situations and use fewer HTML elements.
This makes things much easier to componentize and turn into a system.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Last month, over 200 people got together in my hometown of Cambridge, Ontario to hang out, talk shop, and get a peek behind the curtain at some of the new stuff we’ve been working on.
Tailwind Connect started out as an idea for throwing a little local meetup while the team was in town, but naturally ballooned into us renting a massive hall, hiring a crew of four videographers, and racking up a catering bill that put my own wedding to shame.
But even though we got a little carried away with the production, we tried to make it feel more like a meetup than a conference. We ran the event in the evening and kept it to just one presentation, leaving as much time as possible for people to just hang out and connect.
I've never worked on a site where dark mode was as simple as "replace every instance of hex code A with hex code B."
The color changes are very often context-specific, so if you're using CSS variables to support themes, you need to name those contexts, like GitHub has:
Notice the "Show All Properties (389 more)" at the bottom? Yeah, there are a _lot_ of context-dependent color tweaks that need to happen in every supported theme.
This is why dark mode support works the way it does in Tailwind. It lets you make context-specific design decisions for dark mode right in the template, without identifying, naming, and hoisting every single context out of the design.
It’s weird that anyone thinks Tailwind isn’t suitable for super custom designs. That’s literally the reason I made the framework, to build super custom designs faster.
I've always loved how much polish a subtle animation like the one on this Stripe button can add to a UI 😍
Let me show you how to recreate it with Tailwind CSS! 🧵
First, let's create the button! We'll use `rounded-full` for the pill shape, add padding with `px-4` and `py-1.5`, set the font-weight with `font-semibold`, add color with `text-white` and `bg-slate-900`, then set a hover color with `hover:bg-slate-700`.
Are there any email marketing/newsletter tools designed for technical people? All I want in the world is to write emails in markdown and include code snippets.
I want to do a lot more newsletter writing but the friction with all the WYSIWYG crap is brutal 😞
"HEY World" is by far the closest thing I've found to the right level of friction-free newsletter publishing (even without markdown or code support), but for sending stuff to the Tailwind newsletter it feels weird to not come from our domain.
This is my current oh-my-god-I-want-to-blow-my-brains-out workflow:
1. Write in Markdown in my editor, leaving little comments where I need to add images.
2. Optimize images myself and upload to DigitalOcean Spaces (to bypass brutal compression applied by newsletter software.)
For better or worse my entire approach to business is “make whatever I want, and hope enough people pay for it for it to work.”
Like a band making music — write songs you’re excited about, not the songs people want you to write. Might fail but at least you’ll have fun.
To be clear this isn’t advice, and it’s the furthest thing from a recipe for success. But if you’re lucky enough to have this, I would be careful to fall into the trap of doing what people ask you to do instead of just continuing to live the dream.
As an example, we released these Tailwind CSS templates earlier this week and we used Next.js because we like using Next.js. I’ve gotten lots of feedback like “not all your customers use React” and yeah that’s true! But that assumes we’re customer-driven, and we’re not.