Tailwind is a different way of writing CSS, with some guard-rails coming in from the design system consistency. Tailwind also provides sane defaults (rem over px, for instance).
If someone's bad at writing or thinking in CSS, chances are, they'd be bad at Tailwind too.
I've found Tailwind helps me focus on writing the CSS that matters. But just having Tailwind CSS in a project won't automagically fill one's gap in CSS knowledge.
This isn't bootstrap, where one can use some col-* utilities and magically get a grid layout that just works across browsers.
Tailwind is a bit lower level, and to achieve similar responsive layout, you still have to know how to do that with CSS grid, what the breakpoints are etc.
Where Tailwind aids here, is by providing utility classes that help with original CSS grid intuition. For instance, `grid-cols-2 sm:grid-cols-4 md:grid-cols-6` would be hard to achieve by hand, writing vanilla CSS or styled-components.
> A bigger project with multiple pages having full on Tailwind css classes peppered everywhere looks to be a nightmare.
Ideally, you would be using a framework to help organize code better. Most likely React or Vue or something similar.
In which case, you'd already have components.
There are more than one way to achieve same look and feel, with CSS. Similarly, one can apply some discipline with using Tailwind's utility classes, when building anything.
Two heuristics that have worked for me, are:
- Never use margin if you can, use flex-box and grid with gaps instead. Placing a children node is parent's responsibility.
- Write symmetric CSS. Prefer px over pl or pr, mx over ml or mr etc.
Using margins make it hard to extract some React markup as a reusable component. Using symmetric CSS gives you automatic RTL compliance without using any of the CSS logical properties.
Sure, there'd be times when a UI design cannot be implemented without breaking some of these. But in most cases I've encountered at work, building consistent UIs, have been easy for me and my team following these.
Happy to go into details with code examples, if anyone's interested.
Padding > Margin can also be a good idea, even if working vertically. Padding cannot collapse which is usually what you want. Obv, ymmv.
We had to use `rtl:` directive only in one component, where we were animating translation property, of a switch toggle. `translation-x-` is RTL specific, so we've to apply negative translation if `dir="rtl"` has been set.
Otherwise, this symmetric-utilities-only approach worked really well across dropdowns, modals, tooltips, buttons, inputs etc., even when we integrated these components in different existing products across multiple teams.
I hope one day Tailwind CSS team release an update with underlying CSS for px-, mx-* being replaced with CSS logical operators for corresponding properties. Not sure where the browser support for the same is currently.
Good idea, but importantly only applies to flex and grid layout, not paragraph-like blocks of content.
It is not a good practice to use flexbox for layout, especially if there are nested flexboxes. It takes a lot of time to recalculate such a layout, which can be seen when resizing a desktop browser, or when advertisements load on the page and the layout shifts.
”Write symmetric CSS. Prefer px over pl or pr, mx over ml or mr etc.”
Usually but not always. For example, text boxes can look more visually symmetric with less padding on the ragged side, while interaction-heavy mobile layouts may want to have a larger padding on the right to give the user something to safely scroll.
What does this mean? What's the difference between the two?
Container blocks contain other container blocks or content blocks, but never both at the same time.
Content blocks are paragraph-like content and may contain blocks (headings, media) and inline content (leading and body text, captions).
Example hierarchy: layout > main content area > hero element > positioned container > content block > heading
In fact, I'd expect it to be more maintainable, exactly because it removes the indirection of CSS classes. They're an abstraction that don't make much sense if you're already using components, and the very point of that abstraction -being able to reuse styles- is the very reason it quickly becomes append-only. With Tailwind, you can safely delete styles, knowing it won't affect styles elsewhere in your project.
A bigger project with multiple pages having full on Tailwind css classes peppered everywhere looks to be a nightmare.
Does anyone have experience jumping into an existing larger project with legacy tailwind all over the place? Would you do it again?