A month ago, I decided to make a tiny innocent change to my blog: change the dates to ISO 8601 format, AKA just ISO dates, which has been my favorite way to write dates ever since I started journaling on a computer.

That little change proved to be more involved than I thought, and broke a few things. I have since then fixed them, but others are still hidden. At this point, I’m starting to lose track as to what I broke with that change and what has been, to one degree or another, broken for a while.

Wait, how can something on a website be broken to one degree or another? Is it broken or not? Well, you see… CSS.

If you go to my actual website (RSS wouldn’t pick this up), you’d see that the dates for each blog post use the same red color as the heading and other elements in the theme. That red has been with me for a long time, since the days of the old blog and before. If you inspect it in your browser, you will see that this color (#8b0000) is defined in custom.css, but the font size is defined in main.css. The element, a.post-date, is defined in both of those CSS files.

That’s because when I changed to ISO dates, I forgot about my custom.css. The size was off, I right-clicked, figured out where to make the change, and made it. But custom.css is there for a reason. It’s a file meant to replace the default theme with, you guessed it, whatever custom changes I want to apply.

My memory is a funny place though, and it seems like I forget this file exists at times. The result is a bunch of messy definitions like the one you see above. Ideally, all changes should be in custom.css.

And it’s not just good code hygiene. It’s a CSS file filled with comments and short memos to my future self, telling me what changes I’ve made and why, with helpful references.

custom.css is so important in micro.blog that it has its own dedicated button, conveniently enough right above the edit themes option, which I end up using to mess with the main.css, which I shouldn’t. Is it obvious? Yes. Do I miss it anyway? Of course.

Auto-generated description: A web interface allows editing of the custom CSS for a Tiny Theme on a blog using Hugo

There are a lot of tweaks to my theme I should move over to custom.css at this point.1

Since I was already looking into it, I realized that the overall colors I’ve overwritten (like the red color I mentioned above) can probably be worked into the helpful root{} section2 I have in there. It was the very first thing I did when I started messing with the theme, and it’s meant just for the sort of changes I usually do around my blog.

So I’m considering refactoring my CSS, which I think is a hobby or self-torture (or both; some of us are weird, OK?) for many bloggers and website owners out there.

What can possibly go wrong?

Footnotes

1 : According to AI, what I’m describing here is called a Technical debt: “While an expedited solution can accelerate development in the short term, the resulting low quality may increase future costs if left unresolved.” My frustrations have a Wikipedia entry! Thanks, AI.

2 : Turns out these are called custom properties (I know, crazy right?)