Chris Burnell

Fresh pixels

2026-05-09T09:49:02-03:00

Status updates and enforcing the crispiest-possible 88x31 badges across the web

Yesterday afternoon, I spent some time creating a new 88x31 badge for my website footer.

In case you missed my last post, I’m in the midst of migrating servers, and one of the things I migrated was my status page, which pings each of my websites once per minute and reports whether the request was successful, and if so, how long the request took. Each website is represented on the front end by a graph of response times across the last hour as well as 60 red or green-coloured bloops, which represent the successes of the last hour’s pings.

So the idea was to create a dynamic 88x31 badge that relayed information from my status page by displaying some number of the most recent bloops.

I set out achieving this by first creating the 88x31 image with some blank areas that I could fill in later with green or red, depending on the status of each bloop, and the next step was to create a short PHP script to consume this image, fill in the colours of the bloops, and spit out the result.

Fortunately, generating images with PHP is one of the first things I ever learned how to do outside of HTML and CSS early on in my web development journey, nearly 20 years ago, so this was a familiar task!

And the result (blown up for clarity):

Backend code, if you’re interested

Here’s what the JSON file of minute-by-minute data looks like:

[
	{
		"timestamp": 1778260261,
		"time": 0.406,
		"response": 200,
		"http_version": "2"
	},
	{
		"timestamp": 1778260321,
		"time": 0.446,
		"response": 200,
		"http_version": "2"
	},
	{
		"timestamp": 1778260381,
		"time": 0.807,
		"response": 200,
		"http_version": "2"
	}
]

And here’s the gist of the PHP that generates the dynamic image:

<?php
$image = imagecreatefromgif("uptime.gif");

$green = imagecolorallocate($image, 102, 204, 51);

$red   = imagecolorallocate($image, 153, 0, 51);

$cacheFile  = "cache.json";

$uptimeFile = "uptime.json";

$numBloops = 9;
if (!file_exists($cacheFile) || filemtime($cacheFile) < time() - 60) {

$uptimeData = json_decode(file_get_contents($uptimeFile), true);

usort($uptimeData, fn($a, $b) => $b["timestamp"] - $a["timestamp"]);

$recent = array_slice($uptimeData, 0, $numBloops);

$cache = [

"timestamp" => $recent[0]["timestamp"],

"bloops" => array_map(

fn($item) => $item["time"] > 0 && $item["response"] >= 200 && $item["response"] <= 299,

$recent

),

];

file_put_contents($cacheFile, json_encode($cache));

} else {

$cache = json_decode(file_get_contents($cacheFile), true);

}
$bloops = array_reverse($cache["bloops"]);
foreach ($bloops as $i => $ok) {

$color = $ok ? $green : $red;

imagefilledrectangle($image, 1, 2, 3, 4, $color);

}
header("Content-type: image/gif");

header("Cache-Control: public, max-age=60");
imagegif($image);

And while we’re at it, here’s how I’m serving my PHP file as if it’s a GIF in nginx:

location = /images/uptime.gif {
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME /absolute/path/to/uptime.php;
    fastcgi_pass unix:/run/php/php8.4-fpm.sock;
}

In building this new 88x31, I was struck with another idea.

Because I so fiercely believe that (most) 88x31 badges look best on the web when they have image-rendering: pixelated; applied to them, why not enforce my belief across (almost) the entire web?

Using CSS

I use the Stylus extension in my browser (get it here) to apply my own CSS to websites and pages. My custom styles are mostly to fix bugs, improve shaky layouts, or to add little quality-of-life stuff, and this seems like an ideal place for me to throw a small chunk of CSS and have my browser apply it across every page that I visit.

The CSS I came up with is pretty minimal, and although it relies on the width and height attributes being present, many websites that I visit that do have 88x31 badges at least have the attributes present, if not the desired CSS property applied as well:

:where(img[width="88"][height="31"]) {
	image-rendering: pixelated;
}

Here’s how it looks in Stylus. Note that I’m applying this CSS to Everything, which means every webpage that you visit:

Using JavaScript

Alternatively, if you want to achieve this for all 88x31 images, whether they have the correct attributes or not, there’s the Tampermonkey extension (get it here) that works much like Stylus but with JavaScript instead of CSS. Here’s my script that checks the width and height of images whether their attributes are set or not and appropriately applies the pixelated effect to 88x31 images:

// ==UserScript==
// @name         Pixelate 88x31s
// @match        *://*/*
// @run-at       document-idle
// ==/UserScript==
[...document.querySelectorAll("img")].forEach((img) => {

const pixelate = () => {

if (img.naturalWidth === 88 && img.naturalHeight === 31) {

img.style.imageRendering = "pixelated";

}

};

img.complete ? pixelate() : img.addEventListener("load", pixelate);

});

Now properly-attributed 88x31 images will always appear nice and sharp, everywhere on the web, including but not limited to the ones in the footer of my website (though they already have the correct image-rendering)!

Thanks for subscribing and reading this post via RSS!

You can read this post and others on my website.

New Year, New Server 2: Electric Boogaloo

2026-05-06T18:52:16-03:00

I got to really put my recently-practised and newly-learned system administrator skills to the test again, mere months after my my last update about migrating the server that hosts my websites. Why’s that, you ask? Because the server host that I switched to has been a major disappointment.

To cut a long story short—although, I never seem to be able to tell short stories—the server host that I switched to at the end of last year employs deceptive pricing tactics.

