Chris Burnell – Latest Posts

Prometheus

2024-01-18T19:45:00+08:00

Thinking back on the time that my Mum gave me the first six A Book Apart books as a gift when I first left Canada to start my career in the UK in 2011. They meant so, so much to me. Not just for the enlightening words within, but also because they were this tangible thing that reminded me of the encouragement from my very academic family to take on the daunting task of “making it on my own” without a degree.

Those books inspired the hell out of me. I treated the words inside like gospel. I immersed myself in front end and the web and worked hard to become really good at my craft. Little did I know that, in time, not only would I get to meet some of these accomplished authors, but they would actually know who I was too. I had dreams of getting to finally meet them—heroes in my eyes—to totally fanboy out and get their autographs on the inside covers.

A few months later, I landed my first proper gig in the industry as a Front End Developer. I almost couldn’t believe it. I did it. It was really happening.

Boy, did I learn a lot in those first few months. It felt like that scene in The Matrix where Neo is learning a new martial art every minute. I was also extremely lucky to work with some truly talented, patient, and kind designers and developers, many of whom I still consider great friends today.

A short time passed, and my young and naïve self, wanting to share all the incredible stuff I had learned, brought the books into work.

That same afternoon, I went to make a coffee in the kitchen, and when I came back, the books were gone from my desk. No one admitted to taking them, and I never saw them again. It broke my heart and made my blood boil.

Still does.

Here I am now, 12 years later, having recently moved from London to Singapore, and finding myself in a similar situation as before: facing the stupidly-scary task of trying to find success off the back of my own efforts. Of course, I know a lot more now than I did back then—or so I’d like to think!—but new environments have always been a true test of my resilience.

Ever since those first few months in my first front end role, I’ve wanted to work in Developer Relations. It was never something that seemed to fit into where I was in my career or who I was as a person, despite my best efforts in every job and role I’ve had since then to make it a part of my job, however small that part may have been. Whether it was organising short, weekly meetings to talk about interesting new technology, share fun and interesting things I’d found, or even just being a knowledgable voice pushing for better standards, accessibility practices, etc. I was always reaching for it.

This time, though, I think I finally have the gumption and drive to make it happen. To not just reach for it but to leap halfway around the world and wrestle it into my hands. In fact, I’m determined and steadfast that I will find success, once again, no matter the challenges and doubt that I’ll face along the way.

I guess I owe it to myself to order new copies of the books that I lost and fulfil that fanboy dream of mine from 12 years ago. Hopefully once I’ve found my way here in Singapore and built up some steam, I can make my way back for a short visit (ideally around State of the Browser) and see it through. It’ll be a reminder of the encouragement from myself to persevere, believe in my success, and “make it on my own” all over again.

Can you teach an old design system new colours?

2023-12-23T13:00:00+08:00

Hexidecimal / RGB

Raven
```
#5f8aa6
```
Thunder
```
#060606
```
Snowy
```
#f9f9f9
```

For many years, my colours were defined in Hexidecimal format, or Hex as it’s commonly known as, which maps to the RGB colour model. This was essentially the de facto way of defining colours back when I started web development in 2008.

But when it comes to reading and understanding Hex and RGB colours, it’s a bit more tricky, particularly when dealing with the hexidecimal numbering system.

Using the sliders above, try to make this blue.

Now try to make it this pink.

This is absolutely not an easy task! This is because all three values, in tandem, are responsible for controlling not just the hue, but also the saturation and the lightness of that hue. This makes authoring and reading Hex and RGB values difficult as it’s difficult to imagine how certain ratios and amounts of each value mix to produce a colour.

RGB is an additive colour format. This means that, starting from black, we combine red, green, and blue together to create a colour, and the syntax we use when coding to define Hex/RGB colours follows this format: we have to provide a red, green, and blue value.

These limitations, particularly in creating (or finding) colours, were probably a good thing for web development, as it spawned countless, incredible tools that presented Hex/RGB in ways that are generally easier to understand and manipulate for humans than manually adjusting RGB values. This almost-surely pushed the collective understanding of colour on the web further and helped ingratiate people towards alternative and newer formats for defining colour.

HSL

