Chris Burnell · CSS

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.

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.

Reply to What's Your Style?

2024-08-16T16:13:34+08:00

If I go back and look at the first version of my website from 2008, it looks like I was a style.css guy.

I resent so much about that decision. 😂

I mean, I guess they are called Cascading Style Sheets, not Cascading Styles Sheets, so maybe there’s an argument to be made there for using style.css, but I won’t be the one defending that position!

Recently, though, I tend not to use either style.css or styles.css.

Ever since the notion of Critical CSS entered the scene, I’ve named things a bit differently. Because the idea here is to split a website’s styles into two sets—one that is required for above the fold content, or many/all pages; and another that is needed to style the rest of the website—I’ve started naming the two stylesheets critical.css and defer.css.

What actually happens on my website these days is that I use the 11ty plugin, eleventy-plugin-bundle, to combine various SCSS partials into two buckets (also named critical and defer), and the plugin generates a chunk of CSS that gets inlined in the <head> and another chunk that gets spat out into a content-hashed file location and gets referenced by a <link> tag.

So, in short, I’ve still got a fondness in my heart for ol’ faithful, /css/styles.css, but what I actually do in practice differs. That being said, I think there’s a future where, like native Web Components for example, CSS comes bundled with the HTML that it’s associated with as a best practice. And with that being a possibility, I think it’s reasonable to assume that I’ll be naming my CSS files styles.css once again!

Thanks for subscribing and reading this post via RSS!

You can read this post and others on my website.

Layout Update

2024-05-29T23:19:17+08:00

A short update on my website’s layout.

Over the last few days, I’ve been working on some minor redesign of my website’s overall layout that I mentioned in yesterday’s post, Indent Outdent.

After some thinking, I’ve decided to do away with the sidebar that’s been part of my website’s layout for many, many years. This puts the content of my page and posts in a much more prominent and distinct location within the viewport at wide enough screen sizes. I was starting to feel like the sidebar was pushing a lot of dense information right up alongside the start of each page, which made things a little cluttered and fought for attention and focus with the content of each page.

That’s not to say that the information in the sidebar is gone, I’ve just done a little refactoring of the grid layout to move that stuff underneath the main content, which fills horizontally across the page (given enough space in the viewport) instead of vertically. I’ve been eagerly reading a lot of articles and thoughts in the front end community regarding masonry layout, and I’m eager to see the technology mature and a solid standard come out of it. It would certainly help tidy up the meta information at the bottom of pages.

There are still some things I’d like to take another look at to see what improvements I can make, but I think it’s in a good enough state now that I’m happy to push it live, and not have to juggle two branches of code anymore.

As a result of the sidebar going away, I also took the opportunity to bump up some of the font sizes across my site to make use of the reclaimed real estate, and I think it makes for an easier reading experience across viewport sizes. Another thing I’ll likely be tinkering with as time goes on. This also means that it will be easier for me to re-explore the idea of having aside text within the content of my pages and posts because I won’t have to contend with convoluted styles to take into account the unknown size of the sidebar when positioning them.

I hope you enjoy it! Let me know if you encounter any issues or if you have any ideas or suggestions. I’m all ears!

This is post #29 of #WeblogPoMo2024 / Weblog Posting Month 2024, a one-month challenge to post as often as possible (daily, ideally) for the duration of May 2024!

Learn more on Anne Sturdivant’s website.

Thanks for subscribing and reading this post via RSS!

You can read this post and others on my website.

Indent Outdent

2024-05-28T18:07:40+08:00

In the last few days, I’ve been working on a small redesign of my website, and thought I’d share a handy little implementation of CSS Grid I’ve been using to lay out the contents of my pages.

What this implementation does is set up a containment context around my main grid. This grid is set up with a series of named rows that I can slot children elements into, but the part that I really like about this grid are the columns, where the grid defines three named columns. Depending on the width / inline-size of the container, the size of these columns changes.

First things first, let’s look at the HTML we’re working with.

<main>
	<div class="grid">
		<h1 class="title">Title</h1>
		<p class="description">Description</p>
		<div class="content">
			<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vestibulum suscipit id nulla vitae maximus. In bibendum risus in commodo fermentum.</p>
		</div>
		<aside class="meta">
			<p>published <time datetime="2024-05-28T18:07:40+08:00">28 May 2024</time></p>
			<p>tagged <a href="/tag/css/">css</a>,  <a href="/tag/css-variables/">css-variables</a>, <a href="/tag/weblogpomo2024/">weblogpomo2024</a></p>
		</aside>
	</div>