Advertise price A, but deliver price A × 1.5 after 3 months type of stuff.

And if that wasn’t bad enough, I’ve also been having horrendous issues with establishing and maintaining connections to the server. I have lost track of how many times this website’s scheduled and new commit CI workflows failed to sync newly-built files to my server, seemingly at random times and intervals. Checking the logs would reveal that CI (from multiple sources) wouldn’t even be reaching my server.

Just accept the connection, damn it!

Enough was enough.

I got a new server. It’s actually got even better specs for the same price as I was paying, and it’s hosted in Finland instead of the US too! I went scouring through the terminal history on my scorned server and checked through all the places that I was ~~working~~ playing in and have migrated about 95% of everything! Only a few services and bits and bobs remain to be sifted through.

It was also a fun learning experience, as I decided to use Docker this time around to segment the different pieces of software I use to power my self-hosted stuff. I had everything running on bare metal before and felt like I had a decent grasp of how (at least) my setup worked, but jumped at the opportunity to clean things up and learn something new.

Because I spent so much time learning what I was actually doing last migration, this one went really smoothly. Things were in places that I expected them to be, I had put effort into organising things, and I was able to reach real deep and pull out memories of the migration from four months ago. I’m pretty confident I’ll be able to pull everything that would be missed from my scorned server before it’s decommissioned at the end of this month.

Cue a post from me in June lamenting tremendous data loss…

It was great to watch the sparklines on my uptime tracker shoot downward as I migrated my different websites. Across the board I saw response times to uptime pings decrease by ~10×! So far so good!

Thanks for subscribing and reading this post via RSS!

You can read this post and others on my website.

Unusual Rotations (March 2026): Baroque

2026-03-01T22:23:11+00:00

Reflecting on February and looking ahead to March’s genre(s), Baroque.

February: Vaporwave (in review)

Unfortunately, February was a difficult month, as my family and I went through the loss of a family member. As a result, I wasn’t in a particularly adventurous mindset, and I fell back on familiar and comforting music rather than explore and learn more about music.

In a way, it’s probably a good thing that I picked Vaporwave for this month because I already listen to the genre regularly, so I don’t have an overwhelming sense of having failed this little challenge already at the second month of twelve.

I will probably end up taking a few hours during March to go back and find new stuff to listen to throughout the year and educate myself further on the (frankly) complex history of this scene and its lineage.

All that being said, Bandcamp Friday took place on the 6^th of this month, so I took advantage of the event to purchase a number of fun Vaporwave albums. I haven’t had the opportunity to properly go through them all (yet), but the album ENCARDIA '99 by slowerpace 音楽 was a stand-out for me not just because it so strongly epitomises the Vaporwave sound, but also because it sounds as if someone translated the Encarta 99 Encyclopedia directly into Vaporwave music, with amazing track titles like LEARNING TIME and FORCES OF NATURE.

Vaporwave, a short history

… at least, as told by me. I might get some stuff wrong, but I have no interest in having debates about it—feel free to send me corrections, if you want. I might read 'em.

As far as I understand, like most genres of music, the origin is both difficult and contentious to pinpoint. By and large, music changes through evolution, and to gaze at the timeframe of a given genre birth would show a blurry, watercolour gradient of hues and tones. Sometimes you can maybe discern a shape in the wash of colours (these are the artists/albums/tracks that really pushed the needle), but more often than not, there is no pinpoint that definitively marks the start of a new genre of music.

When it comes to Vaporwave, there is a strong case to be made that its origins are too murky to call a start time on, but there’s an equally strong case to be made for pinpointing the start of Vaporwave as we know it:

In the late 2000s, as the Internet matured (the Internet itself, not its denizens lol) towards a new decade, there were a few genres like chillwave and h-pop that were already using retro sounds, lo-fi aesthetics, and playing on nostalgia and a wistfulness for a half-remembered past.

It was out of this primordial soup that Vaporwave grew. One of the key moments in this early time was in October of 2011 when James Ferraro released his album, Far Side Virtual. In it, James Ferraro masterfully blends ringtones, elevator music, and the sound of corporate technology and techno-optimism from the 80s, 90s, and early 2000s to evoke an uncanny dreamscape of consumerism and overwhelming nostalgia (as a kid of the 90s, at least).

Unbeknownst to the world, as the genre bubbled slowly to life in underground, indie circles, the artists that were pushing the envelope in this scene were creating a supersaturated solution. All the elements were there, in suspension, just waiting for the right conditions.

On the 9^th of December, 2011, Vektroid (as Macintosh Plus) released Floral Shoppe, crystallising Vaporwave in these underground circles, and, in a way, helped to define the je ne sais quoi that makes up what Vaporwave is: 80s/90s Japanese city pop, corporate muzak, lo-fi and chopped and screwed samples, and subtly-critical or ironic sounds of late stage capitalism.

This is what gives Vaporwave its interesting but slightly-eerie quality: a world that was sold to us, but refracted through the uncynical, wide-eyed wonder of childhood, before we knew enough to be critical, when everything just seemed so shiny and glossy and exciting and new.

Of course, nothing happens in a vacuum, and the Internet at large quickly caught onto this new but nostalgic genre of music. Maybe the conditions were just right, because it exploded in popularity throughout 2012, and I think this probably has a lot to do with how memeable the Vaporwave aesthetic was and that the nostalgia factor of Vaporwave is targeted at the demographic of people who are more likely to make memes about things in the first place.