Raven
```
hsl(204 29% 51%)
```
Thunder
```
hsl(0 0% 2%)
```
Snowy
```
hsl(0 0% 98%)
```

Enter HSL. Coming from the world of Hex/RGB, it was immediately more-readable to me, where the values in the HSL syntax tell us: which direction in the colour wheel to point; how saturated (how much) of that colour we want, and the lightness of the produced colour.

It’s important to know that HSL uses the same sRGB colour space as Hex and RGB, it just provides different parameters for us as developers to achieve the same colours.

Like before, using the sliders above, try to make this blue.

Then try to make it this pink.

It may not necessarily be quicker to do, but the inputs that we get with HSL are certainly more intuitive to work with and comprehend than RGB’s. Importantly, it puts two of the ways that we typically describe colour with language, by a colour’s Hue and Lightness, as two of the colour format’s inputs (which, I imagine maps to parts of the brain more easily than RGB). The third input, Saturation may not be immediately obvious, but can be understood by playing with its value.

Hue

In contrast to manipulating RGB values, finding the Hue of your target colour is much easier here; although, not perfect, it’s still not trivial to be able to remember how much rotation is required to find your target Hue.

Setting the Saturation to 100% and Lightness to 50%, and then cycling through the values for Hue, from 0° to 360° will give you an idea of what colours look like in their most saturated and untinted/unshaded form.

Saturation

Next is Saturation which dictates how much of our given Hue we want.

With any Hue, try setting the Lightness to 50%, and then cycling through the values for Saturation, from 0% to 100%. This will give you an idea of how the amount of Saturation we apply to Hue dictates how far away from being completely-greyscale we make the colour. You’ll also notice that when the Saturation is at 0%, it doesn’t matter what the Hue is anymore—given the same Lightness, an unsaturated Red Hue and an unsaturated Cyan Hue appear the same.

Lightness

The easiest way for me to understand the Lightness value is to think of it like a slide between black and white. The midpoint at 50% mixes your colour with both black and white (so a grey colour that is perfectly between black and white). As you deviate away from the midpoint, your colour is mixed with either more black and less white (as Lightness decreases) or more white and less black (as Lightness increases), reaching a point of being pure black at 0% and pure white at 100%.

You can see this effect no matter what the Hue and Saturation values are.

Problems with the sRGB colour space

Inconsistent perceived lightness

While one of the parameters of an HSL colour is Lightness, you’ll find that there is a stark contrast in how we perceive the brightness of Hues around the wheel.

Cyan and blue both have identical Saturation and Lightness values—only their Hues differ—but we perceive the cyan as being much brighter than the blue. We can account for this by changing Saturation and Lightness to compensate, but an ideal colour space would provide consistency in its parameters.

Dead grey zones

A clear example of this is in displaying gradients; when instructing the browser to traverse the colour space to find a line between two colours that will make up the gradient, you’ll often find that it takes a path that you don’t expect or want. It’s not uncommon to find that developers have created gradients that don’t simply traverse from point A to point B in the colour space; they provide additional colour stops to ensure that the gradient looks correct.

In the example, I’ve instructed the browser to create a gradient between red and cyan, but you’ll notice that it goes through a grey/monochrome area of the colour space around the midpoint. I would hope that the produced gradient would tween between not just the hues of red and cyan, but also their lightness and saturation. It seems, however, that the path taken to draw gradients often goes through parts of the sRGB colour space that have little or no saturation, leading to dead grey zones.

OKLCH

Raven
```
oklch(61.29% 0.064 237.73)
```
Thunder
```
oklch(15% 0 0)
```
Snowy
```
oklch(98.2% 0 0)
```

And finally, where I’ve happily landed: OKLCH. This is the most flexible and understandable colour format that I’ve found, but do check out the list of predfined colour spaces in the CSS Color Specifications for all the possibilities.

Last time now, using the sliders above, try to make this blue.

Finally, try to make it this pink.

This is about on the same level as HSL in terms of authoring and reading, but OKLCH fixes a number of problems with the sRGB colour space that makes it more consistent and reliable across its colour space. In addition, it offers both more colours and colours that are outside of the sRGB colour space, i.e. colours that were not achievable on the web before.

Browser Support

Desktop support:

Chrome: 111
Edge: 111
Firefox: 113
Opera: 97
Safari: 15.4

Mobile support:

Android Browser: 111
Chrome (Android): 111
Firefox (Android): 113
Safari (iOS): 15.4
Samsung Internet: 22.0

oklch

Browser support data for oklch comes from MDN’s browser-compat-data and is up-to-date as of version 5.5.10.

Lightness

Lightness here functions similarly to the HSL Lightness value in that it mixes your colour with different levels of black and white.

You can see this effect no matter what the Chroma and Hue values are.

Chroma

Chroma is similar, again, to HSL’s Saturation; it dictates how much of our given Hue we want. What differs from HSL’s Saturation is that even when the Lightness is zero, we still get some colour, depending on how much Chroma we apply. So in this colour space, greyscale colours, including black and white, require that the Chroma value be 0.

You’ll also notice that, like with HSL’s Saturation, when the Chroma is at 0%, it doesn’t matter what the Hue is anymore—given the same Lightness values and zero Chroma, changing Hue no longer affects the produced colour.

Hue

OKLCH’s Hue functions very much the same as HSL’s Hue, but the values don’t line up exactly the same. This is because unlike Hex/RGB and HSL, OKLCH operates in a different colour space and actually makes available (to supporting browsers and devices) even more colours than were available in the sRGB colour space.

Try setting the Lightness to 50% and the Chroma to 100%, and then cycling through the values for Hue from 0° to 360°. This will give you an idea of what colours look like in their most saturated and untinted/unshaded form.

Colours in practice

This all came about when I decided that I wanted to add a Sepia theme to my website (check out the theme selector in the footer!), but I didn't have a clean and concise way to go about it. What I wanted was a way to slightly-tint all the colours on my website into the sepia range.

Until recently, I had defined my colours manually, like this:

--color-raven: oklch(61.29% -0.034 -0.054);
--color-thunder: oklch(12.2% 0 0);
--color-snowy: oklch(98.2% 0 0);
--color-mineshaft: oklch(28.9% 0 0);
--color-yeti: oklch(89.8% 0 0);
--color-lynx: oklch(17.6% -0.01 -0.014);
--color-bear: oklch(96% -0.006 -0.01);
...

So building a theme where all of the colours are tinted sepia meant redefining each of the CSS Variables I had already defined for the default (non-sepia) theme.

That’s where the incredible new CSS function, color-mix(), comes in! Using it, I’ve been able to boil down my 13-colour palette into 3 core colours and 10 variations of those colours.

The first step is to set up some initial CSS variables to use for building out the --color-* variables. These are the variables that we’ll later use to change themes, including our desired Sepia theme.

--snowy-lightness: 98.2%;
--thunder-lightness: 15%;
--monochrome-chroma: 0;
--monochrome-hue: 0;
--raven-lightness: 61.29%;

--raven-chroma: 0.064;

--raven-hue: 237.73;

Next, we’ll build out the 3 base colours in the palette using the above variables, and from these 3 base colours, the 10 remaining colours in the palette can be constructed:

Raven

oklch(
	var(--raven-lightness)
	var(--raven-chroma)
	var(--raven-hue)
)

Thunder

oklch(
	var(--thunder-lightness)
	var(--monochrome-chroma)
	var(--monochrome-hue)
)

Snowy

oklch(
	var(--snowy-lightness)
	var(--monochrome-chroma)
	var(--monochrome-hue)
)

Mineshaft

color-mix(
	in oklab,
	var(--color-snowy),
	var(--color-thunder) 83.6%
)

Kaiser

color-mix(
	in oklab,
	var(--color-snowy),
	var(--color-thunder) 66.6%
)

Nickel

color-mix(
	in oklab,
	var(--color-snowy),
	var(--color-thunder) 51.8%
)

Yeti

color-mix(
	in oklab,
	var(--color-snowy),
	var(--color-thunder) 10.2%
)

Lynx

color-mix(
	in oklab,
	var(--color-raven),
	var(--color-thunder) 75%
)

Wolf

color-mix(
	in oklab,
	var(--color-raven),
	var(--color-thunder) 54%
)

Bowhead

color-mix(
	in oklab,
	var(--color-raven),
	var(--color-thunder) 33%
)

