She writes from a place of vulnerability and honesty. Most people write to sound smart and she writes to say "I don't know it all but there are some things I discovered I want to share." I almost feel like she writes to share things with people she loves, even though she doesn't know them directly.
She spoke alongside Randall Munroe at the last Strange Loop (RIP). Some people waited to talk to him afterwards, but I waited to talk to her. I don't think she got my joke that she should rewrite her bash scripts into perl and for that I'm truly sorry.
I'm a fan of removing any dependencies on external libraries and writing my own solution from scratch, but there's a good reason why I decided not to do so with Tailwind: They offer an optimization for production that ensures that you never ship more than the bare minimum of CSS needed. This means you can keep your palette of color, spacing, and other options fully enumerated in `globals.css` and elsewhere, without worrying whether you're using all those variants in production. Moreover, if you're working within a framework, such as Next.js, this minimization step automatically happens when you build, without even having to worry about whether it's happening. This alone is a compelling reason, at least for me, not to migrate from Tailwind.
Also, I've never found any restrictions in Tailwind in using inline CSS that weren't readily navigable, or in implementing really nice responsive grids that handle different screen widths for instance using Tailwind's grid tooling. I definitely have solved each of the scenarios described in this article using Tailwind or a Tailwind-CSS combination, but it's true that they don't have grid-column-areas natively. Still, I haven't yet found that to be a significant restriction in getting responsive grid layouts.
I think the biggest issue with Tailwind is simply that it takes a long time to get used to reading it. We all learn that inline CSS is bad, globally scoped CSS is best, etc., and we get used to seeing clean simple HTML. Then we look at real-world code featuring Tailwind and it just looks so hard to read at first, especially because the lines are so long. I guess I just have been using it long enough that I've gotten completely used to the way it looks, but I do remember it took me a very long time to get comfortable with reading Tailwind. After a long while, I concluded that, for me, Tailwind really is more efficient and maintainable and even more readable, but it definitely took quite a bit.
- Engineers never learn to properly use developer tools to debug CSS
- Components get gigantic bloated piles of classes that are not human readable
- Those gigantic piles of classes get logic in them, that often would have been easier to write as a CSS selector. Tailwind developers learn to write a JS ternary operator with a string of classes instead of ever learning how CSS selectors work
- Those ternary operators get too complicated. The engineers write object maps of Tailwind classes, or export consts of strings of Tailwind classes to use later. Those object keys and const names are what the CSS class names could have been if they just used CSS. They literally re-invent CSS classes, but worse.
- Tailwind classes can't be migrated. You can migrate CSS to Sass to CSS modules to Emotion CSS to etc mostly just by copying them over, because all of those are CSS (with some quirks). Tailwind classes are non-transferable
The happiest medium I've found was in an organisation of around 200 UI engineers: scoped CSS so that engineers can work with autonomy without colliding with other engineers, plus Tailwind for quick band-aid fixes.
I still like it though. it’s one of those abstractions that actually helped me learn. I would go to the tailwind doc pages and see the underlying css of any class.
There were some other frameworks I got excited about: vanilla extract and stitches, both made by some really talented people. I wonder why those never quite got the same traction…
> I got curious about what writing more semantic HTML would feel like.
This is so relatable. In the beginning of my career, I used to add so many dependencies for things I did not know. But these days, I mostly work on removing dependencies because I'm a lot better at using the web platform. I treat the web platform and browser primitives as materials to build what I want rather than a blank canvas to paint things from scratch.
css applies attributes to objects via graph queries
the queries are tightly coupled to the tree. you must work hard to avoid scatter gun edits now. it doesn't make much sense to have attributes stores in a separate location to their use
it would be like assigning all of your instances attributes using decorators
> Builders value getting the work done as quickly and efficiently as possible. They are making something—likely something with parts beyond the frontend—and are often eager to see it through to completion. This means Builders may prize that initial execution over other long-term factors.
> Crafters are more likely to value long-term factors like ease of maintainability, legibility, and accessibility, and may not consider the project finished until those have also been accounted for.
> In my view, the more you optimize for building quickly, the more you optimize for homogeneity.
My favorite is when colleague A broke something from colleague B, who fixed it but broke sometimes from me, and I fixed that and broke what colleague A did. The process repeated once more and it landed again on my desk, where I said wait a minute, I've been here already. We were than able to fix all three things at the same time.
So it's difficult to keep track of everything.
I've been teaching semantic HTML / accessible markup for a long time, and have worked extensively on sites and apps designed for screen readers.
The biggest problem with Tailwind is that it inverts the order that you should be thinking about HTML and CSS.
HTML is marking up the meaning of the document. You should start there. Then style with CSS. If you need extra elements for styling at that point, you might use a div or span (but you should ask yourself if there's something better first).
Tailwind instead pushes the dev into a CSS-first approach. You think about the Tailwind classes you want, and then throw yet-another-div into the DOM just to have an element to hang your classes on.
Tailwind makes you worse as a web developer from a skill standpoint, since part of your skill should be to produce future-proof readable HTML and CSS that it usable by all users and generally matches the HTML and CSS specs. But devs haven't cared about that for years, so it makes sense that Tailwind got so popular. It solved the "I'm building React components" approach to HTML and CSS authoring and codified div soup as a desirable outcome.
Tailwind clearly never cared about any of this. The opening example on Tailwind's website is nothing but divs and spans. It's proven to be a terrible education for new developers, and has contributed to the div soup that LLMs will output unless nudged and begged to do otherwise.
CSS is a skill just like any other technical skill. If all you do is learn the bare minimum so you can bodge things until you get something that looks right, then your ambitions are going to outpace your ability to keep things organised very quickly.
Maybe it's useful for people here. I don't use Tailwind or similar for styling, just CSS with modern frameworks like Astro or Svelte.
For every project I have the following CSS files:
- reset.css
- var.css
- global.css
- util.css
Other styling is scoped to that specific component or layout.
It scopes CSS to components by default, and keeps HTML, CSS and JavaScript seperate.
Separating HTML and CSS into different files is just like separating a bunch of methods/functions into different files, or splitting one monorepo into git submodules. Yeah, it sometimes makes sense, but if you're doing it for the sake of separating things then just stop.
I think the only point of Tailwind is to make front end devs realizing how much separation of concerns is misunderstood and misused as a dogma. Once you realize that you can ditch Tailwind if you like.
there is a reason why tailwind got as popular as it is today. And it only highlights the gaps in either what HTML and CSS provide for the task at hand or the difficulty in that approach. This must not be lost in any criticism.
another observation is none of technical user interface decisions or discussion emphasis on the tree data structure that is inherent to every major user interface rendering mechanism relevant today. there are inherent benefits and drawbacks of it being a tree structure that neither of the developers nor the framework leverage. when thought of as a tree, it benefits from adding certain constraints and naming conventions that allow more artistic expression using just HTML and CSS that I have not seen tailwind or any other framework encourage
EDIT: ignore. I can see you have some links in your profile. Will check it out.
25 years ago, I was appalled how Microsoft Frontpage could transform a very simple word document (with little formatting) into an utterly indecipherable mess of HTML that rendered correctly.
With very simple transformations, I could paste the text of the document into notepad and add just a few heading tags for the same rendered result but a much more understandable source.
CSS had a lot of promise for simplifying the HTML content, but the world tried its hardest to prevent that.
Now we have multi-megabyte monsters for simple webpages (before even counting graphics).
This is precisely how I do it.
Code that generates HTML. Once I can see all the content on the screen in some kind of Netscape Navigator 1.0 nightmare, then I go back and add styles to make it look pretty.
It's not hard. It just requires thought and planning.
(The best planning tool I've found is a pencil and grid paper, not the web design SaaS-of-the-moment. However, it's surprisingly hard to find good pencil sharpeners these days.)
Just using tailwind and anchoring around a design system like shadcn is just way easier for a team to align around than somebodys made up css language.
<template>
<!-- Largely just HTML -->
</template>
<script setup lang="ts">
// JS/TS as you would expect
</script>
<style scoped>
/* Component scoped styles here */
</style>
[0] Vue SFC docs: https://vuejs.org/guide/scaling-up/sfc.html
E.g. how do you style a child on parent hover with the style attribute?
can tailwind be used poorly? absolutely. but that's true of any tool
i've been writing CSS for ~20 years and am quite capable with it, having used CSS, Less, SASS/SCSS, Stylus, PostCSS etc. the reason i have settled on Tailwind for the last few years is precisely because it enables me to build more robust application styling.
tailwind frees you from having to spend excessive time building abstractions of styles/classes that will invariably change. placing the styles directly into the markup that is affected by it reduces cognitive load, prevents excessively loose selectors affecting styles unintentionally and really aids in debugging. jumping into codebases with bespoke css frameworks is always more complex and fragile than a tailwind codebase for anything but the most simple sites/apps
add to that the ability to have consistent type, color and sizing scales, reduced bundle sizes, consistency for any developer who knows tailwind and a very robust ecosystem (and thus llms are very familiar with it) and tailwind is a really excellent choice for a lot of teams
tailwind is like most tools; it can be used well or poorly depending on who is using it
I look at the royal mess that is HTML/CSS/JS as a necessary evil, required when we want to target browsers. To me it's "just the presentation layer".
In my work I put a lot more emphasis on correctness in the db schema, or business logic in the backend.
When it comes to the messy presentation layer I prefer to write a little as possible, while still ending up with somewhat maintainable code. And for this Tailwind fits the bill really well: LLMs write it very well, new devs understand it quick, and it's quite easy to read-back/adjust the code later.
I 100% agree a Tailwind project is not the best way for a new dev to learn HTML/CSS. But then I prefer the new dev to focus on great db schemas, intuitive APIs, test-able biz logic, etc. Fiddling with the mess that's HTML/CSS is not the place where I consider human attention is best spent on (or where developers pick up skills to become much better developers).
Treating markup and styles separately is great, in principle, but you'll always need additional markup for certain things. We knew this going back to the early 2000s.
There is nothing about Tailwind itself that forces you to use divs and spans instead of the appropriate HTML tag.
Documents and interfaces are different. Tailwind makes a lot more sense for interfaces. You can use Tailwind for the interface and scoped HTML selectors for other content.
Tailwind is around 4x faster and has practically no overhead compared to writing a complex CSS codebase. Whatever you think of it, this is always a benefit in its corner.
If I look at their component library, they also do the work of including aria attributes for you https://tailwindcss.com/plus/ui-blocks/marketing/sections/pr... (first exsmple with free code I've found).
If we're not talking landing pages, which are more like digital brochures, I always start with markup and then add css classes on top.
To be fair plopping a `div` everywhere started way before Tailwind. I blame React and the mess that is CSS in JS for this.
I tend to work closer to the latter end and find that both React and Typescript are extremely helpful to make my code extensible and maintainable. YMMV.
But for mid/large projects, I find that TypeScript brings sanity to JavaScript.
I love some quick and dirty JS project. But after a certain project size I begin the see runtime errors like undefined, NaN, 'false/true' concatedted to URLs, and so on. TypeScript eliminates a ton of those.
Frameworks like React that add structure to the data flow, component encapsulation, and a huge repertoire of patterns to train on, plus Typescript for immediate compile-time feedback loops… those are what LLMs thrive on.
I have these two https://reddit.premii.com and https://hn.premii.com/ both works without any changes. Reddit will stop working once they kill the apis but until then it will work.
Hmm, yes, simply have the LLM write good with no mistakes.
Abstractions like a hero image, a menu, a headline? Sure, it's easy to overthink things but most of the time, it's not that complex.
> placing the styles directly into the markup that is affected by it reduces cognitive load, prevents excessively loose selectors
In my opinion, it's the opposite. Besides the obvious violation of DRY and the separation of concerns, inline CSS can't be cached and it creates a lot of noise when using dev tools for debugging. It actually increases cognitive load because you have to account for CSS in two different locations.
Lots of people use Tailwind because they don't want to deal with the cascade, usually because they never learned it properly. Sure, back in the day, the web platform didn't provide much built-in support for addressing side effects of the cascade, but now we have @layer and @scope to control the cascade.
Tailwind uses a remnant of '90s web development (inline CSS) and built an entire framework around it. I get why it appeals to some people: it lets you use CSS while not requiring an understanding of how CSS works, beyond its most basic concepts.
If a power tool is poorly designed it may not force me to hurt myself but if it makes it easier that’s a problem.
I think that upside became more prevalent in the reusable components era, whereas previously CSS was targeting an entire HTML file (and thus the reasoning was more like SQL query than "this one element's styling").
With LLMs I think this upside is much smaller now though.
That seems like a false dichotomy. I'm a huge fan of locality (both in software engineering and in physis) but you can also "localize" your styles by scoping them appropriately. (Modern frontend frameworks typically do that automatically for you at the component level.) There is no need to use Tailwind for that.
It gets really easy to lean on class-based CSS and use a `<div>` for everything instead of ever learning what a semantic element is.
And that contributes to other bad habits, like writing a bunch of JavaScript to define behavior that could just be natively handled by your browser.
A weird personal irony is that because no employer has ever asked me to directly write CSS, what's actually made me better at CSS is JavaScript -- namely that my understanding of selector logic has improved a lot after picking up Web scraping.
The HTML bloat was really tough to deal with. I spend far more time in HTML than I'd like, and having more Tailwind classes than I do semantic HTML was really tough to look at.
I've settled on using vanilla CSS and applying styles per-page on an as needed basis. For example, include base styles (reset, primary theme, etc) and then include marketing styles (or: blog styles, dashboard styles, syntax highlighting styles, charting styles, etc).
It keeps each page light and minimal. Reading the HTML is easy. Styles stay consistent across any pages that share styles, etc.
There is such a thing as the ergonomics of the tool. Yes div soup has been around a long time. But also yes, Tailwind makes the wrong approach the easy one.
It’s ergonomics encourage adding div elements to support styles. It’s the core design loop.
You’re conflating “forces to” and “ergonomically encouraged”.
Can tailwind be a useful CSS framework? Absolutely, but that can be said of any of them.
Which is precisely why it makes sense to point out it's unique flaws, so that people can make an informed decision as to what works best for them.
If you have some unique feature to tailwind that you think makes it better than the rest, you should share that.
Everything you have listed is also accomplished by all the other CSS frameworks, so it almost sounds like tailwind is simply the main one you have experience with.
Totally agree. I feel like this was more a by product of React. Not that React forced this either, but it felt like the rise in both went hand in hand for some reason.
While I think it's true that none of the current top FE technologies force the div soup, they don't discourage it either. It would be nice if what ever FE technologies catch on next did try to encourage better practices around things like accessibility. Make the path of least semantic HTML the path of least resistance and allow people to fall into the pit of success, ya know?
Your comment only mentions developers as the audience of HTML authoring, as opposed to users, which is a common attitude and the core problem with Tailwind.
Every time someone says that Tailwind sucks, it’s like hearing the old me speak.
Unless you're coding on a VT100 terminal, you just put the HTML in one window and the CSS in another. Subdivide as necessary, or as your monitor space allows.
Heck, we were doing that back in 1989 on IBM PCs with MDA displays.
If your CSS is so out of control that you can't wrap your brain around it, it's time to refactor or split into individual CSS component files.
It's really frustrating to be talking with someone about Tailwind and CSS, and realize that not only do they not know what "cascading" means, they never even considered the concept might be useful in the context of a stylesheet.
We actually loved it so much that we’ve taken over maintenance of a fork, and just released our Pico successor candidate: https://blades.ninja/
@import 'tailwindcss';
p {
@apply text-justify;
@apply bg-slate-300 dark:bg-slate-800; /* Second rule just for colors */
display: block; /* regular CSS */
}
That's never been a valid argument to dismiss criticism. It wasn't with Dreamweaver, any it wasn't with visual basic, and it isn't with Tailwind.
Patterns matter. Best practices matter. Path of least resistance matters. Those are all choices you make when you develop a CSS framework. Some of those choices are good and some are bad.
If none of those things mattered, them choosing a CSS framework would not matter at all.
They fixed this later with Fragments but the damage was done.
Very similar in to early React where every component had to return a single real parent element (now you can return a fragment) so people chose div.
Not sure if it helps, but if we get our first blind user I will gladly make some admends to make it more usable for them.
It seems that Tailwind is now blamed for the mess that is HTML/CSS. Tailwind certainly allows for accessible designs; it may not be the ideal solution, sure, but what we aim for is "good enough".
I feel like old-school frontend devs bring up accessibility as a kind of bogeyman.
It reminds me of the myth that CSS style X or Y breaks accessibility "because screen readers expect semantic CSS classes". Zeldman (of A List Apart) promulgated that disinformation for years, until someone actually told him screen readers don't work that way. 90% of people who use a11y as a rhetorical cudgel have never actually used AT themselves.
Disability software that uses both the markup and the on-screen visual for decision making is likely imminent and would render most of this no longer necessary.
Claude Cowork is already doing navigation and web browsing by screenshot showing this is possible.
Isn't this slightly backwards? Why would blind users sign up if the platform isn't usable for them in the first place? It has to be usable for them for them to become users :)
Side note: if you aren’t deliberately choosing semantic elements and instead dropping aria attributes onto a bunch of divs this is an anti-pattern.
I’ve usability tested and performed user research with many users needing assistive tools and I’ve used them myself as part of design.
Basic HTML authoring is good practice for many reasons.
Not good enough. You have to be accessible before it is needed in order to avoid legal liability.
And how do you expect to get a blind user if they already cannot use your product?
None of the doctors I build web sites for are currently blind. I know this because I talk to them regularly. But I still build the web sites for the future, when HR might hire a doctor or nurse or other person who is blind, or partially sighted, or has trouble with their muscles, or has difficulty distinguishing colors.
Doing the right thing isn't that hard. Not doing it is just lazy.
No, I don’t think that’s the case at all.
And none of this really violates DRY, your unit of reuse has shifted from a CSS class to a framework component. There's nothing precluding you from using an approach like DaisyUI if stock Tailwind has too much repetition for your taste.
And when this is pointed out you’ll usually get replies that just hand wave it away as not a problem, as if things like BEM were invented for no reason.
Whenever i have written CSS/TailwindCSS which was unproblematic to extend it was when i literally switch thinking to use least amount of properties and let the page flow.
Whenever i see tons of css i know it’s brittle and will cause hours of wasted time down the line to fix something which already should have been fixed.
I think that was true at the beginning. But Tailwind is quickly approaching the multi-headed hydra it was trying to replace.
I find the "legal liability" claim hilarious... I do better than 95% of the web: as I said I HAVE some screen reader directives (just did not test it), and labels to make the app more accessible.
It’s really not when working with components instead of pages, and when working with variables properly
I don’t believe Tailwind is inherently worse than pure CSS. If Tailwind had existed from day 1 on the web and you had learned it first you probably wouldn’t say this. In fact, if Tailwind had existed first somehow, and someone came up with CSS as we know it as a new revolutionary library, I’m not sure it would have succeeded.
This is what CSS classes were made for. Of all of the arguments in favor of Tailwind, this is the one that drives me battiest. Say what you will about CSS, but "give a name to a re-usable set of styles for a component" is pretty much as fundamental as you can get.
> And none of this really violates DRY, your unit of reuse has shifted from a CSS class to a framework component.
Sure, sure. except for the inline styles everywhere. And the fact that everything is literally being repeated all over the place. But other than that, no repetition!
> There's nothing precluding you from using an approach like DaisyUI if stock Tailwind has too much repetition for your taste.
...and now you have three problems.
But sure, like most tools, it starts with understanding how it works.
Is this to be read that disabled people and their needs, or more directly from the replied-to comment, "doing the right thing", are not a focus of yours, flossly?
Accessibility isn't a checklist to cover your ass for a percentage of the population: it's for everyone. It literally makes your website less shit. You slapping an aria-label doesn't fix things.
Like yes, CSS by itself is extremely powerful, but I see no reason why you should feel beholden to use all of its features simply because they're there.
> Sure, sure. except for the inline styles everywhere. And the fact that everything is literally being repeated all over the place. But other than that, no repetition!
Well, instead of repeating inline class names everywhere, you end up with CSS properties repeated everywhere. Not really seeing the difference.
That brings with it the problem of naming a thousand things in a consistent way that everyone on your team needs to understand and remember, otherwise you end up with tons of duplicated classes, parallel systems, and bike shedding. Have we, as an industry, not felt this pain often enough yet? Do we really need to keep banging our head against the wall to figure out it does hurt?
> Sure, sure. except for the inline styles everywhere.
There are no inline styles when using Tailwind. There are references to variables from the design system.
> And the fact that everything is literally being repeated all over the place.
If you find yourself repeating the same sequence of classes, it's time to create a component in your frontend framework if you use one, or a Tailwind utility class. And even if you just copy-paste the same class strings all over the codebase, transport compression will eliminate that pretty much entirely.
Sooner or later it deteriorates.
Pretty sure they'll remember that, and they'll talk about it a lot.
I mean, to readers of these comments, I think it's right there for you: 0x3f will take "higher ROI" over "accommodate and support disabled people".
But if you're having a higher ROI writing absolute crap, feel free, it's not my website.
We were already implicitly discussing RoI when we were talking about 'legal consequences' above. This is how people decide between alternatives, generally.
Hello! 8 years ago, I wrote excitedly about discovering Tailwind.
At that time I really had no idea how to structure my CSS code and given the choice between a pile of complete chaos and Tailwind, I was really happy to choose Tailwind. It helped me make a lot of tiny sites!
I spent the last week or so migrating a couple of sites away from Tailwind and towards more semantic HTML + vanilla CSS, and it was SO fun and SO interesting, so here are some things I learned!
As usual I’m not a full-time frontend developer and so all of my CSS learning has happened in fits and starts over many years.
When I started thinking about structuring CSS, I was intimidated at first: I’m not very good at structuring my CSS! But then I started reading blog posts talking about how to structure CSS (like A whole cascade of layers or How I write CSS in 2024) and I realized a couple of things:
For example, Tailwind has:
I’m going to talk about a few aspects of my CSS codebase and my thoughts so far what kind of rules I want to impose on the codebase for each one. Some of them are copied from Tailwind and some aren’t.
I just copied Tailwind’s “preflight styles” by going into tailwind.css and copying the first 200 lines or so.
I noticed that I’ve developed a relationship with Tailwind’s CSS reset over time, for example Tailwind sets box-sizing: border-box on every element (which means that an element’s width includes its padding):
* { box-sizing: border-box; }
I think it would be a real adjustment for me to switch to writing CSS without these, and I’m sure there are lots of other things in the Tailwind reset (like html {line-height: 1.5;}) that I’m subconsciously used to and don’t even realize are there.
This next part is the bulk of the CSS!
The idea here is to organize CSS by “components”, in a way that’s spiritually related to Vue or React components. (though there might not actually be any Javascript at all in the site)
Basically the idea is that:
So editing the CSS for one component won’t mysteriously break something in another component. And probably like 80% of the CSS that I would actually want to change is in various component files, so if I’m editing a 100-line component, I just have to think about those 100 lines. It’s way easier for me to think about.
For example, this HTML might be the .zine “component”.
<figure class="zine horizontal">
<img src="whatever.jpg">
</figure>
And the CSS looks something like this, using nested selectors:
.zine {
...
&.horizontal {
...
}
&.vertical {
...
}
&:hover {
...
}
}
I haven’t done anything programmatic (like web components or @scope) that ensures that components won’t interfere with each other, but just having a convention and trying my best already feels like a big improvement.
Next: conventions to maintain some consistency across the site and keep these components in line with each other!
colours.css has a bunch of variables like this which I can use as necessary. Colour is really hard and I didn’t want to revisit my use of colour in this refactor, so I left this alone.
The only guideline I’m trying to enforce here is that all colours used in the site are listed in this file.
:root {
--pink: #fea0c2;
--pink-light: #F9B9B9;
--red: #f91a55;
--orange: rgb(222, 117, 31);
...
}
One thing I appreciated about Tailwind was that if I wanted to set a font size, I could just think “hm, I want the text to be big”, write text-lg, and be done with it! And maybe if it’s not big enough I’d use xl or 2xl instead. No trying to remember whether I’m using em or px or rem.
So I defined a bunch of variables, taken from Tailwind, like this:
--size-xs: 0.75rem;
--line-height-xs: 1rem;
--size-sm: 0.875rem;
--line-height-sm: 1.25rem;
Then if I want to set a font size, I can do it like this. It’s a little more verbose than Tailwind but I’m happy with it for now.
h3 {
font-size: var(--size-lg);
line-height: var(--line-height-lg);
}
There are some things like buttons that appear in many different components. I’m calling these “utilities”.
I copied some utility classes from Tailwind (like .sr-only for things that should only appear for screenreader users).
This section is pretty small and I try to be careful about making changes here.
“base” styles are styles that apply across the whole site that I chose myself. I have to keep this section really small because I’m not confident enough to enforce a lot of styles across the whole site. These are the only two I feel okay about right now, and I might change the <section> one:
/* put a 950px column in the middle of each <section> */
section {
--inner-width: 950px;
padding: 3rem max(1rem, (100% - var(--inner-width))/2);
}
a {
color: var(--orange);
}
I think for the base styles it’s going to be easiest for me to work kind of bottom up – first start with almost nothing in the base styles, and then move some styles from the components into base styles as I identify common things I want.
I haven’t completely worked out an approach to managing padding and margins yet. I’m definitely trying to be more principled than how I was doing it in Tailwind though, where I would just haphazardly put padding and margins everywhere until it looked the way I wanted.
Right now I’m working towards making the outer layout components in charge of spacing as much as possible. For example if I have a <section> with a bunch of children that I want to have space between them, I might use this to space the children evenly:
section > *+* {
margin-top: 1rem;
}
Some inspiration blog posts:
The way I was doing responsive design in Tailwind was to use a lot of media queries. Tailwind has this md:text-xl syntax that means “apply the text-xl style at sizes md or larger”.
I’m trying something pretty different now, which is to make more flexible CSS grid layouts that don’t need as many breakpoints. This is hard but it’s really interesting to learn about what’s possible with grid, and it’s a good example of something that I don’t think is possible with Tailwind.
For example, I’ve been learning about how to use auto-fit to automatically use 2 columns on a big screen and 1 column on a small screen like this:
display: grid;
grid-template-columns: repeat(auto-fit, minmax(min(100%, 400px), max-content));
justify-content: center;
I also used grid-template-areas a lot which is an amazing feature that I don’t think you can use with Tailwind.
Some inspiration:
In development, I don’t need a build system: CSS now has both built in import statements, like this:
@import "reset.css";
@import "typography.css";
@import "colors.css";
and built in nested selectors, like this:
.page {
h2 { ...}
}
If I want, I can use esbuild to bundle the CSS file for production. That looks something like this.
esbuild style.css --bundle --loader:.svg=dataurl --loader:.woff2=file --outfile=/tmp/out.css
Even though I usually avoid using CSS and JS build systems, I don’t mind using esbuild (which I wrote about in 2021 here) because it’s based on web standards and because it’s a static Go binary.
A few people asked why I was migrating away from Tailwind. A few factors that contributed are:
tailwind.min.css files (270K gzipped) in a lot of my projects and it feels a little silly.While doing this I learned about a lot of CSS features that I didn’t use but am curious about learning about one day:
@layer (from A Whole Cascade of Layers)I’ve been talking a lot in this post about what I learned from using Tailwind, and that’s all true.
But I read this post 3 years ago called Tailwind and the Femininity of CSS that really stuck with me. I honestly probably started out with an attitude towards CSS a little like that post describes:
They’ve heard it’s simple, so they assume it’s easy. But then when they try to use it, it doesn’t work. It must be the fault of the language, because they know that they are smart, and this is supposed to be easy.
But in the last 10 years I’ve learned to really love and respect CSS as a technology.
So I decided years ago that I wanted to react to “CSS is hard” by getting better at CSS and taking it seriously as a technology, instead of devaluing it. Doing that changed everything for me: I learned that so many of my frustrations (“centering is impossible”) had been addressed in CSS a long time ago, and that also what “centering” means is not always straightforward and it makes sense that there are many ways to do it. CSS is hard because it’s solving a hard problem!
I’ve been so impressed by the new CSS features that have been built in the last 10-15 years (some of which I’ve talked about in this post!) and how they make it easier to use CSS, and spending the time to improve my CSS skills has been a really cool experience.
And that post made me feel like Tailwind contributes to the devaluing of CSS expertise, and like that’s not something I want to be a part of, even if Tailwind has been a useful tool for me personally. Especially in this time of LLMs where it feels more important than ever to value humans’ expertise.
Another blog post criticizing Tailwind that influenced me:
Thanks to Melody Starling who originally designed and wrote the CSS for wizardzines.com, everything cool and fun about the site is thanks to Melody.
Also I read so many incredible blog posts about CSS while working on this (from CSS Tricks, Smashing Magazine, and more), I’ve tried to link some of them throughout this post and I really appreciate how much folks in the CSS community share their practices.
to be tracked here: https://github.com/anyblades/blades.ninja/issues/7