From there, genres and sub-genres and sub-sub-genres (that some would argue are genres unto themselves, thank you very much) would grow and blossom through their own scenes and wider circles that were developing.

There are far too many genres that were born from this time and from very similar origins for me to even name, and it’s been interesting to see and hear how Vaporwave has evolved and splintered in the ~14 years since Far Side Virtual and Floral Shoppe came out.

March: Baroque

I spent a lot of my youth learning piano, mostly baroque and classical pieces, and have been trying to pick it back up as an adult. My parents are both big fans of these genres, and I’ve been very familiar throughout my life (as a result), so this month, again, will probably be more about the depth of my exploration rather than breadth.

I’d really love to get a stronger understanding of what defines these genres (usually lumped together under the umbrella of classical music), what kind of influence history had on this music, and deep dive on some of my favourite aritsts/composers of these periods.

I’m definitely going to be listening to and playing a lot of Beethoven this month!

As always, if you have any ideas, thoughts, recommendations for this month or future ones, hit me up!

It's all right here in my noodle. The rest is just scribbling. Scribbling and bibbling, bibbling and scribbling.
Mozart (from the movie, Amadeus)

This post is part of Unusual Rotations 2026, a year-long project to immerse myself in 12 different musical genres that aren’t in my usual rotation over the course of a year, one genre of focus per month, in an effort to expand the horizons of my musical tastes, learn more about how genres have evolved and grown over time, and expose myself to a rich history of music that I might have otherwise overlooked!

More to come…

Thanks for subscribing and reading this post via RSS!

You can read this post and others on my website.

Unusual Rotations (February 2026): Vaporwave

2026-02-01T21:50:47-04:00

Reflecting on listening to Grunge throughout January and planning February’s genre, Vaporwave.

January: Grunge

On the whole, I really enjoyed exploring grunge more this month! There were some classic, quintessential tracks in there that I was already pretty intimately aware of, but it was nostalgic and it always rules to listen to great music you haven’t heard before.

Although I did listen to a smattering of big music’s Grunge playlists (e.g. The Grunge Era on YouTube Music) and sampled through some top 50 albums of all time lists (e.g. 50 Greatest Grunge Albums by Rolling Stone), I think I let my own personal taste really take the reins this month. Because I ended up really enjoying so much of it, it was hard to stop listening to artists and albums once I put them on! Even though I don’t think it was necessarily a mistake, I’m going to try to cast a wider net going forward and absorb more music, rather than latch onto the first things that prick up my ears.

I want to guess that I listened to at least 100 hours of Grunge across January, and I captured 10 albums on my Music Reviews page that really stood out to me. I don’t know whether it’s a testament to just how good these bands are at grunge, or just the pervasive nature of popularity, but most of them are the well-known heavy-hitters of the grunge world.

In no particular order, here are a few of my favourites from this month:

Jar of Flies

Alice in Chains (1994)

4.25/5

In Utero

Nirvana (1993)

4.25/5

Superunknown

Soundgarden (1994)

4/5

I also received some much-appreciated recommendations from a handful of lovely folks: James Elliker recommended a whole personalised list of top 50 albums which was incredibly fruitful; Nathan Knowler recommended Superheaven’s album from last year which helped me settle into the driver’s seat of a nomad in the grunge world; and Jeremy Keith recommended I check out Babes in Toyland (two very sick music videos). Thanks all!

I suspect I’m going to be juggling grunge through February as well, so don’t be surprised if a few albums slip onto my Music Reviews page over the next… well, probably over the course of this year!

I’m going to take a quick moment to pay myself on the back for taking on this idea or project or whatever you want to call it. It has been really fun and I encourage you to join! Reject the Gregorians and start your own exploration into new and semi-familiar genres whenever you want!

On with February!

Vaporwave

To say that I’m new to this genre would be… a complete and utter lie! I got really into it probably around a decade ago, and I’ve been listening to it pretty steadily ever since.

With that being said, my exploration of the genre has been pretty limited. As with my month focusing on grunge, I’ve tended to be drawn to depth rather than breadth. I’m hoping by cheating with a rather familiar genre this early on will help me get into exploring more. Pausing along the way is fine—pun ~not~ intended—but covering as much ground as I can over the course of this short month is my goal!

I imagine I’ll be fleshing out my Music Review section with some old favourites that I never added for whatever reason, but I’m hoping to find myself immersed in that wonderful, euphoric feeling of discovering something new that electrifies you once again.

’Til March!

More to come…

Thanks for subscribing and reading this post via RSS!

You can read this post and others on my website.

RSVP to State of the Browser 2026

2026-01-28T16:17:20-04:00

Only one month until State of the Browser, and I will once again be organising, but this year I’ll be there in-person! 🥳

Sadly, I’ve had to do what I can rather remotely since 2023, so I’m really looking forward to some amazing talks, meeting old pals, and making new ones too.

Less than 15 in-person tickets left, so I hope to see you there! (I’ll just take credit for any tickets claimed in the next hour or so 😘)

Get yourself a ticket!
2026.stateofthebrowser.com

Thanks for subscribing and reading this post via RSS!

You can read this post and others on my website.

EchoFeed Buttons

2026-01-17T17:28:48-04:00

EchoFeed is an incredible web service by my pal, Robb Knight, that periodically checks your RSS feeds and can echo them out to various social media websites, and can even send Webmentions on your behalf!

I proudly use EchoFeed on my website. I think the Pro subscription ($25 a year) is super worth the cost, and in a time where it feels like we’re constantly drowning in low-effort, let us monetise you slop, it is abundantly evident that EchoFeed has been built with attention and care by someone who cares deeply for the web and its denizens, and that’s worth supporting in my book.