</main>

This is the rough HTML for an example blog post, which contains a title, description, content, and meta information about the post.

The first step in building out this implementation is to define a containment context on the <main> element, which wraps the grid.

main {
	container: main / inline-size;
}

Next we’ll set up the grid and its rows and columns.

.grid {
	display: grid;
	align-items: start;
	grid-template-rows:
		[title-start]
		auto
		[title-end description-start]
		auto
		[description-end content-start]
		auto
		[content-end meta-start]
		auto
		[meta-end];
	grid-template-columns:
		[indent-start]
		var(--indent-size, 0)
		[indent-end]
		var(--indent-gap, 0)
		[content-start]
		repeat(6, 1fr)
		[content-end]
		var(--outdent-gap, 0)
		[outdent-start]
		var(--outdent-size, 0)
		[outdent-end];
}

Now we’ve got our grid in place, complete with named rows and columns. In particular, note that the two outer named columns, indent and outdent (as well as the gaps between them), have a size of 0. This is because the four respective CSS Variables (--indent-size, --indent-gap, --outdent-gap, and --outdent-size) have not been defined, so the fallback value of 0 is used instead.

We can now use a container query to assign some values to these CSS Variables when the inline-size of the <main> element is greater than 500px.

@container (inline-size > 500px) {
	.grid {
		--indent-size: 1fr;
		--indent-gap: 1rem;
		--outdent-gap: 1rem;
		--outdent-size: 1fr;
	}
}

The last step is to slot the four content areas into the named rows and columns.

.title,
.description,
.meta {
	grid-column: indent / outdent;
}
.title {

grid-row: title;

}
.description {

grid-row: description;

}
.content {

grid-row: content;

grid-column: content;

}
.meta {

grid-row: meta;

}

Now we’ve got a layout where three of the four grid items span the full width of the grid, and the content spans only the width of the content column.

When the container size is greater than 500px, the indent and outdent columns will have a size of 1fr, so the title, description, and meta information areas will be wider than the content.

At or below 500px, the indent and outdent columns will have a size of 0, so all four grid items will have equal widths.

And that’s all there is to it!

I built a demo on CodePen so you can play with the container to see how the indent and outdent appear at different sizes. Use the handle on the bottom-right of the grid to resize the <main> element to see the indent and outdent appear and disappear.

This is post #28 of #WeblogPoMo2024 / Weblog Posting Month 2024, a one-month challenge to post as often as possible (daily, ideally) for the duration of May 2024!

Learn more on Anne Sturdivant’s website.

Thanks for subscribing and reading this post via RSS!

You can read this post and others on my website.

Interpolating Colours

2024-05-27T21:39:56+08:00

Today I’ll be talking about how we can use some relatively new data types in CSS for finer control over how we use colour spaces in mixing and creating gradients from colours.

Although not completely stable across all modern browsers, there are two data types that we can apply to colour-related CSS functions like color-mix() and linear-gradient() and give us the ability to traverse through different colour spaces in new ways. I’m going to work through these two data types by using them with some linear gradients and seeing how they affect the outcome.

Color Interpolation Method

The first data type I’m going to look at is called the color interpolation method.

What’s interpolation?

Interpolation, in this context, is a method for finding new data points based on a range of discrete data points. When it comes to interpolation in colour gradients, this refers to the method by which new colours are found between some known set of colours.

If we imagine a gradient between the colour red and green, interpolation is how the browser figures out what colours come between the red and green on opposite ends of the gradient.

A few months ago, I published a code snippet, Mixing Colours in Different Colour Spaces, where I showed how different colour interpolation methods will mix two given colours in different ways. The reason why using different colour interpolation methods produce such different results boils down to the shapes of the colour spaces.

When mixing two colours, the browser will do some calculations to determine the nearest possible midpoint between the two, and the shape and journey taken inside that colour space to find that midpoint is what affects the output.

Check out Hueplot by Alexey Ardov for an incredible visualiser of different colour spaces.

