How I Accidentally Ended Up With My Own CSS Framework - aardCSS

I want to be clear from the outset that this was not the plan.

The plan was to build some websites. Simple, fast, reasonably handsome websites for small businesses and organisations that do not need a shopping basket, a member area, or an entire industrial estate of JavaScript tooling. I’d settled on Hugo as my static site generator of choice, and I wanted a sane way to make things look decent without hand-rolling all the CSS myself like it was 2004 and I had something to prove.

So I started looking at Hugo themes. This turned out to be a reliable way of finding things that were nearly right in exactly the wrong ways. A lot of the good-looking ones were built on Tailwind, which meant Node.js, npm, and the usual stack of dependencies I was specifically trying to avoid. No thanks. I want websites that work, not websites that need a supply chain.

After rejecting most of what looked promising, I started looking at lightweight CSS frameworks instead. My requirements were not especially exotic: no build step, no JavaScript dependency, sensible semantic HTML support, and preferably something small enough that I could actually understand what it was doing. I am in my fifties. I do not want to learn a framework the size of Belgium.

I looked at Pico CSS. Clean, classless, styles semantic HTML directly. Genuinely liked it. I looked at Pure.css. Fine. Functional. About as exciting as its name suggests. And then I found µCSS. µCSS ticked every box. No build step. Pure CSS. Built on Pico CSS v2, which I already liked. Modular component files. Twenty colour themes. Proper dark mode support. The kind of thing where you include one file and your HTML immediately looks like someone who knows what they're doing made it.

There was, however, a small issue. The project was nine days old.

Now, I want to be clear that a nine-day-old CSS framework is not, in itself, a problem. CSS doesn't rot. It doesn't phone home. It doesn't have a supply chain that gets compromised at three in the morning. Once you've downloaded the file, that file will continue to be a file for as long as files exist. I am not exaggerating when I say the maintenance concern for a static CSS file is roughly equivalent to the maintenance concern for a brick.

But. There was a nagging feeling. What if it disappeared? What if it never got updated and I found a bug I couldn't fix? What if, having built half a dozen client sites on someone else's framework, I wanted to customise something in a way the original author hadn't anticipated? The answer, obviously, was to fork it.

So I did. I cloned the repository, redirected the git remote to my own GitLab account, and then — and this is the bit where it stopped being sensible and started being fun — I renamed everything. All eighty-odd files. Every CSS variable. Every internal reference. --mu- became --aard-. mu.fuchsia.css became aard.fuchsia.css. The whole thing, top to bottom, now says Aardvark Web on it.

Is it meaningfully different from µCSS? No. The underlying code is Amaury Bouchard's work, built on Lucas Larroche's PicoCSS, and I've been careful to keep the MIT licence intact because I'm not an animal. But it lives on my GitLab. I control it. If µCSS disappears tomorrow, I have my copy. If I want to add a new component or a new colour theme for a client, I can do that without waiting for a pull request to be reviewed by a stranger on the internet.

And if I want to tell people I have my own CSS framework, which I absolutely do, I can do that too. aardCSS. It's a thing. I made it. Sort of.