If the insane quality of Robb’s work doesn’t do enough to prove to you just how much faith the web community can put in his capable hands… heck, just try talkin’ to the guy. Leave some kindness for the rest of us, dude.

All this is to say that I did a little riffing on the illustrious Andy Carolan’s work in creating EchoFeed’s Powered by EchoFeed SVG buttons and remade them in the style of my other pixel-art 88x31 buttons (shown at 4× size so you can see more detail):

I’ve since relinquished any and all ownership I have over the buttons I created, and you can grab ’em on the Buttons page from the EchoFeed Help Pages.

Thanks for subscribing and reading this post via RSS!

You can read this post and others on my website.

Unusual Rotations (January 2026): Grunge

2026-01-06T19:57:37-04:00

I've come up with a fun, new project to work on over the course of this year, and maybe you’ll join me!

Towards the end of 2025, I came up with this idea to expand the horizons of my musical tastes.

I’ve always had quite a broad taste in music, I think. When I was growing up, I would tell people, I listen to everything except jazz and country. I didn’t really know what I was talking about, and definitely listen to all sorts of jazz and country music these days, so is it fair to say that I listen to everything?

Maybe! But I’m going to try and find out.

Over the course of 2026, I’m going to be dedicate each month to a genre of music that’s either way outside the realm of what I normally listen to or is a genre that I’ve been tiptoeing around and deserves more attention.

I’ll be documenting the journey here, on my website, as something that I can reflect back on and might inspire someone else to try something new too!

At the start of each new month, I’ll reflect on the previous month, maybe highlight some stand-out artists/albums/songs, touch on some historical stuff that intrigued me, and whatever else I take away from my exploration into that genre.

This whole project is really a venture into the unknown. To be frank, I haven’t even thought much about how I want to structure my research and listening, let alone if this project is a reasonable thing to consider doing in the first place. How much can I really learn about something as deep and as rich as an entire genre of music in just a month?

The reality is: I can’t. But I don’t expect to, either. Reaching some ethereal finish line is not the point. On the contrary, the journey is the whole point! Imagine the sadness that would come with knowing you had already heard everything. To know that the feelings of sating one’s curiosity is behind me and that no surprises await would be a terrible condemnation to endure.

I’m more concerned with having enough time each month to juggle spending time towards the genre of the month and continuing to listen to the previous genres I’ve explored that I’ll inevitably become obsessed with!

I know way too many cool people with vast, sprawling, wildly different tastes in music, so I’m really looking forward to ~~hassling~~ hearing from folks about their favourite genres. Educate me! What are your favourite artists/albums/songs? I’ll check them out! Shoot me a message with a totally un-asked for braindump of the lore of your favourite genre! Cause I’m askin’, and I’ll read every single word of it. What are the genre’s big hits? Hidden gems? Do you make this kind of music? I WILL LISTEN TO IT.

And please, by all means, join me! Make your own list of 12 genres that you want to dive into or maybe the ones I’ll pick interest you already. But make sure you let me know! I’d love to go on this journey with you.

So, without further ado, my genre for January 2026 is…

Grunge

Growing up in the 90s and 2000s, I’m a bit too young to have really caught the peak of the grunge wave (I think?). Regardless, my friend group in school was sort of tangentially into grunge, so this genre isn’t a particularly new sound for me.

However, when I moved to Singapore in 2023, I had the opportunity to spend a lot more (in-person) time with my good friend, Raga, who’s a metalhead and huge fan of grunge. He (re-)opened my eyes to a lot of grunge that I hadn’t deliberately listened to in at least 15 years! Thinking about it now, I don’t really know why I let it fade out of rotation. I’ve been giving hip hop and drum and bass too much space! They’re getting set on the backburner for, at least, January, so I can concentrate on immersing myself in grunge!

Again, please do reach out if you join me on this journey and/or if you’re a fan of grunge yourself. Send me your recs!

Apologies to the neighbors.

More to come…

Thanks for subscribing and reading this post via RSS!

You can read this post and others on my website.

New Year, New Server

2026-01-06T15:37:40-04:00

Over the last two weeks, I’ve been toiling away on the ugly underside of this website: the server. It powers and hosts all the data for this and my many other websites, and I thought as we say goodbye to 2025 and welcome in 2026, I’d reminisce on the history of my website.

In the beginning…

When I first started publishing on my own domain on the web (under my own name, at least, I’ve been webmastering since 2005), I really wanted a WordPress blog, which I thought was the coolest thing you could possibly own in 2008. (Things have changed, to say the least!) Somehow, I managed to get one running on a shared hosting provider, and suddenly it felt like a part of me was on the Internet now, or at least some kind of extension of myself.

That shared hosting dashboard (cPanel) kept my handful of websites going from 2008 until 2014, a solid 6 years of service, but it didn’t come without friction.

Unfortunately, the style of the dashboard that is/was common with these types of sharing hosting services feels like it was constructed to be some impossibly-capable tool-belt that extends ad infinitum, but is thrust around you in the vain hope that the little One size fits all label will answer your many questions and provide some level of comfort amidst your utter confusion and horror.

I’m sure this is exactly what other folks expect and want of their web hosting dashboard, but this isn’t something that I can effectively learn how to use. I just end up feeling like my grasp is slipping on the surface of a very large, very well-maintained planet. No shade if this stuff is your jam!