Highland

color-mix(
	in oklab,
	var(--color-raven),
	var(--color-snowy) 33%
)

Coyote

color-mix(
	in oklab,
	var(--color-raven),
	var(--color-snowy) 54%
)

Bear

color-mix(
	in oklab,
	var(--color-raven),
	var(--color-snowy) 75%
)

Why am I mixing colours with in oklab?

I prefer the way that OKLab mixes colours and traverses the colour space for gradients; although, I still much prefer the syntax of defining colours themselves using OKLCH.

And with that, the 13-colour palette is complete!

Time to start putting all this work to use.

Applying a tint

Now that we have 3 base colours and 10 variations, built in the browser based on 7 variables, we can redefine just a few of those variables and affect the entire palette.

/* bring down the amount of white */ --snowy-lightness: 88%; /* slight yellow tint to monochrome colours */ --monochrome-chroma: 0.06; --monochrome-hue: 90;

/* slight yellow tint to raven-based colours */ --raven-chroma: 0.034; --raven-hue: 180;

Sepia Theme

Raven
Thunder
Snowy
Mineshaft
Kaiser
Nickel
Yeti
Lynx
Wolf
Bowhead
Highland
Coyote
Bear

This makes it easy to change the theme of my website just by manipulating the raven-based variables. Critically, you might notice that the perceived brightness of the colours between these themes look much more consistant than what the RGB colour space provided.

Raven
Thunder
Snowy
Mineshaft
Kaiser
Nickel
Yeti
Lynx
Wolf
Bowhead
Highland
Coyote
Bear

Opacity vs. Transparency

I also have a set of defined opacities that I use with the opacity property throughout my CSS:

--mostly-opaque: 90%;
--barely-opaque: 10%;
opacity: var(--barely-opaque);

The first instinct here might be to generate even more CSS variables for every combination of colour and opacity that I have defined, but we can actually use color-mix() once again to reuse the CSS variables that we already have:

--mostly-opaque: 90%;
--barely-opaque: 10%;
background-color: color-mix(in oklab, var(--color-thunder), transparent calc(100% - var(--mostly-opaque)));

You’ll notice that I’m using calc() at the end to invert the opacity variable. This is because opacity and transparency are opposites; if something is opaque, it is not transparent! (Deep facepalm when I finally realised this.) So when we say we want something to be 90% opaque, it's the same as saying we want it to be 10% transparent, which the calc() function achieves for us.

Problems with new colour spaces

There are some limitations and gotchas to be aware of when using these new colour spaces; although, they have more to do with compatability and browser support than difficulty in describing and representing colour.

Fallbacks

First of all, older browsers that don’t support oklch() (see modern browser support), for example, will require fallbacks wherever you use newer colour formats:

/* put one of these first: */
color: #5f8aa6;
color: rgb(95, 138, 166);
color: hsl(204 29% 51%);
/* to fallback on from this, where the
entire line of CSS fails in
unsupported browsers: */
color: oklch(61.29% 0.064 237.73);

However, this does not work:

--color-raven: #5f8aa6;
--color-raven: oklch(61.29% 0.064 237.73);

Instead of what you’d hope would happen—older browsers ignore the second line—the --color-raven variable is instead always set to the second value, even if it isn’t supported and won’t work. This is also important if you plan on supporting older browsers and using color-mix() too (see modern browser support) because you’ll be unable to use the technique I’m using to combine colours.

You can use the amazing website, OKLCH Color Picker & Converter to calculate colours in the sRGB colour space that are relatively close to your OKLCH

Out of range

Secondly, there are areas of the new colour spaces you’ll find when using oklch(), oklab(), lch(), lab(), color(), etc., that are outside of the sRGB colour space, and therefore cannot be accurately represented in Hex, RGB, or HSL, for example.

You may also run into the issue of hardware being unable to present your vivid, new colours because they exist outside the colour space that a given display is built to show. I hope it’s only a matter of time before supporting hardware becomes more widespread and we can have more confidence that our colours will be presented to our website visitors just as we intend; although, I certainly dislike the waste involved in “upgrading” all those devices.

However, like with new and emerging web standards, without adopting these new colour spaces, we’ll be missing out on huge chunks of a beautiful spectrum that the web of today is already ready for!