The article, High definition CSS color guide, by Adam Argyle is also a fantastic resource for learning more about colour spaces and how the browser draws a path between different types of colour spaces (rectangular and polar) to mix them or create gradients between them.

Similarly to mixing colours with color-mix(), we can use different colour spaces when defining gradients with linear-gradient(). As a rudimentary example, let’s look at how we might define a gradient between the colours red and green:

background-image:
	linear-gradient(
		to bottom,
		red,
		green
	);

Most browsers will use the sRGB gamut by default, which means the in-between points of colour between red and green are derived from traversing the path between red (rgb(255, 0, 0)) and green (rgb(0, 128, 0)) in the rectangular sRGB colour space.

We can instruct the browser to traverse between these two colours in a different colour space by using the in * syntax. For example, to traverse between the equivalent of the same two colours in the HSL colour space, we can add in hsl after the angle of direction in the gradient’s definition:

background-image:
	linear-gradient(
		to bottom in hsl,
		red,
		green
	);

This produces a different gradient because the path between red (hsl(360, 100%, 50%)) and green (hsl(120, 100%, 25%)) passes through different colours in the polar HSL colour space than it does in the sRGB colour space.

What’s also great about this method is that we can define our colours however we choose, and the browser will interpret them in our chosen colour space for us. No conversion needed!

Hue Interpolation Method

The second data type I’ll discuss is called the hue interpolation method. This provides us with a way to specify how the browser should calculate the midpoint between the hues of different colours when in a polar colour space like HSL, LCH, or OKLCH.

I think the power of this data type can be most-easily visualised by taking a look at a colour wheel (this one is using HSL):

Let’s say we wanted to create a gradient that traverses through all the hues of a colour space to produce a full rainbow of colours across the gradient.

Ideally, it would be nice to be able to define a starting colour and have the gradient traverse through all the hues in the colour space and arrive back at the starting point. Something like this:

background-image:
	linear-gradient(
		to bottom in hsl,
		red,
		red
	);

Sadly, this doesn’t work, and what is produced is a solid red colour across the entire gradient. This is because the browser will travel through a colour space by taking the shortest path that it can. In our case, because we’re going from red to red, the shortest path is to not travel at all, which means that the hues in between the start and end of the gradient will not change.

Traditionally, creating a rainbow gradient like the one we want would involve defining a series of colour stops for the browser to interpolate between.

background-image:
	linear-gradient(
		to bottom in hsl,
		red,
		orange,
		yellow,
		green,
		blue,
		indigo,
		violet,
		red,
	);

But this is certainly far from perfect. The problem is that the spread of colours in a colour space is usually not very even, so the visual difference between each of the colour stops can vary quite dramatically.

However, by defining a hue interpolation method alongside a polar colour interpolation method, we can tell the browser to take the longer way around the colour space. This means we can instruct the browser to traverse from red to red again, but instead by taking the longer route around the colour space to get from beginning to end:

background-image:
	linear-gradient(
		to bottom in hsl longer hue,
		red,
		red
	);

This tells the browser to take a path through the HSL colour space that looks something like this:

And the result is our rainbow gradient!

We can also use other colour spaces to get different colours in the gradient, produced by the shapes of those colour spaces instead, e.g. in oklch:

background-image:
	linear-gradient(
		to bottom in oklch longer hue,
		red,
		red
	);

The other values (shorter hue, decreasing hue, and increasing hue) are other ways we can dictate that the browser should traverse through a given colour space. This allows us to do things like change the direction around the colour space that is taken, force the browser to use the shorter route, and so on. Playing with these values can lead to some really interesting mixes and gradients that were previously quite cumbersome to achieve!

Demo

Check out this post on my website to play with the demo.

This is post #27 of #WeblogPoMo2024 / Weblog Posting Month 2024, a one-month challenge to post as often as possible (daily, ideally) for the duration of May 2024!

Learn more on Anne Sturdivant’s website.

Thanks for subscribing and reading this post via RSS!

You can read this post and others on my website.

Website Settings

2024-05-10T11:04:55+08:00

In this post, I’m going to run through how I’m using some exciting new browser features to power the settings/preferences on my website.

While still riding the high of the fantastic 11ty Conference yesterday (which ended at 5 in the morning here in Singapore…), I was inspired to write this post off the back of two talks in particular: Don't Fear the Cascade by Mayank and by Light mode versus Dark mode by Sara Joy.