Somehow (this isn’t the last time I’ll use that word), I managed to work through this inadequate/over-adequate tooling for years and years, but my skills as a developer eventually caught up with my needs of control over the backend of my websites. I remember starting to really detest having to wade through all the pre-installed junk in my shared hosting dashboard, but not being nearly interested enough in the dashboard itself to do more than some basic modifications to the UI.

Taking the reins

By 2014, my role at work and my personal projects had already begun demanding some actual know-how with the command line, and as my familiarity with Node.js and bash grew, it became obvious that I wasn’t destined to chain myself to my shared hosting dashboard forever.

So I decided do something about it.

As someone who ~~spent~~ still spends tonnes of my personal time in this space, I have come to realise that the moments where I really enjoy developing and learning are when the virtual space I’m in feels comfy and familiar. Flow state and all that jazz.

To me, this is like the difference between following maps and following landmarks and paths your feet have tread a hundred times before. Both methods get you to the same place, but I want my steps to be my own, not the steps that have been determined for me by someone or something else.

This probably comes from a ~decade of obsessing over the minute details of my website to the point of exhaustion, moving on to modifying and customising my Android phone to a ridiculous degree until it feels just right, and looking for something else to dive into and learn about and absorb myself in and transform it into something that feels homey and familiar only to find my itch unscratched.

So it’s been nearly twelve years (4,348 days, to be exact) since I first installed the VPS that succeeded the shared hosting that was the home for chrisburnell.com et al. for so many years.

This came with a steep learning curve, but each step forward brought with it deep lungfuls of fresh air. I got to learn first-hand where the gaps in my knowledge and skills were from years of depending on janky web UIs to manage databases and oversee processes.

I’m super fortunate and grateful to be friends with great people like Hank Woods and Callum Loh who guided and taught me boatloads throughout many of those early, hands-on hours with my new server.

That’s not to say that I didn’t go off and make a shambles of everything when I wasn’t supervised: configuration files in the tmp directory, SSHing directly in as root with a far-too-trivial password, binaries where configuration is supposed to go… Name a mistake and I probably made it.

But, somehow (again?), I MacGyvered together a mountain out of a molehill, and was finally at a level of control over my website (front and back) that felt like I could work with. There were times it outpaced me or felt like I couldn’t get it to do what I wanted, but without that veil between me and the systems I was trying to interact with, I was able to explore and learn so much, achieve new things that weren’t possible for me before (let alone conceive of), and again, make the environment that I was spending so much time in feel like a home.

Clueless

Over some quiet evenings this last December, a old, familiar feeling started to creep back into my mind:

Sure, I’m not making the total newbie mistakes anymore, or at least not that often. I can edit and find the stuff that makes my server run. I can handle nginx configuration, I have enough of a handle on firewall rules and reverse proxies exposing services to the web, but if anything goes wrong…

Yeah, I ended up creating a grotesque sibling for the shared hosting dashboard that I hated so much, but this behemoth was of my own making… *facepalm*

The difference with this behemoth was that when things went wrong, there wasn’t a customer support chat for me to jump into and get things resolved for me. The responsibility was mine and mine alone, and I certainly threw down the gauntlet at my own feet.

I must have been feeling especially self-sabotaging when I decided I wanted to add hosting my own Mastodon instance to my skillset in 2022. It’s a real testament to their documentation that I was able to get things running, but I figured it out and have kept it ticking along ever since, but this is where my old VPS’s age really began to show.

After over a decade of mucking around and leaving grease stains on all the server’s good furniture, the toll on the server was showing. Running 3+ database management systems, pumping the traffic of 5+ domains and dozens of subdomain projects through shoddily-configured web servers, and an interesting mishmash of who-knows how many iterations of different projects in different languages written at very different stages of my career was enough, but supporting a Mastodon instance on top of that meant that the server’s memory was running like a lump of molten lava pretty much nonstop.

Not good.

It’s alive!

So I began researching. Maybe I could just upgrade the server’s capabilities and things would be fine?

But I couldn’t shake that feeling of how great it would feel to start fresh and take the time to actually learn what I’m doing to get things right from the start. At the very least, even if I got things wrong, my attitude this time would be to understand and learn, so I figured I would be capable of understanding why it was wrong.

Rather than chasing search queries about my issue for hours, looking for the silver bullet to copy and paste that will just fix things, my plan was to actually read logs and man pages. After all, associating patterns of strings in bash scripts and postgres commands with certain actions is only really one step removed from associating the phpMyAdmin logo with the way that I used to interact with databases.

(Again, to each their own! I’d rather have you on the web with me than not, and I don’t hold any judgement towards how you get comfy and comfortable in your web space. This article’s about me, though!)

And that solidified it for me. This was happening.

I began shopping around and discovered I could get a server for a comparable, competitive price that had twice the CPUs, memory, storage, and transfer capabilities of my old server. Lock it in.

So that’s what I’ve been up to for the last ~2 weeks: slowly trickling stuff across from my old VPS to the new. I started with the straightforward static sites and then moved onto the more complex ones, taking things really slowly to make sure I understood every line of config I authored and looking for ways to DRY things out just enough to build a sweet library of my own reusable stuff while not making it impossible to revisit this stuff in a year’s time and have to re-learn how hundreds of moving pieces fit together. A careful and measured approach.

And I’m very pleased to say that my old server is just about ready to be decommissioned! Everything important (read: that I can remember exists) has been ported over and the new server looks to be in great health after a week of stability.