Taking this further

I can’t overstate how much clearer HSL and OKLCH colour formats are to read and author compared to Hex and RGB. Unless you’re using a CSS preprocessor like Sass/SCSS, it can be laborious to calculate combinations of colours or create tints, particularly if the colours in your palette ever change.

Colour formats like HSL and OKLCH give us much more intuitive understanding of the nature of a given colour, and the ways to manipulate and create variations of those colours

I hope you found this useful, and I’d love to know how others are doing this sort of things or what kind of pitfalls I might run into using this technique!

Halfway to CSS Naked Day 2024

2023-10-09T12:00:00+00:00

I was really happy to participate in CSS Naked Day earlier this year, and today marks the halfway point to CSS Naked Day 2024. Just six more months until it’s time to don the Emperor’s New Clothes and show off your <body> for what it really is. (CSS Naked Day)

If you use Eleventy or use JavaScript to build your website, check out my article, CSS Naked Day JavaScript Function, for a swift guide to how I prepared for next year’s event, which actually spans for 50 hours. 🤔

In the article, I explain how I’ve set up a Datetime check to figure out Is it CSS Naked Day?. The result controls whether or not to link to CSS in my templates’ HTML, and the check runs every time my website builds.

That includes CI/CD builds, which effectively means I can set it and forget it, which I love being able to do.

Hope to see you participating on the 9^th of April as well!

Moose Country

2023-08-21T18:53:44+01:00

I took this photo at the Bog along the Cabot Trail in Cape Breton Highlands National Park.

This is the 1000^th post on my website!

Yahaha! in Halifax

2023-08-18T10:47:00+01:00

Gotta stay alert outside the Art Gallery of Nova Scotia.

Note from July 1, 2023

2023-07-01T12:24:18+01:00

Happy Canada Day! 🇨🇦 Have a good one, eh?

Double-Double

2023-06-12T15:00:00+01:00

Skip to the full Double-Double technique.

What is a Double-Double?

The Double-Double, practically a proper noun in Canada, refers to a Tim Horton’s coffee with two creams and two sugars. Although the quality of Tim Horton’s has certainly declined, it was, once upon a time, a staple part of my diet, as it was/is for many Canadians, and I look back on them fondly.

What does this have to do with CSS?

The power of the Double-Double technique is in using shorthand/logical properties and a clever feature of CSS Variables: the ability to provide a fallback value that gets used when a CSS Variable is not defined.

We’ll use that feature twice, nesting one CSS Variable inside another to provide a chain of values to be checked and used by the browser, and then again as we use the technique alongside shorthand CSS properties.

Let’s break that down.

Working with defaults

First, we’ll look at how default parameter values work in a JavaScript function. In this example, we’ve given the wordsPerMinute parameter the default value of 200:

const readingtime = (numberOfWords, wordsPerMinute = 200) => {
	return Math.ceil(numberOfWords / wordsPerMinute)
}

This means that we can use the readingtime function with or without providing a wordsPerMinute value—without one, the function will use our default value of 200.

We can do something similar in our CSS. For example, we might want a component to have a default font-size, but still give ourselves a uniform means of changing the font-size for a variation of the component.

Fortunately, CSS Variables give us this ability:

.component {
	font-size: var(--font-size, 1em);
}

With this line of CSS, we’ve instructed our component to have a font-size of 1em, and if the --font-size CSS Variable has been defined it will be used instead. So if we wanted to create a variation of our component, all we need to do is define --font-size:

.component--variation {
	--font-size: 5em;
}

This is super useful! We can use this technique for many properties and values that we might set on a given component, and because the syntax of defining defaults and overriding them (as above) is consistent, our CSS draws a clear distinction between base-level component and variations of those components.

Nested CSS Variables

One thing that’s great about using the var() function in CSS is that it can be nested! We’ll use this to create a chain of checks before our component resolves to our defined value:

.component {
	font-size: var(--first, var(--second, 1em));
}

With this line of CSS, we’ve given our component a set of ordered instructions for setting a font-size value:

Use the --first CSS Variable if it has been defined
Use the --second CSS Variable if it has been defined
Otherwise, use the default 1em value