While there’s certainly a lot to look forward to in the Web Preferences API, it hasn’t yet become a fully-fledged web standard and become available in browsers. Until that time comes, I’m using a combination of relatively-modern but stable browser features to serve up a series of settings/preferences that website visitors can use to control and modify their browsing experience.

Popovers

Historically, attaching functionality to buttons has, for the most part, required JavaScript, save for some bits and pieces like submit buttons in forms. The new Popover API provides a method for displaying popover content on top other page content, like a modal window, and wonderfully does not require JavaScript, as it’s baked right into the browser.

At its simplest, turning an element into a popover element is done by applying a popover attribute; likewise, attaching a button to that popover element (to open and close it) is done by adding a popovertarget attribute whose values is the id of the popover element:

<div id="wibble" popover>Popover content here</div>
<button popovertarget="wibble">Toggle Popover</button>

Popover content here

Included with popover elements is a new pseudo-element, ::backdrop, that covers the entire viewport, can be styled with CSS, and can even intercept clicks to hide/close the popover.

There are a tonne of other features that I won’t go into detail about today, but includes other quality-of-life things like the Escape key closing popovers, being able to control whether buttons should open, close, or toggle its respective popover element, etc.

I’m using this great new browser feature to hold my website’s settings, which tucks them away neatly when not in use and saves me from having to write and maintain some JavaScript to control the interactions!

If you want to learn more about Popovers, Hidde de Vries has written extensively on their intricate details, how to use them effectively, and accessibility related to their use. I can’t recommend Hidde’s work enough. It’s absolutely worth the read!

The :has() selector

I spent many years as a developer wishing, hoping, and deeply-lamenting the non-existence of the parent selector. I cannot count the number of times that I’d be working on something and mourned how much more readable and easy life would have been had there been a way to style a parent element based on its children element(s).

So with the introduction of the indomitable :has() selector, my hopes and dreams were finally realised.

For example, in the past, if I wanted to style my <h2> elements in a particular way when it contains an <a> element, I’d have to do something like create a specific class that I would also need to remember to include in my HTML:

<h2>This is a heading</h2>
<h2 class="has-anchor">

<a href="#_">This is also a heading</a>

</h2>

h2.has-anchor {
	/* apply specific styles */
}

With the :has() selector, a lot of the mental overhead involved with that solution just floats away:

<h2>This is a heading</h2>
<h2>

<a href="#_">This is also a heading</a>

</h2>

h2:has(a) {
	/* apply specific styles */
}

When it comes to applying the settings on my website, I’m providing a series of <select> elements that visitors can use to control things like the colour scheme, theme, and smooth scroll. I’m applying a set of styles based on the selected <option> inside those <select> elements and their associated values in conjunction with the :has() selector.

Let’s look at the HTML for the colour scheme setting controls:

<label for="color-scheme-selector">Light/Dark:</label>
<select id="color-scheme-selector" 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>

By default, I’m leaving it up to the browser / operating system to define whether a visitor prefers a light or dark colour scheme. When this setting is left alone, I can use a media query to match whatever this preference may be, e.g.:

@media (prefers-color-scheme: dark) {
	html {
		/* apply dark colour scheme styles */
	}
}

However, if the visitor were to select either the Light or Dark options, I can use the :has() selector to match their selection and apply those same styles:

html:has([name="color-scheme"] [value*="dark"]:checked) {
	/* apply dark colour scheme styles */
}

Although this selector might look a little unwieldy, what it’s doing is checking the DOM to see if the <html> element contains an element that has a name attribute whose values is color-scheme, which matches the <select name="color-scheme"> element. And if the child element <option value="dark"> is selected, then apply my dark colour scheme styles.

I’m using this same pattern for all of my website’s settings, and I couldn’t be more thankful that the fabled parent selector is finally a reality!

<storage-form>

The last piece of the puzzle here is a critical one. Being able to open and close the settings popover and make some choices to control how to experience my website is one thing, but if those choices don’t persist when navigating between pages, then the settings could be more of a headache than the lovely feature that I’d like them to be!

That’s where <storage-form>, a Web Component by David Darnes that allows form elements to persist and be saved, comes in. It uses the browser’s Local Storage to save what the visitor has typed/checked/selected in form elements, and reads those saved values from Local Storage so they can be reapplied whenever the visitor navigates between pages and even when completely leaving the site and returning later.