I still need to go through things on the old server with a fine-toothed comb once more. There’s so many old and unimportant one-off experiments that I’d like to keep just for the heck of it, but there’s also a lot of files that I can only assume were accidentally saved in the wrong location or moved haphazardly or for some other indecipherable reason. It’s funny, though, to think how much I probably confused myself in 2014!

I was wandering around so naïvely back then, but it’s a fun and nostalgic experience to retrace the first steps I took on fresh earth twelve years ago; to see where my feet took me, what piqued my interest, what parts of the landscape I strayed from out of fear, what parts I let nature take its course out of deference, where I built lookouts and small homes to rest and read in.

One day soon will be the last day I set foot in that space that I know so well, but I haven’t left the experience empty-handed.

Now, I have a map. A map that has all my secret little paths, notes, warnings about here be dragons, all the stuff, all the character that isn’t on the pages of the maps you can get off a shelf. It’s not a perfect map by any means—the corners are dog-earred; words, written in pen, have been scratched out; and, later on, eraser marks betray hidden mistakes in charcoal—this map is far from finished.

But this map that I made is my own.

Thanks for subscribing and reading this post via RSS!

You can read this post and others on my website.

Color Scheming

2025-10-24T12:01:00-03:00

It’s been about a year and a half since I changed how colour schemes (i.e., light and dark themes) work on my website, and after reviewing and refactoring things again recently, I thought I would share how everything ties together and allows for different levels of control over colour schemes.

In this article, I’ll cover how to implement a colour-scheming system, gain some understanding of how to control the colour scheme in different ways, and write some CSS that leverages the strengths of the language to build a hierarchy of colour scheme controls.

Note: We’re going to build this hierarchy of controls out of order, but we’ll wrap everything back around to honour its order by the end.

Element-level Override
Page-level Override
Site-level Preference
OS/Browser-level Preference

Let’s build

4. OS/Browser-level Preference

To begin with, we should make sure to include this meta tag in the head of our page(s). This indicates a suggested [colour] scheme that user agents should use for a page (MDN).

<meta name="color-scheme" content="light dark">

Next, we need to indicate in our CSS what colour schemes we want to have available, and we can apply this to the document root (<html> in most cases) and the cascade will apply the appropriate colour scheme to the entire document:

:root {
	color-scheme: light dark;
}

This, alone, allows us to write CSS that responds dynamically to the OS/Browser-level Preference for a light or dark colour scheme. Where colours are concerned in our CSS, we can use the light-dark() function to hook into which of the two colour schemes is active and provide an appropriate colour for both conditions.

Also, because we’ve written light dark, we have indicated that where an OS/Browser-level Preference does not exist, we should default to the first value. This means that in the absense of all preferences and overrides, the default colour scheme will be the light one. If we had instead written dark light, the dark colour scheme would be the default.

1 & 2. Element-level & Page-level Overrides

Next, let’s take care of Page-level and Element-level colour scheme overrides. The way I’ve chosen to do this is by creating classes for each colour scheme that can be appled to any element and use a specific colour scheme for itself and its children:

.light {
	color-scheme: light;
}
.dark {
	color-scheme: dark;
}

We can apply these classes to the html element to force an entire page to use a specific colour scheme:

<html class="dark">

Similarly, we might want a particular section of a page to always use a specific colour scheme, so we can apply the class to a wrapper element and allow the color-scheme value to cascade to its children:

<main class="light">
	...
</main>

3. Site-level Preference

The last part is unfortunately the most complex, so let’s dive in and flesh out how we can allow website visitors to override their OS/Browser-level Preference without stepping on top of our Page-level/Element-level Overrides.

To start with, I’m using David Darnes’ web component, <storage-form>, to capture the Site-level Preference. This works by wrapping a <form> that contains a <select>. The <storage-form> web component listens for selection changes on the <select> value and saves those changes to local storage.

<storage-form>
	<form autocomplete="off">
		<select name="color-scheme">
			<optgroup label="Select a colour scheme">
				<option value="" selected>OS Default</option>
				<option value="light">Light</option>
				<option value="dark">Dark</option>
			</optgroup>
		</select>
	</form>
</storage-form>

From then on, whenever the web component’s JavaScript finds the same <select> (matched by name attribute) on subsequent page loads or on other pages, it will modify the selected <option> in the DOM to match the local storage value.

This takes care of persistence of Site-level Preferences. I cannot overstate how amazingly powerful this little web component is! I use it every time I need to manage some sort of state on my website.

What’s great about this approach is that we can leave <storage-form> alone from here and continue using CSS to control and manage how we respond to different colour schemes. We can build selectors that match when a particular <option> is selected (i.e., checked), and using the :has() selector, we can then apply a specific colour scheme based on that selection:

:root:has([name="color-scheme"] [value="light"]:checked) {
	color-scheme: light;
}
:root:has([name="color-scheme"] [value="dark"]:checked) {
	color-scheme: dark;
}

So when the light option has been selected, we are applying the light colour scheme to the document root, and vice versa for the dark option.

A nod to performance

Before we can put everything together, there are some problems we need to address.

Firstly, we need to think about how we initiate the JavaScript that defines the <storage-form> web component because until it is loaded, the Site-level Preference that exists in local storage won’t have been mirrored onto the <select> on the page. At present, we’re relying on the value of the <select> to apply a Site-level Preference.

This gives us some options and a choice to make.