This is handy in all sorts of ways. Take the fill colour of an SVG, for example:

svg {
	fill: var(--fill-interaction, var(--fill, currentColor));
}
:is(:hover, :focus, :active) > svg {

--fill-interaction: red;

}
.dark-background svg {

--fill: white;

}

With some pretty terse and readable CSS, we’ve given the browser a whole suite of instructions to set the fill colour of our SVGs:

Use a sensible default of currentColor to match any text content that the SVG might be part of
When the SVG is shown on top of a dark background, we want to force our SVGs to fill with the colour white
When the SVG is inside an interactable element (e.g. inside a button), fill the SVG with red on interaction with the element

What’s also really nice is that we can circumvent some nasty specificity issues by nesting CSS Variables. Because the nested values will be evaluated in order, we, as the authors of the CSS, are in control, rather than the declaration with the highest specificity being in control.

We get to choose which selectors or conditions (interaction states, media/container queries, etc.) trigger a CSS Variable to be defined, and in this context, we’re concerned solely with whether or not it’s defined as a boolean attribute, not the specificity of the selector that defined it.

This means that switching on a CSS Variable can be done by a selector of any specificity, and, because CSS Variables will cascade, a selector which sets the values a CSS Variable can have less specificity than the selector which sets the property value itself:

.flow > * + * {
	margin-top: var(--spacing, 1em);
}
h2 {

--spacing: 5em;

}

I think, on the whole, this makes for a much more pleasant developer experience.

Je voudrais un Double-Double, s'il vous plaît

I’d like a Double-Double, please

It’s no secret that Logical Properties are one of my favourite additions to CSS in recent years. Consequentially, I’ve been thinking more and more about the block and inline axes of a webpage as I build components, and that’s where the Double-Double technique comes in.

MDN has great content on logical properties and values and shorthand properties if you want a refresher!

In short…

property: all;
property: block inline;
property: block-start inline block-end;
property: block-start inline-end block-end inline-start;

Let’s switch from our font-size example to one with padding so we can work with shorthand and logical properties. In the next example, we’ll provide two values to the padding property, each value being a nested CSS Variable.

The Double-Double Technique

.component {
	padding:
		var(--spacing-block,  var(--spacing, 1em))
		var(--spacing-inline, var(--spacing, 1em));
}

This new line of CSS (broken into three for readability) gives us a bunch of control over our component’s padding:

Defining --spacing sets a new padding-block and equal padding-inline value
Defining --spacing-inline sets a new padding-inline value, leaving padding-block to the default value
Defining --spacing-block sets a new padding-block value, leaving padding-inline to the default value
Defining any two of --spacing, --spacing-block, and --spacing-inline sets a new padding-block value and a new padding-inline value

And let’s not forget that CSS Variables will cascade and can be set to different values by multiple conditions. This means that once a variable has been set, or a component variation created, we’re still free to make variations by further overriding of the CSS Variables, based on different selectors or browser conditions!

When you extrapolate this idea across multiple properties for a component, you can start to see how much flexibility it affords you.

.component {
	padding:
		var(--spacing-block,  var(--spacing, 1em))
		var(--spacing-inline, var(--spacing, 1em));
	margin:
		calc(2 * var(--spacing-block,  var(--spacing, 1em)))
		calc(2 * var(--spacing-inline, var(--spacing, 1em)));
}

In this case, we’re defining both a padding and margin for our component with the Double-Double technique. You’ll notice that their values are almost identical, but we’ve instructed the component to have margin values that are 2× the size of the padding. We’ve baked this calculation right into the component’s declaration block, which means we don’t have to keep this mathematical relationship in our mind as we build out variations of this component and come up with new values to override the defaults.

Like before, this allows us to make simple, one-line variations of our components in CSS that (can) have a tremendously-powerful and deep-reaching impact to the computed outcome in the browser:

.component--variation {
	--spacing: 5%;
	--spacing-block: 120px;
}

This one change results in a variation that has the computed values quite different from the default component’s:

.component {
	padding-block-start: 1em;
	padding-inline-end: 1em;
	padding-block-end: 1em;
	padding-inline-start: 1em;
margin-block-start: 2em;

margin-inline-end: 2em;

margin-block-end: 2em;

margin-inline-start: 2em;

}
.component--variation {

padding-block-start: 120px;

padding-inline-end: 5%;

padding-block-end: 120px;

padding-inline-start: 5%;
margin-block-start: 240px;

margin-inline-end: 10%;

margin-block-end: 240px;

margin-inline-start: 10%;

}

Working with the cascade gets us further, and with less effort, than trying to swim against the current.

Quadruple-Quadruple?

Now, this might seem like the next logical step to take with this technique, but, much like having four creams and four sugars in a coffee, it’s just a bit too sweet for my tastes:

.component {
	padding:
		var(--spacing-block-start, var(--spacing-block, var(--spacing, 1em)))
		var(--spacing-inline-start, var(--spacing-inline, var(--spacing, 1em)))
		var(--spacing-block-end, var(--spacing-block, var(--spacing, 1em)))
		var(--spacing-inline-start, var(--spacing-inline, var(--spacing, 1em)));
}

But maybe that’s just me—to each their own!

Over to you

Have you been using this technique yourself? Or any similar techniques? Found any neat ways to use it I haven’t covered here? I’d love to hear from you!

Not without sacrifice

2023-05-05T00:20:09+01:00

I recently had the pleasure of watching Jack Franklin’s talk from All Day Hey! 2023, Abstractions, complexities and off-ramps, and a couple of slides at the end got me thinking about the landscape of developer concerns in front end; a bit cynically, I’ll admit, but it comes back around in the end!

In recent years, there has been a growing emphasis on the importance of Developer Experience (DX) in front end development. This has lead to the creation of powerful tools that assist developers in building and organising more feature-rich websites. With the introduction of new web technologies and seeing the maturity of beloved tools that have become essential to many in the field, suffice to say it has been an exciting time for web development.

However, when we compare our efforts in DX to efforts in User Experience (UX), it is important to remember that resources are not infinite. We can only expect to complete a day’s work in nothing less than a day. A decade ago, when the capabilities of the web were fewer and we didn’t have such a wide array of tools to aid in our work, we had more time to focus on the user’s experience. Assuming, of course, you hadn’t spent the entire week debugging a dropdown in Internet Explorer.

As new web features bubble to the surface (growing now to a rolling boil!) the responsibility for learning and implementing new and/or complex has shifted to the front end developer. As a result, the time we once dedicated to ensuring the best experience for all users has been consumed by more developer-centric tasks. Unfortunately, this has left experiences for users who are not browsing under optimal conditions neglected.

In light of these constraints, our priorities as front end developers and the time we have to dedicate to each part of our work has shifted. Changing how we look at this shift puts the battle between DX and UX in a different perspective:

That being said, it seems like things are moving once again focus more on the UX of our work—not to say that it’s DX’s turn to be thrown to the wayside, but that a concerted effort needs to be made to maintain an appropriate balance.

This shift hasn’t only just begun; we’ve seen great articles musing on this subject and even evidence of this shift in different forms today, e.g.

The Developer Experience Bait-and-Switch by Alex Russell
Split by Jeremy Keith
accessibility overlays (though mileage may vary)
web features like prefers-reduced-motion and color-scheme
accessibility compliance laws
an ever-growing focus on building greener websites

It’s heartwarming to see concerns about performance, sub-optimal browsing conditions, diversity, and more being brought back to the forefront of our discussions about how we should build for the open and inclusive web that we want.

A society grows great when there are those who would plant trees under whose shade they know they will never sit.

Dynamic Heading Borders

2023-04-17T23:47:02+01:00

For a long time, I’ve had a specific look to the most-common heading in my articles: the Level 2 Heading, or <h2> element. While doing some refactoring recently, in light of many developments on the frontiers of CSS, I found a new way to get the same result with a bit of new CSS that makes understanding what it does a lot clearer, and clarity is always important—if not for your teammates or the wider web’s understanding, at least for future you’s understanding!

Inception

In essence, what I want is for the borders underneath each heading to be the same width (inline-size) as the text inside, plus a small but consistent amount. I decided to use the relatively-new CSS value, fit-content, to achieve this:

h2 {
	inline-size: fit-content;
	display: flex;
	padding-inline-end: clamp(2.25rem, 0.5rem + 4vw, 4.5rem);
	box-shadow: inset 0 -2px 0 #dddddd;
}

The new heavy-hitter here is the fit-content value that I’m assigning to the inline-size (width). This means that the heading’s box will use the available space as its content grows and will never exceed its computed max-content, or however much space is taken up when its content does not wrap.

Importantly, this allows me to limit the width of the headings without re-assigning the default display: block; of headings, which browsers assign by default, to display: inline-block;, for example. This would achieve the same visual effect for the headings in a vacuum, but if placed around other elements which also have display: inline-block; assigned to them, there’s the possibility that they’ll sit alongside the heading (in the inline axis) rather than headings appear on their own line.

Forced line breaks around headings is already achieved by browser defaults, so I’m much happier relying on that and building progressively on top with fantastically-terse new CSS features like fit-content.

You can read more about fit-content and its brethren, max-content and min-content, on MDN as well as track its progress towards full stability across modern browsers on my Browser Feature Watch page.

Desktop support:

Chrome: 22
Edge: 79
Firefox: 126
Opera: 15
Safari: 16

Mobile support:

Android Browser: 4.4
Chrome (Android): 121
Firefox (Android): 122
Safari (iOS): 16
Samsung Internet: 4

intrinsic-width

Browser support data for intrinsic-width comes from caniuse.com and is up-to-date as of 23 February 2024.

CSS Naked Day JavaScript Function

2023-04-17T07:49:36+01:00

Recently, I wrote Why I participated in CSS Naked Day, discussing my experience preparing for CSS Naked Day and why it was so productive. Today I’ll explain how I turned off CSS across my website.

TL;DR: The JavaScript function

const cssnakedday = () => {
	const now = Date.now()
	const thisYear = new Date().getFullYear()
	const startEpoch = new Date(`${thisYear}-04-09T00:00:00+1400`).getTime()
	const endEpoch = new Date(`${thisYear}-04-09T23:59:59-1200`).getTime()
return startEpoch <= now && now <= endEpoch

}

Getting it into Eleventy

In Eleventy, there is a concept of Global Data Files. These are files which live in a specific location in your project. Eleventy parses and exposes the data in these files to be consumed anywhere that we have access to Eleventy’s Data Cascade, i.e. anywhere inside Eleventy templates/pages/etc.

What is particularly useful is Eleventy’s ability to work with many types of data, allowing us, as authors, to build with what feels most comfortable. Typically, we might reach for JSON, XML, or even YAML to store some block of data, but Eleventy allows us to work with JavaScript data files as well. In the same way that Eleventy will parse data stored as JSON and expose it to us as an Object or Array, so too will Eleventy parse and expose data that is exported by a JavaScript file, whether it be an Object, Array, String, Boolean, Function, etc.

This gives us the ability to expose data that is dynamic. In other words, we have the ability to modify what data comes out of a JavaScript file based on conditional checks, information that we pass into the JavaScript file (in the case of an exported function, for example), information and data from other parts of Eleventy, and so on.

In our case, the question that we're concerned with is: Is it CSS Naked Day? When the answer is yes, do not include references to CSS in our HTML. We’re able to answer that question by comparing datetimes:

start of CSS Naked Day < current datetime
current datetime < end of CSS Naked Day

When both of those conditions hold true, we know that it is currently CSS Naked Day.

Now let’s put our function into a Global Data File, e.g. _data/cssnakedday.js:

module.exports = () => {
	const now = Date.now()
	const thisYear = new Date().getFullYear()
	const startEpoch = new Date(`${thisYear}-04-09T00:00:00+1400`).getTime()
	const endEpoch = new Date(`${thisYear}-04-09T23:59:59-1200`).getTime()
return startEpoch <= now && now <= endEpoch

}

The returned value of this function, a boolean true/false, can then be used throughout our templates, wherever we might include CSS in our HTML. Here’s an example using Nunjucks:

{% if not cssnakedday %}
	<link rel="stylesheet" href="/css/global.css" />
{% endif %}

This way we don’t need to worry about manual intervention, and we can simply rebuild our website or let continuous deployment take care of the CSS Naked Day check and decide whether or not to include the link tag in a template’s HTML.