Usage is very straightforward and done by wrapping <form> elements with the Web Component:

<storage-form>
	<form>
		<!-- settings form inputs here -->
	</form>
</storage-form>

Unfortunately, this does mean that persisting visitor choices of settings between pages requires JavaScript, but I cannot overstate how useful this Web Component is. I feel so lucky that great folks like David are contributing to the ecosystem of Web Components!

If you’re interested in exploring the wealth of amazing Web Components that you can just about drag-and-drop into your own projects and start using, I’ve got a list of Web Components on GitHub that you might want to browse through.

This is post #10 of #WeblogPoMo2024 / Weblog Posting Month 2024, a one-month challenge to post as often as possible (daily, ideally) for the duration of May 2024!

Learn more on Anne Sturdivant’s website.

Thanks for subscribing and reading this post via RSS!

You can read this post and others on my website.

The Cluster Composition

2024-05-07T18:39:29+08:00

In this post, I’m going to cover how I use a snippet of CSS for laying out list items that called the Cluster.

The contents of this post require my website’s CSS to appear properly.
See the web version: https://chrisburnell.com/article/cluster-composition/.

In the CUBE CSS methodology, there is the concept of a composition. In short, a composition is a piece of CSS that creates flexible, component-agnostic layout systems that support as many variants of content as possible^[1].

While there is a layout in Every Layout also called The Cluster, I’ve built my own version that serves a very similar purpose but achieves it with slightly-different CSS. I’m using my version of the Cluster composition for a number of lists around my website: breadcrumbs, the category/tag lists on post pages, links in the footer, and response types, to name a few.

This composition uses CSS variables with fallback values as a means of creating variants. This means that when the composition’s CSS variables are not set, the fallback value is applied, creating the default version of the composition, so by setting the CSS variables, we can modify the behaviour of the composition.

Without further ado, here’s the code for my Cluster composition:

.cluster > * {
	display: inline-block;
}
.cluster > *:not(:last-child)::after {
	content: var(--delineator, "·");
	padding-inline: var(--padding-inline, 1em);
	line-height: 0;
}

Using the Cluster

Using the cluster is done by applying the cluster class to some HTML:

<ul class=" [ cluster ] ">
	<li>One</li>
	<li>Two</li>
	<li>Three</li>
</ul>

One
Two
Three

Styling my website’s breadcrumbs is done by setting the --delineator variable to a desired value using a class or with inline styles:

<ul class=" [ cluster ] " style="--delineator: '→';">
	<li>One</li>
	<li>Two</li>
	<li>Three</li>
</ul>

One
Two
Three

And for cases where I want greater spacing between list items, I can set the --padding-inline variable to a desired value:

<ul class=" [ cluster ] " style="--padding-inline: 2em;">
	<li>One</li>
	<li>Two</li>
	<li>Three</li>
</ul>

One
Two
Three

Compositions are a seriously powerful concept that I’ve enjoyed using ever since learning about them from the indomitable Andy Bell, and it’s given me a really strong sense of control over the styles that I write.

What methodologies do you use when authoring CSS? Do you have any compositions that you find yourself using all over the place? I’d love to learn more about what gives you a sense of control over your styles too!

This is post #7 of #WeblogPoMo2024 / Weblog Posting Month 2024, a one-month challenge to post as often as possible (daily, ideally) for the duration of May 2024!

Learn more on Anne Sturdivant’s website.

Thanks for subscribing and reading this post via RSS!

You can read this post and others on my website.

Mixing Colours in Different Colour Spaces

2024-03-05T04:58:00+08:00

Visualise how different colour spaces will mix two given colours.

Thanks for subscribing and reading this post via RSS!

You can read this post and others on my website.

Some use cases for revert-layer

2024-02-14T10:27:37+00:00

CSS Layers has been such a boon to wrangling specificity, and it’s really helped me get a better understanding of the CSS I write from a bird’s eye view. So I’m surprised that I’m just learning about revert-layer now, but super glad that this fabulously-comprehensive article by Mayank is what introduced me to it!

Reference: https://www.mayank.co/blog/revert-layer

Thanks for subscribing and reading this post via RSS!

You can read this post and others on my website.