We could instantiate the web component in the head of our page(s) and be sure that by the time the HTML parser reaches our <storage-form> and <select>, the browser will know what to do with it, and the correct colour scheme will be applied; however, this will block the parsing of HTML while the entirety of the web component’s JavaScript is being processed.

We might think to defer the script or run it asynchronously, but no matter how we slice it—loading the JavaScript before the HTML or vice versa—we’re going to run into an unsightly problem. The effect will be more pronounced on slower devices and/or slower connections, but there will be a period of time where some portion of HTML has been parsed and rendered before the locally-stored colour scheme value has been applied to the HTML. Depending on how different in brightness the light and dark colour schemes are, this can result in an intense shift from light to dark or dark to light before and after the locally-stored colour scheme value is applied.

What I’ve done to solve this is to defer the loading of the JavaScript that initiates the web component and instead include a small snippet of (minified) JavaScript in the <head> that is technically parser-blocking, but will reliably run (or fail) very quickly.

const COLOR_SCHEME = localStorage.getItem("color-scheme");
if (COLOR_SCHEME) {
	document.documentElement.setAttribute("data-color-scheme", COLOR_SCHEME);
}
window.addEventListener("load", () => {

document.documentElement.removeAttribute("data-color-scheme");

});

What this does is independently check the browser’s local storage for the same value that gets set by the <select> in the <storage-form> web component. If a value is found, then it sets a data attribute on the document root. When the window has finished loading, this means that the <storage-form> JavaScript has completed, so the data attribute on the document root gets removed, allowing the CSS selector based on the <select> value (which is now in parity with local storage) to once again take control.

We can apply some further CSS that will apply the correct colour scheme during this in-between state when the data attribute is present on the document root:

[data-color-scheme="light"] {
	color-scheme: light;
}
[data-color-scheme="dark"] {
	color-scheme: dark;
}

Review and Refactor

Let’s put all of our CSS together. We’ll combine our initial :root declaration alongside two other declarations, one for each of two groups, selectors that should apply the light colour scheme and selectors that should apply the dark colour scheme.

Warning! The CSS below is not the full solution! Keep reading below to learn about what we need to do to fix its problems.

:root {
	color-scheme: light dark;
}
:root:has([name="color-scheme"] [value="light"]:checked),

[data-color-scheme="light"],

.light {

color-scheme: light;

}

:root:has([name="color-scheme"] [value="dark"]:checked),

[data-color-scheme="dark"],

.dark {

color-scheme: dark;

}

Unfortunately, while this CSS does target the different parts of the DOM that we need, there are a few last considerations to make before this will preserve the order of preferences and overrides that we want. We’re going to use two important features of CSS to help us tailor things to do that.

First of all, we can amend our first declaration with the :where() selector. This selector nullifies the specifity of all selectors inside it, so when our :root selector becomes :where(:root), it has a specificity of (0,0,0). This makes it very easy to out-specify later on.

-:root {
+:where(:root) {
	color-scheme: light dark;
}

Next, we’ll consider the three methods of control (<select> value, data attribute, class) and which should be more specific.

The <select> value selector and data attribute selector can be treated as one—that is to say that their specificity in this hierarchy should be identical, as they both actually represent the same thing, the value of the <select>.

Based on the hierarchy that we want, the specificity of the class-based controls should be higher than the <select> value and data attribute controls.

Let’s consider the specificity of the three selectors in each group:

`:root:has([name=color-scheme] [value=light]:checked)`	(0,4,0)
`[data-color-scheme=light]`	(0,1,0)
`.light`	(0,1,0)

Given that their specificities don’t align with what we want, we can leverage a second important feature of CSS, source order.

Let’s use the :where() selector again to nullify the specificity of the <select> value selector and data attribute selector:

-:root:has([name="color-scheme"] [value="light"]:checked),
-[data-color-scheme="light"],
+:where(:root:has([name="color-scheme"] [value="light"]:checked)),
+:where([data-color-scheme="light"]),
.light {
	color-scheme: light;
}
-:root:has([name="color-scheme"] [value="dark"]:checked),
-[data-color-scheme="dark"],
+:where(:root:has([name="color-scheme"] [value="dark"]:checked)),
+:where([data-color-scheme="dark"]),
.dark {
	color-scheme: dark;
}

But why do this? Won’t they have the same specificity as the :where(:root) declaration?

They do have the same specificity (0,0,0), but, critically, they come after the :where(:root) declaration in source order. This means that our new <select> value and data attribute selectors take precedence over :where(:root).

I’ve inlined the specificity of each selector to demonstrate this below:

/**
 * (0,0,0) — 1st in source order
 */
:where(:root) {
	color-scheme: light dark;
}
/**

Order of selector specificities below:
(0,0,0) – 2nd in source order
(0,0,0) – 2nd in source order
(0,1,0)

*/

:where(:root:has([name="color-scheme"] [value="light"]:checked)),

:where([data-color-scheme="light"]),

.light {

color-scheme: light;

}

:where(:root:has([name="color-scheme"] [value="dark"]:checked)),

:where([data-color-scheme="dark"]),

.dark {

color-scheme: dark;

}

Fin.

At this point, the build is complete! For the most part, the code involved in this solution rarely needs amending or changing, so I tend to put it wherever you might find things like resets in my CSS.

We can make powerful use of the light-dark() function to toggle between colour values depending on the active colour scheme, e.g.:

main {
	background-color: light-dark(#e1e1e1, #1e1e1e);
	color: light-dark(#1e1e1e, #e1e1e1);
}

Furthermore, because we’ve set up a hierarchy for the controls that we’ve made available to us, we’ve instructed our styles to hook into visitors’ OS/Browser-level Preference. If they’d rather not let their OS/Browser dictate their preference, they can use the <select> to choose a Site-level Preference that will persist across tabs, windows, and even sessions, thanks to the power of local storage.

We’ve also thought about user experience and poor-performance situations by introducing a light sprinkling of JavaScript. Despite incurring a small performance impact itself, this gives us the tremendous benefit of applying a chosen colour scheme to the page as early as possible to prevent the wrong colour scheme from being shown before the heftier parts of this solution have had a chance to make their impact.

On top of that, we, as website authors, can override the user’s Site-level Preference to be able to say that certain pages or parts of pages should always be rendered with a specific colour scheme.

Full CSS Solution

:where(:root) {
	color-scheme: light dark;
}
:where(:root:has([name="color-scheme"] [value="light"]:checked)),

:where([data-color-scheme="light"]),

.light {

color-scheme: light;

}

:where(:root:has([name="color-scheme"] [value="dark"]:checked)),

:where([data-color-scheme="dark"]),

.dark {

color-scheme: dark;

}

Bonus!

Although it isn’t stable across browsers yet, the if() selector will allow us to toggle non-colour property values based on the resolved colour scheme. This is great for things like changing a background-image based on the colour scheme. That would look something like this:

background-image: if(color-scheme(light): url("/light.png"); else: url("/dark.png"));

Fin. Part 2: Electric Boogaloo

We can actually take this one step further without much extra CSS, and this gives us the ability to set a Page-level or Element-level colour scheme that is more of a suggestion than a rule, and can be overridden by a Site-level Preference.

This gives us two new ways to apply colour schemes to our pages and an amended hierarchy of how colour schemes can be applied:

Element-level Override
Page-level Override
Site-level Preference
Element-level Suggestion
Page-level Suggestion
OS/Browser-level Preference

:where(:root) {
	color-scheme: light dark;
}
+:where(:root:has([name="color-scheme"] [value=""]:checked):not([data-color-scheme], .light, .dark)) {

+	&:where(.suggested-light),

+	& :where(.suggested-light) {

+		color-scheme: light;

+	}

+	&:where(.suggested-dark),

+	& :where(.suggested-dark) {

+		color-scheme: dark;

+	}

+}



:where(:root:has([name="color-scheme"] [value="light"]:checked)),

:where([data-color-scheme="light"]),

.light {

color-scheme: light;

}

:where(:root:has([name="color-scheme"] [value="dark"]:checked)),

:where([data-color-scheme="dark"]),

.dark {

color-scheme: dark;

}

This introduces a rather unwieldy selector, :where(:root:has([name="color-scheme"] [value=""]:checked):not([data-color-scheme], .light, .dark)), so let’s break down what it does:

:root:has([name="color-scheme"] [value=""]:checked) checks if the <select> on the page has its default value but targets the document root when applying styles. When this is the case, it means that the user has selected neither light nor dark as their Site-level Preference.
:not([data-color-scheme], .light, .dark) ensures that the document root has neither a data-color-scheme attribute nor the classes light or dark applied to it.
:where(...) makes sure that this complex selector has a specificity of (0,0,0). This ensures that it doesn’t compete in specificity with other important parts of this solution, but rather takes a specific place in the source order to help define its place in the hierarchy (see below).

The two extra classes that this introduces, .suggested-light and .suggested-dark, can be applied to our HTML in the same way as our previous classes (.light and .dark), but the important thing to note here again is the source order.

By placing these declarations between the two parts of our previous solution (and matching the specificity of (0,0,0)), they receive higher precendence than the OS/Browser-level Preference but lower precedence than the Site-level Preference.

This can be useful in situations where, for artistic reasons, you'd like a particular page or section to be a specific colour scheme, but if the user has set a Site-level Preference—maybe for reasons relating to eyesight or otherwise—then that choice should be respected and the particular page/section should be rendered as they’ve chosen, not from your suggested colour scheme.

Thanks for subscribing and reading this post via RSS. This post is part of RSS Club, which means it appears only in my RSS feeds for 3 days (until Monday, 27 October 2025), rewarding folks who subscribe to my RSS feeds with knowing about this post early!

You can read this post and others on my website.

“Built with Eleventy” Animated 88x31

2025-06-10T03:47:32+08:00

I was tagged several days ago on Mastodon, as someone was looking for a 90s-style 88x31 footer GIF for pages built with Eleventy, and it has been just over a year now since I first created mine:

Shown at 4× original size so that the detail is a bit easier to see.

I had a lot of fun creating a handful of 88x31 badges, and the post on Mastodon reinvigorated my desire to play with pixels. So this evening, I once again fired up Aseprite and gave animating the badge a shot!

It may not be the most flashy 88x31 badge you’ve ever seen, but I think it’s pretty fun in its simplicity, and it’s only 3.3 kB.

You’ve got my full permission to take these badges and use them on your own “Built with Eleventy” websites or however else you want!

Important to note, if you are displaying these on the web, I highly recommend that you apply the following CSS to the image to ensure it displays nice and crispy:

image-rendering: pixelated;

I also built some longer versions that include call-outs to the 11ty.dev website.

This one’s a bit chunkier, clocking in at 9 kB.

And this one’s a bit bigger than the previous at 9.5 kB.

Thanks for subscribing and reading this post via RSS!

You can read this post and others on my website.