Back then, I was the esteemed Chair of the RICG — the "pirate radio" web standards body responsible for bringing responsive image markup to the web platform. Some of you remember. Some of you were there at the advent of responsive web design, helping to find brand new use cases where the web platform fell short — as a scrappy band of front-end specialists rallied, organized, and crashed headlong into a web standards process that did not welcome them. We demanded a seat at the table alongside browser vendors, representing the needs of web designers and developers and the users we served. Our numbers swelled to the hundreds, and after years of iteration, countless scrapped draft specifications and prototypes, and endless arguments-turned-consensus across antique mailing lists and IRC channels, we finally arrived at a workable syntax hand-in-hand with browser vendors. Then we made it real — raised money from the community to fund independently-developed implementations in browsers, built the polyfills that would drive adoption, wired these new features up major CMSs, wrote articles and gave talks, and distributed — if I may say so — some of the best t-shirts the web standards game has ever seen.

I imagine just as many of you weren't there for any of that, as ancient as that history is in web development terms. For you, responsive image markup has been around as long as you've been making websites — a dense, opaque, inexorable, inescapable aspect of the web platform, an arcane syntax and a constant source of frustration.

If you're in the latter group, well, please allow me to introduce myself: I did that. Right here; eyes front — me.

Every time you tried and failed to figure out why the browser was selecting a certain source from srcset? You didn’t know it, but I was the one putting you through it. Every time you had to pull in some enormous third-party library to deal with a syntax very clearly not designed to be parsed by any human? Not only was I the cause, hell, I might have helped write it. When you ran some workflow-obliterating bookmarklet in hopes of generating a sizes value that mostly, kind of matched the reality of your layouts? When it was all too much; when you threw up your hands — gave up — and instead found yourself foisting huge source files upon countless users who might never see any practical benefit, but would bear all the performance costs? None of that was your fault. That was all me. Not only did I not stop these syntaxes from being standardized, I was the flag-bearer for responsive images — I fought tooth-and-nail for the markup you’ve cursed.

Oh-ho, and as if that wasn't enough, here's the part that will really make you mad: I hate it all too.

Every talk I gave and article I wrote on the subject — the course I wrote about images, the entire book I wrote about images — all done through gritted teeth. There are parts of this syntax that I've hated since the moment I first set eyes on them — which, again, was the very same moment that I became their most vocal champion. I'm not sorry. I'd do it again.

The Beast

Don’t get me wrong: I don't hate responsive images. The problem needed solving, there are no two ways about that. Then, as now, the vast majority of a website's transfer size is in images. A flexible image requires an image source large enough to cover the largest size it will occupy in a layout — without responsive images, an image designed to occupy a space in a layout that's, say, two thousand pixels wide at its largest layout sizes would mean serving every user an image source at least two thousand pixels wide. Scaling that image down to suit a smaller display is trivial in CSS, but the request remains the same — the user bears all the transfer costs, but sees no benefit from an enormous image source.

Remember, too, that this problem stems from an era where sub-3G connections were still common. There was no reliable way to tailor those requests to a user's browsing context in a way that maintained browser-level performance optimizations — and ultimately, the solutions we got were effective, performant, and have saved unfathomable amounts of bandwidth for users. Responsive images, as a concept, are an incredible addition to the web platform. I'm proud to have been able to play a small part in it.

Hell, it's not even that I wholesale don't like the responsive image syntaxes. Not all of them, anyway. picture I liked from the very beginning. Granted, that's a prescriptive syntax, and it represents a very different set of use cases from "I just want fast images." The picture element is for control — the siren song that has called out to designers and developers of all stripes since time immemorial, and I’m no exception. Control over sources, control over the conditions used to determine whether they're requested, even control over whether the browser should bail out of the source selection algorithm entirely to the tune of "nevermind, don't load any source" — it took me a while to come around on that last one, but I got there.

What's not to like? Who wouldn't want that level of fine-grained control? Not only that, but picture made it possible to responsibly serve brand new image formats with fast, reliable fallbacks across browsers, opening the door for incredible advances in encoding and compression without the need for a single scrap of JavaScript. The syntax makes perfect, readable sense, it provides us with a template for standardizing smarter decisions around all media requests, and it grows ever more powerful as more and more media queries are added to the platform. picture is great. I like picture; everyone likes picture. We're not here to talk about picture.

picture is something altogether different from srcset and sizes, which represent a descriptive syntax. You use srcset to provide the browser with information about a set of image sources, identical apart from their dimensions, and sizes to provide the browser with information about how the image will be rendered, and at no point do you use either to tell the browser what to do with any of it. Once given this information, the browser can then use it to do exactly one (1) very complicated thing: determine the image source most appropriate for that user's browsing context. Visually, the source selected from the list of candidates in srcset doesn't matter to the user — the sources will all look the same — but the chosen candidate will best fit the user’s browsing context. You don't get any control over how that decision is made. In fact, you don't even get to know how that decision is made, by design — right down to an "explicitly vague" step in the source selection algorithm, carved into the HTML specification itself:

In an implementation-defined manner, choose one image source from sourceSet.

— Source

If something is said to be implementation-defined, the particulars of what is said to be implementation-defined are up to the implementation. In the absence of such language, the reverse holds: implementations have to follow the rules laid out in documents using this standard.

— Source

Unsettling, isn’t it? “Then the browser,” in strict technical terms, “just does whatever.” That formally codified lack of control didn't just happen; that buck could have stopped with me, but no. Instead, I personally thumbs-upped the decision that you should not have any say in how srcset/sizes work — that you can’t even know how they work. Now, after all these years — with this, the reveal that I’ve been the villain of the story all along — I can finally tell you why. You’re not gonna like it one bit, either. It’s because I know you would have done it wrong.

A human work

Don't take it too personally, I would've done it wrong too. Hell, I did do it wrong, through countless proposals and prototypes, in search of a solution that could be standardized — everybody did. In the end, all that iteration only proved that nobody could have gotten this part right. That "one thing" that srcset/sizes does — determining the image source best tailored to a user's browsing context, including viewport size, display density, user preferences, bandwidth, and countless other potentially unknowable factors? Those factors include things we can't know, and just as many things we shouldn’t know.

For example, we can't tailor asset delivery to a user's connection speed, which seems like a shame. For a moment, though, let's imagine we could — imagine we were able to say "use that source above this speed, and that source below it." Now that those decisions are yours to control: what connection speed thresholds would you set for your image sources, and what would I set for mine? They're different, I bet. That means that for a given connection speed, a user might get beautiful but bandwidth-obliterating image sources on one site, and highly compressed but wonderfully efficient ones on the next one. Which of those does that user actually want? Well, trick question, they'd all want something different, wouldn't they? What would your organization want? Uh oh. Everyone is looking to you now — you, with the open tickets, and a meeting in half an hour, and all this control foisted upon you by the specification. Why does the website feel so slow? Why do our images look worse than our competitors' now? Why does the website feel so slow again? Even when we're only considering connection speed, the cost of our having more control is the user giving up theirs, and that's before we've considered every other factor besides connection speed.

I didn't want that; I didn't want that for the people who build the web, I didn't want that for people using the web, and I sure as hell didn't want to see the web itself buckle under the strain of a million massive image files backed by a hundred thousand figure out our responsive images policy in excruciating detail when we have time issues buried in trackers forever.

The browser has access to a lot more information than we do — certainly more than we should reasonably want access to — so it can make decisions about screen size and display density and bandwidth and user preferences and any number of future factors we can't even imagine, without making any of it our problem. The browser can decide how to finesse details, like avoiding wasted requests by retaining larger sources rather than requesting functionally identical smaller ones if the larger sources already exist in the cache — I wouldn't want to own that logic. The browser can poll preferences set by a user, to give them control over these decisions and ensure a consistent experience from one site to the next.

Ultimately, we don't need control when it comes to optimizing an image request. We just want faster images, and srcset and sizes cover that use case handily — better than you or I ever could, if we had to. It would be miserable if we had to. A descriptive syntax avoids this whole nightmare for us, and allows the browser to do what it does best: use the information it has at hand to make a single, efficient request for an image source — something only the browser can do. We just have to provide it with what little information it doesn't have.

Honestly, srcset isn't even that bad, all things considered! Every CMS, static site generator, and build tool in the world can churn out a quick comma-separated list of generated image sources and their widths. Then the more of those values you put in the attribute, the more efficient and tailored the image requests can be; no fuss, no muss, no user-facing costs beyond a few extra bytes of markup. Pretty tidy little syntax, all things considered. I like srcset fine. It’s fine. We're not really here to talk about srcset either.

Responsive images aren't a problem. picture isn't a problem; srcset isn't even the problem.

We both know what the problem is.

The sizes dilemma

A browser can't know about the space an image will occupy in a layout because it makes decisions about image requests long before it has the information it needs to render that layout — there's nothing there for it to measure. The viewport size is available to the browser at that point, sure, but that's a terrible proxy for the size of a rendered image in a real-world layout. The web isn't made out of full-bleed "hero" images, it's made up of columns and grids and sidebars and "cards" and smatterings of little round user avatars. Assuming that an image source should never be larger than the user's viewport is a good start, sure, which is why an omitted sizes attribute (invalid, per the specification) behaves as though it were sizes="100vw" . That’s better than nothing, but not by much. So, instead, you and I are left describing the all of the sizes that an element will be, across every breakpoint and container query, as a single string, in an HTML attribute. How disgusting.

Precisely because it requires information about the surrounding layout, sizes resists automation in any meaningful way. A build process can't know the space an image will occupy across layouts without introducing a tremendous amount of overhead to that process — to the tune of "build everything, render the whole site, take measurements for every image on every page, generate sizes values for them all, and then continue the build." So instead we're left to generate that description manually — but except in very, very simple cases, we can't calculate a sizes attribute without tooling. Describing the sizes of a flexible image will require far too much calculation across breakpoints. (min-width: 1340px) 257px, (min-width: 1040px) calc(24.64vw - 68px), (min-width: 360px) calc(28.64vw - 17px), 80px is an example from a relatively simple layout, and there's no way anyone could be expected to write this. I mean, how — from, what, resizing your browser and squinting? Guessing? sizes is one of the few markup patterns that all but require the use of tooling, which the furthest possibly cry from the web's "open any text editor and you can build a website" ethos — something I value tremendously. Hell, even if you did manage to factor it all out, to describe it with media queries — to use a prescriptive syntax as a descriptive syntax, by using them to say "above this size, this is what happens" rather than "above this size, do this" — I feel sick. I hate sizes. I have always hated sizes.

That's why I'm here. That's why I'm writing this, finally, after all this time. I’m not here to apologize for sizes. I’m here to help bury it.

The beginning and the end

A few weeks ago, two patches landed in Gecko and WebKit — championed by Simon Pieters and Yoav Weiss, respectively, two of the RICG's finest. These patches landed to little fanfare, quietly aligning Gecko and WebKit with Blink in supporting a relatively recent addition to the HTML specification: support for an auto value in sizes attributes. Automatic sizes — the potential sizes of the rendered image, left up to the browser to determine alongside all those other factors. Fully automatic responsive images. Supply the browser with a list of candidates using srcset, bolt on sizes="auto", and let the browser do the rest.

How? Well, the central issue with srcset/sizes was one of timing, remember: "a browser makes decisions about image requests long before it has any information about the page's layout, so we had to provide it with that layout information." That assumption is no longer strictly true. That's still the default behavior, yes: if there's an img in your markup, the request it triggers will be fired off long before any information about the layout can be known — that is, unless that image uses the loading="lazy" attribute, an exceptionally common best practice for all but the images most likely to appear in the user's viewport at the time the page is first loaded. Adding loading="lazy" to an img changes that entire equation — now those images are requested at the point of user interaction, long after the browser has all the information it needs about the sizes of the rendered image. The browser doesn't need us anymore, and all's right in the world.

I bet you’re waiting for a catch. Well, if you're worried about browser support, don't be — upon encountering the string "auto" at the start of a sizes attribute, any browser with support for it will say "figure it out myself; got it," ditch the rest of the sizes attribute, and move on — browsers without support will throw the meaningless-to-them auto value out and continue on to the rest of attribute as usual. That means you can start using this right now, at absolutely zero cost and with no more overhead than typing auto, at the start of a sizes attribute:

<img 
  loading="lazy"
  src="TrIZjHKy9-650.jpeg" 
  srcset="GTrIZjHKy9-650.jpeg 650w, GTrIZjHKy9-960.jpeg 960w, GTrIZjHKy9-1400.jpeg 1400w"
  sizes="auto, (min-width: 1040px) 650px, calc(94.44vw - 15px)"
  alt="…">

Not the first four-letter word sizes has inspired me to use, but certainly the one with the most positive result.

This approach is exactly what WordPress is now using thanks to a patch from Joe McGill, another RICG alum still fighting the good fight.

You do (not) need sizes

Granted, it’s not over — you’ll still need descriptive sizes values now and then. An image likely to appear in the user's viewport when a page first loads is a situation where you wouldn't want to use loading="lazy" (again, sizes="auto" will only work with lazyloaded images), but these images are the exceptions, not the default.

Those few exceptions — the images all but certain to appear in the user's viewport way up at the top of the page, your most likely Largest Contentful Paint elements and thus poor candidates for loading="lazy"? Well, you saw one in your mind just now, didn't you? You imagined a big "hero" image; the kind of images that, say, occupy the full viewport width, or close to it? Relatively easy to describe across breakpoints? Maybe even somewhere in the ballpark of — I dunno, just to pull a value out of thin air — sizes="100vw". Every other image — all those images scattered throughout columns and grids and sidebars and "cards" and smatterings of little round user avatars that the web is really made out of? loading="lazy" sizes="auto". Job done. Congratulations.

I won't miss all those hand-hewn sizes attributes; I never had any love for them to begin with. I will never experience a shred of nostalgia for a thing that I helped make real and inexorably bound to my name. A syntax was never the goal; the goal was always a mechanism. At the time, the web platform lacked a way for browsers to make smarter decisions about what image asset to request and when, and no amount of clever scripting or markup trickery would ever result in an asset request as fast or efficient as one the browser itself could make. We got that mechanism — and I made all of us pay the cost of it, for the sake of our users and for the health of the web.

So, to any of you designers and developers who’ve wrestled with sizes attributes in the past: go ahead and render an image of me — any size you want — print it out, and stick it to your nearest dartboard. I hold my head high and I offer you no apology. I was right about this; we were right about this. I stand by the need for a declarative syntax. I stand by it every bit as much as I wish it could've been something better, and every bit as much as I know it couldn't have been, at the time. Sure, I bristle at the idea of giving up control as much as the next developer, but when it comes to high-performance images we could never have had any in the first place — not really. It would've been hubris to even try. As frustrating as it can be to give up control, owning responsive images would be a burden; a curse.

Ask me how I know.

The step attribute

When you add the step attribute to your <input> element, it specifies how granular the numbers can be in the input.

If you truly don't care what the value is, you can use step="any" like so:

<input id="number" type="number" value="42" step="any" />

See the Pen HTML Number Input with step='any' by Andy Bell (@piccalilli) on CodePen.

Your users can then input any number their heart desires, even if it's several decimal places deep.

But, let's say you want it to be a monetary value, for example, only to two decimal places. Then, you make step="0.01".

<input id="number" type="number" value="3.14" step="0.01" />
<!-- 3.15 valid, 3.14159 invalid -->

Try setting a value of three decimal places in this demo to see how it fails validation.

See the Pen HTML Number Input with step='0.01' by Andy Bell (@piccalilli) on CodePen.

Not too bad, right? You can even get funky with it and give it a really specific number value, and if the user clicks up and down with the input box controls, it'll go up by that amount:

<input id="number" type="number" value="3.14" step="3.14" />
<!-- 9.42 valid, 9.43 invalid -->

See the Pen HTML Number Input with step='3.14' by Andy Bell (@piccalilli) on CodePen.

Can I use pattern to do the same thing?

Theoretically yes. If you haven't seen the pattern attribute, you can use it in your HTML to do regex pattern matching. It can be used for decimal places too. Should you use it for that? Probably not, especially when step is right there, waiting to be used. But you can use it.

For example, you can use pattern to match a one or two-digit number with two decimal places after it:

<input type="number" pattern="\d{1,2}(\.\d{2})?" />
<!-- 12.34 valid, 123.4 invalid -->

Try typing in a number with more than two decimal places or three numbers before the decimal point to see how it fails validation.

See the Pen HTML Number Input with pattern='\d{1,2}(\.\d{2})?' by Andy Bell (@piccalilli) on CodePen.

...it's not cute, but it does get the job done if you really want this kind of behavior. The pattern attribute is definitely more suitable for text-based inputs — like an email address — rather than numerical ones. The pattern attribute doesn't provide the same UI controls that step gives you either.

This approach of using pattern is particularly good for adhering to specific patterns, like "a number that is exactly 4 digits" (pattern="[0-9]{4}"), rather than limiting input data to a certain number of decimal places. But, the max attribute set to 9999 will do the same thing, and it's more semantic.

What happens when I break the step or pattern?

With both step and pattern, your <input> element will match the :invalid pseudo-class in CSS, so you can style it, and there's often a browser-native validation message as well when a user tries to submit the form.

If your users type in an invalid value anyway, you can still run JavaScript on it and see what the value is. Sometimes the browser rounds the number to the closest one that will fit. I say "sometimes" because... It Depends™.

See the Pen HTML Number Inputs, with JavaScript by Andy Bell (@piccalilli) on CodePen.

In this demo, you can see that some of the initial values in the number inputs are valid, with suggestions on how to change them to see how the browser rounds things. The "raw" value in the input is what you see in the input, but the "valid" value is what the browser might be accepting instead.

Wrapping up

You should use step for controlling numeric increments because it's designed specifically to do that and the browser provides better UI controls for it natively. The step attribute is more mathematically based, too, instead of text-pattern based. It also works for other numeric input types like range and works really well when paired with the min and max attributes.

Use pattern for more complex pattern validation beyond the number of decimal places you want! But, remember that it doesn't have built-in incrementing and decrementing controls, and the validation is done based on text-pattern matching.

Still, this collection of demos is worth enjoying. Here’s a video for those who don’t have the latest version of Safari Technology Preview.

While we wait for native switch support, I thought I would build a highly configurable switch component using :has(), container queries, Logical Properties and Custom Properties for fun and to show you how much goes into a truly flexible component. Let’s dig in.

What we’re building

See the Pen Our final switch component by Andy Bell (@piccalilli) on CodePen.

HTML first, always

The HTML for this is pretty straightforward:

<label class="switch-input">
  <span class="visually-hidden">Enable setting</span>
  <input type="checkbox" role="switch" class="visually-hidden" />
  <span class="switch-input__decor" data-switch-input-state="on" aria-hidden="true"
    >On</span
  >
  <span class="switch-input__decor" data-switch-input-state="off" aria-hidden="true"
    >Off</span
  >
  <span class="switch-input__thumb" aria-hidden="true"></span>
</label>

The first thing to note is the root of this component is a <label> element. I like that pattern for checkbox and radio buttons because you get a nice increased tap area.

The HTML form control is a checkbox, but I’ve added a role="switch" attribute to it. This is so the component is announced as a switch by a screen reader and also each state change is announced as “on” or “off”, which is appropriate for a switch in my opinion.

I could have used an aria-label for the text label (always add a text label, pals), but I opted instead for a visually hidden <span>. The main reason is it’s easier for a user’s in-browser translation tool to translate the content.

Lastly, there’s 3 decorative only elements. The “on” and “off” text are hidden from assistive tech with aria-hidden="true" because that tech is already announcing those states. The visual thumb of the control is hidden in the same manner too because it only provides value for sighted users.

Configuration settings

As promised, this thing is configurable. There’s no better way in native CSS than Custom Properties.

:root {
  --switch-input-thumb-size: 44px;
  --switch-input-thumb-bg: #ffffff;
  --switch-input-thumb-stroke: 1px solid grey;
  --switch-input-off-bg: #444444;
  --switch-input-off-text: #ffffff;
  --switch-input-on-bg: #00a878;
  --switch-input-on-text: #ffffff;
  --switch-input-gutter: 4px;
  --switch-input-decor-space: var(--switch-input-gutter) 1.25ch;
  --switch-input-focus-stroke: 2px solid #ff6978;
  --switch-input-font-weight: bold;
  --switch-input-font-family: sans-serif;
  --switch-input-font-size: 18cqw;
  --switch-input-transition: inset 50ms linear;
}

I’m not going to go into too much detail at this point. I’ll explain stuff as we come to it in the component’s CSS. One thing I will note though is that the pixel sizes are there for reasons like:

1. I wanted to hit the WCAG minimum tap target size
2. The thumb size and thumb gutter are used in calculations, so clamp() is outa the window

Visually hidden utility

.visually-hidden {
  border: 0;
  clip: rect(0 0 0 0);
  height: auto;
  margin: 0;
  overflow: hidden;
  padding: 0;
  position: absolute;
  width: 1px;
  white-space: nowrap;
}

I roll this variant of screen reader only CSS out on pretty much every project and have done so for quite some time. This will allow a screen reader to read the label’s content, but will visually hide it and also prevent it from affecting layout etc.

The .switch-input root

It’s time to get stuck into the component now.

.switch-input {
  width: calc((var(--switch-input-thumb-size) * 2) + (var(--switch-input-gutter) * 3));
  height: calc(var(--switch-input-thumb-size) + (var(--switch-input-gutter) * 2));
  border-radius: calc(var(--switch-input-thumb-size) + var(--switch-input-gutter));
  padding: var(--switch-input-gutter);
  background: var(--switch-input-off-bg);
  color: var(--switch-input-off-text);
  text-align: left;
  text-transform: uppercase;
  font-family: var(--switch-input-font-family);
  font-weight: var(--switch-input-font-weight);
  position: relative;
  cursor: pointer;
  container-type: inline-size;
}

The first calculation is the width of the component itself because it is also the switch “track”. The two configuration options used are --switch-input-thumb-size and --switch-input-thumb-gutter. The thumb size is self-explanatory, but the gutter is the space around the thumb.

The gutter provides space around the thumb, so we need to account for each side of the overall .switch-input element and also added space for the middle. The formula for the calculation is thumbSize x 2 added to gutter x 3.

The border-radius uses the following formula for relative rounded corners: radius + padding. It’s not as visible in this context as say, a rounded rectangle, but if you have a large gutter it will make a difference.

There’s a lot of inheritable CSS in here such as font treatments, so we’ll skip that. The last bit I want to focus on is the container-type: inline-size. This will be used later to calculate the label’s size, so it’s critical that it is present here because that size will be relative to the track’s inline size. We also roll out position: relative because everything is absolutely positioned from here on in.

The decorative text elements

.switch-input__decor {
  position: absolute;
  inset-block: 0;
  inset-inline-start: 0;
  padding: var(--switch-input-decor-space);
  font-size: var(--switch-input-font-size);
  display: flex;
  width: 100%;
  align-items: center;
}

We’re using the logical versions of inset here because it’ll be handy for this component to respond the HTML dir attribute. For example, if a parent HTML has dir="rtl", it’ll automatically present as rtl.

It’s worth noting that the inset shorthand property is not logical. It is shorthand for top, right, bottom and left. That’s why we’re using the specific logical versions.

You can also see that we’re applying our font-size here, rather than inheriting from the parent. This is because the --switch-input-font-size Custom Property is using cqw units: a portion of the container’s computed width.

As that demo shows, if the component grows, the labels grow with it nicely. Please use this approach with caution though. You need to make sure that the text is large enough (ideally computed to at least 16px) and that it also zooms appropriately. With the switch input’s overall size being pixel controlled in this example, and the fact we’re using 44px — the minimum tap target size — that is the case.

Future stuff: align-content

A nice improvement to this decorative text’s rule would be the following (don’t add this to your code):

align-content: center;
display: block;
block-size: 100%;

We’re only using flexbox to vertically align our text labels in the middle. This new alignment capability is arriving to block elements in the future which should render those already completely out of date, vertical alignment CSS memes, useless, once and for all. I imagine this won’t change the social media clout chaser’s behaviour though, unfortunately.

.switch-input__decor[data-switch-input-state='off'] {
  justify-content: flex-end;
}

Lastly for this element, we’re adding a CUBE Exception to push the “off” label out to the inline end because the thumb will be at the inline start in the default off state.

The thumb element

Time to style up our little round thumb element.

.switch-input__thumb {
  display: block;
  width: var(--switch-input-thumb-size);
  height: var(--switch-input-thumb-size);
  border-radius: var(--switch-input-thumb-size);
  background: var(--switch-input-thumb-bg);
  border: var(--switch-input-thumb-stroke);
  z-index: 1;
  position: absolute;
  inset-block-start: var(--switch-input-gutter);
  inset-inline-start: var(--switch-input-gutter);
  transition: var(--switch-input-transition);
}

We’re making a square by setting the width and height, then making that square a circle by using the same configuration value for border-radius. You could use percentages here, but I personally prefer this approach. I think it’s a symptom of the bad old days of browsers.

It’s important to set z-index because we want this to always be a layer up from our decorative labels and guarantees that the thumb won’t interfere with the visual text.

Finally, using absolute positioning, the thumb is set to the inline and block start, using the logical inset values. A transition (very quick one!) is added to smooth out the on and off state changes. Normally I would recommend that you don’t transition inset because translate is much smoother, but in this context, it should be fine because it’s not a large surface area and the transition is very quick (100ms).

Focus states

The important thing to get right here for me is that the focus ring should show for keyboard users only and not when the component is clicked or tapped.

.switch-input:has(:focus-visible) .switch-input__thumb {
  outline: var(--switch-input-focus-stroke);
}

Luckily :focus-visible does this well and is very well supported.

The party trick here is the usage of :has(). Historically with this sort of component you’d have to write a selector like this: .switch-input input:focus-visible ~ .switch-input__thumb.

This would require the source order to be just right in the component. Now that we have :has() — which is also very well supported — that state can be determined at the root level of the component. In theory, the input could be the last child element now.

The on/off states

This is the last bit of CSS and we are done!

.switch-input:has(:checked) {
  background: var(--switch-input-on-bg);
  color: var(--switch-input-on-text);
}

.switch-input:has(:checked) .switch-input__thumb {
  inset-inline-start: calc(
    var(--switch-input-thumb-size) + (var(--switch-input-gutter) * 2)
  );
}

Historically setting the background of the switch component would again, require some weird combination selectors and extra elements, or require a JavaScript dependency. Not anymore because :has() allows us to change the background and text colour of the component (if required) based on its child :checked state. Handy!

We also use that pattern to change the position of the thumb. It’s a calculation that similar to the one we added earlier to set the size of the overall component. This time, it’s pushing the thumb to the end when the switch is “on”. This is why the --switch-input-gutter is doubled, to account for the start space and also the middle space.

Wrapping up

After all that, we’ve got ourselves a lovely little component:

See the Pen Our final switch component by Andy Bell (@piccalilli) on CodePen.

Would I use this in production? Probably, yeh. There has to be a damn good reason for a switch in the first place though.

Regardless, this is a handy little context to teach you about some of the super powers CSS gives us now.

Getting started

We’re keeping things on The Platform™ in this tutorial, so no need to worry about build processes. We’re going to have a single HTML page, a CSS file and a couple of JavaScript files.

First up, grab these starter files that will give you the right structure.

Download starter files

Extract those into the folder you want to work out of. It should look like this:

├── css
│   └── global.css
├── images
│   └── logo.svg
├── index.html
├── js
│   ├── burger-menu.js
│   └── get-focusable-elements.js

These files are all empty (apart from the logo), so let’s start filling them up.

Adding our HTML

We’ll start with HTML, so open up index.html and add the following to it:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <meta http-equiv="X-UA-Compatible" content="ie=edge" />
    <title>Build a fully-responsive, progressively enhanced burger menu</title>
    <link rel="stylesheet" href="https://unpkg.com/modern-css-reset/dist/reset.min.css" />
    <link rel="stylesheet" href="css/global.css" />
    <link rel="preconnect" href="https://fonts.gstatic.com" />
    <link
      href="https://fonts.googleapis.com/css2?family=Halant:wght@600&family=Hind:wght@400;500;700&display=swap"
      rel="stylesheet"
    />
  </head>
  <body>
    <script src="js/burger-menu.js" type="module" defer></script>
  </body>
</html>

This is our HTML shell and features all the relevant CSS, fonts and JavaScript files, pre-linked and ready to go. We’re using this modern CSS reset to give us some sensible defaults that we’ll build on with our custom CSS.

Let’s add some more HTML, first. Open up index.html again, and after the opening <body> tag, add the following:

<header class="site-head" role="banner">
  <a href="#main-content" class="skip-link">Skip to content</a>
  <div class="wrapper">
    <div class="site-head__inner">
      <a href="/" aria-label="ACME home" class="site-head__brand">
        <img src="images/logo.svg" alt="ACME logo" />
      </a>
      <burger-menu max-width="600">
        <nav class="navigation" aria-label="primary">
          <ul role="list">
            <li>
              <a href="#">Home</a>
            </li>
            <li>
              <a href="#">About</a>
            </li>
            <li>
              <a href="#">Our Work</a>
            </li>
            <li>
              <a href="#">Contact Us</a>
            </li>
            <li>
              <a href="#">Your account</a>
            </li>
          </ul>
        </nav>
      </burger-menu>
    </div>
  </div>
</header>

This is our main site header and it’s got a few bits that we’ll break down. First up, we have a skip link. A skip link allows a user to skip past the header and navigation and jump straight to the <main> element—which in our case—contains a simple <article>. It’ll be visually invisible by default and show on focus, when we get around to writing some CSS.

Next up, we have the brand element, which contains our placeholder logo. We’re using the aria-label attribute to provide the text to mainly assist screen readers. Very importantly, the alt on the image describes the image as “ACME logo”, with “ACME” being the name of the company.

Lastly, we have our main navigation—a classic unordered list of links in a <nav> element. It’s wrapped in a <burger-menu> element which is a Custom Element. This is a great example of HTML being an incredibly smart programming language because even though we’ve not defined what this element is or does yet, but the browser doesn’t care—it just continues doing what it’s doing, without any fuss. This capability helps us build this project progressively, which we’ll get into more, shortly.

We have an aria-label on our <nav> element. It’s not required in our case, but if you have more than one <nav> on a page, you must label them to help assistive technology.

Let’s wrap up our HTML by adding the last bit. Still inside index.html, add the following after the closing </header>:

<main id="main-content" tabindex="-1" class="wrapper">
  <article class="post flow">
    <h1>A responsive, progressively enhanced burger menu</h1>
    <p>
      Burger menus are a relic of responsive design that no matter what your opinion of
      them is, they continue to be a dominant design pattern. They’re very good at
      preserving often-limited horizontal space, but they also, more often than not, are
      built in a user-hostile, non-accessible fashion.
    </p>
    <p>
      <a
        href="https://piccalil.li/premium/build-a-fully-responsive-progressively-enhanced-burger-menu"
        >In this premium tutorial</a
      >, we’re going to build a burger menu from the ground up, using progressive
      enhancement, `ResizeObserver`, `Proxy` state and of course, super-solid HTML and CSS
      that pull from the CUBE CSS principles.
    </p>
    <p>
      This whole page is what you’re building in the tutorial 👆.
      <a
        href="https://piccalil.li/premium/build-a-fully-responsive-progressively-enhanced-burger-menu"
        >Let’s dive in</a
      >
    </p>
  </article>
</main>

There’s not much to say about this as it’s a pretty straightforward <article>. The only bit to make you aware of is that the <main> element should only feature once on the page, being the main content. We’ve got an id of main-content on there, too, which is what our skip link links to.

We’ve got all of our HTML now and guess what: we’ve got a fully functional web page (if you ignore the # links). The key to progressive enhancement is building up with a principle of least power approach. We know now that as long as this very small HTML page lands in the user’s browser, they can immediately and effectively use it.

Minimum Viable Experience CSS

We’re going to approach our CSS progressively too, so using principles of CUBE CSS: we’re going to start right at the top with some global CSS.

Open up css/global.css and add the following to it:

:root {
  --color-light: #ffffff;
  --color-light-shade: #fafffd;
  --color-dark: #062726;
  --color-primary: #d81159;
  --color-primary-shade: #b90f4c;
}

These are our site colours, neatly organised as some root-level CSS Custom Properties. The :root pseudo-class is just a posh way of using the <html> element. Keep in mind, though, that a pseudo-class (not pseudo-elements) has a higher specificity than a HTML element (<html> in this case). They have the same specificity as a class.

Let’s add some core globals. Still in global.css, add the following:

body {
  background: var(--color-light-shade);
  color: var(--color-dark);
  line-height: 1.5;
  font-family: 'Hind', 'Segoe UI', Roboto, 'Helvetica Neue', Arial, sans-serif;
  font-weight: 400;
}

h1,
h2 {
  font-family: 'Halant', Georgia, 'Times New Roman', Times, serif;
  font-weight: 600;
  line-height: 1.1;
  max-width: 30ch;
}

h1 {
  font-size: 2rem;
}

h2 {
  font-size: 1.8rem;
}

a {
  color: currentColor;
}

:focus {
  outline: 1px dotted currentColor;
  outline-offset: 0.2rem;
}

p,
li,
dl {
  max-width: 70ch;
}

article {
  margin-top: 2.5rem;
  font-size: 1.25rem;
}

main:focus {
  outline: none;
}

@media (min-width: 40em) {
  h1 {
    font-size: 3rem;
  }

  h2 {
    font-size: 2.5rem;
  }
}

These are high-level, global HTML-element styles. We’re setting the basics, mainly, but again, with progressive enhancement in mind, we’re keeping things as simple as possible.

Some key points:

1. We set a max-width on headings, paragraphs, lists elements and description lists using a ch unit. This really helps with readability and a ch unit is equal to the width of a 0 character in your chosen font and size. You can read more about why we do this here.
2. We set :focus styles globally by modifying how the outline looks. This means that any element that can receive focus, such as <a> and <button> will have a consistent focus style. The outline-offset pulls the outline away from the content a bit, which in my opinion, makes it more user-friendly.
3. We remove focus styles from the <main> element because when someone activates the skip link from before, it programatically focuses the <main> because it’s the :target. The focus ring is unnecessary though, because making the <main> focusable, programatically, is purely for making tabbing on the keyboard more predictable for users who want to skip navigation. If we didn’t move focus, they could end up in a situation where hitting the tab key sends them back up the the navigation!

.skip-link {
  display: inline-block;
  padding: 0.7rem 1rem 0.5rem 1rem;
  background: var(--color-light);
  color: var(--color-primary-shade);
  text-decoration: none;
  font-weight: 700;
  text-transform: uppercase;
  position: absolute;
  top: 1rem;
  left: 1rem;
}

.skip-link:hover {
  background: var(--color-dark);
  color: var(--color-light-shade);
}

.skip-link:not(:focus) {
  border: 0;
  clip: rect(0 0 0 0);
  height: auto;
  margin: 0;
  overflow: hidden;
  padding: 0;
  position: absolute;
  width: 1px;
  white-space: nowrap;
}

.wrapper {
  max-width: 65rem;
  margin-left: auto;
  margin-right: auto;
  padding-left: 1.25rem;
  padding-right: 1.25rem;
}

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

.site-head {
  padding: 0.6rem 0;
  background: var(--color-primary);
  border-top: 5px solid var(--color-primary);
  border-bottom: 5px solid var(--color-primary-shade);
  color: var(--color-light);
  line-height: 1.1;
}

.site-head :focus {
  outline-color: var(--color-light);
}

.site-head__inner {
  display: flex;
  flex-wrap: wrap;
  justify-content: space-between;
  align-items: center;
  gap: 0 1rem;
}

.site-head__brand {
  display: block;
  width: 3rem;
}

.navigation ul {
  display: flex;
  flex-wrap: wrap;
  align-items: center;
  gap: 0.3rem 0.8rem;
  padding: 0;
}

.navigation li {
  margin: 0.1rem;
}

.navigation a {
  font-weight: 600;
  text-transform: uppercase;
  text-decoration: none;
  color: currentColor;
}

.navigation a:hover {
  color: var(--color-dark);
}

class BurgerMenu extends HTMLElement {
  constructor() {
    super();

    const self = this;

    this.state = new Proxy(
      {
        status: 'open',
        enabled: false
      },
      {
        set(state, key, value) {
          const oldValue = state[key];

          state[key] = value;
          if (oldValue !== value) {
            self.processStateChange();
          }
          return state;
        }
      }
    );
  }

  get maxWidth() {
    return parseInt(this.getAttribute('max-width') || 9999, 10);
  }

  connectedCallback() {
    this.initialMarkup = this.innerHTML;
    this.render();
  }

  render() {
    this.innerHTML = `
      <div class="burger-menu" data-element="burger-root">
        <button class="burger-menu__trigger" data-element="burger-menu-trigger" type="button" aria-label="Open menu">
          <span class="burger-menu__bar" aria-hidden="true"></span>
        </button>
        <div class="burger-menu__panel" data-element="burger-menu-panel">
          ${this.initialMarkup} 
        </div>
      </div>
    `;

    this.postRender();
  }
}

if ('customElements' in window) {
  customElements.define('burger-menu', BurgerMenu);
}

export default BurgerMenu;

postRender() {
  this.trigger = this.querySelector('[data-element="burger-menu-trigger"]');
  this.panel = this.querySelector('[data-element="burger-menu-panel"]');
  this.root = this.querySelector('[data-element="burger-root"]');
  this.focusableElements = getFocusableElements(this);

  if (this.trigger && this.panel) {
    this.toggle();

    this.trigger.addEventListener('click', evt => {
      evt.preventDefault();

      this.toggle();
    });

    document.addEventListener('focusin', () => {
      if (!this.contains(document.activeElement)) {
        this.toggle('closed');
      }
    });

    return;
  }

  this.innerHTML = this.initialMarkup;
}

toggle(forcedStatus) {
  if (forcedStatus) {
    if (this.state.status === forcedStatus) {
      return;
    }

    this.state.status = forcedStatus;
  } else {
    this.state.status = this.state.status === 'closed' ? 'open' : 'closed';
  }
}

processStateChange() {
  this.root.setAttribute('status', this.state.status);
  this.root.setAttribute('enabled', this.state.enabled ? 'true' : 'false');

  this.manageFocus();

  switch (this.state.status) {
    case 'closed':
      this.trigger.setAttribute('aria-expanded', 'false');
      this.trigger.setAttribute('aria-label', 'Open menu');
      break;
    case 'open':
    case 'initial':
      this.trigger.setAttribute('aria-expanded', 'true');
      this.trigger.setAttribute('aria-label', 'Close menu');
      break;
  }
}

manageFocus() {
  if (!this.state.enabled) {
    this.focusableElements.forEach(element => element.removeAttribute('tabindex'));
    return;
  }

  switch (this.state.status) {
    case 'open':
      this.focusableElements.forEach(element => element.removeAttribute('tabindex'));
      break;
    case 'closed':
      [...this.focusableElements]
        .filter(
          element => element.getAttribute('data-element') !== 'burger-menu-trigger'
        )
        .forEach(element => element.setAttribute('tabindex', '-1'));
      break;
  }
}

const observer = new ResizeObserver(observedItems => {
  const {contentRect} = observedItems[0];
  this.state.enabled = contentRect.width <= this.maxWidth;
});

// We want to watch the parent like a hawk
observer.observe(this.parentNode);

import getFocusableElements from './get-focusable-elements.js';

/**
 * Returns back a NodeList of focusable elements
 * that exist within the passed parnt HTMLElement
 *
 * @param {HTMLElement} parent HTML element
 * @returns {NodeList} The focusable elements that we can find
 */
export default parent => {
  if (!parent) {
    console.warn('You need to pass a parent HTMLElement');
    return [];
  }

  return parent.querySelectorAll(
    'button:not([disabled]), [href], input:not([disabled]), select:not([disabled]), textarea:not([disabled]), [tabindex]:not([tabindex="-1"]):not([disabled]), details:not([disabled]), summary:not(:disabled)'
  );
};

.burger-menu__trigger {
  display: none;
}

.burger-menu__bar,
.burger-menu__bar::before,
.burger-menu__bar::after {
  display: block;
  width: 24px;
  height: 3px;
  background: var(--color-light);
  border: 1px solid var(--color-light);
  position: absolute;
  border-radius: 3px;
  left: 50%;
  margin-left: -12px;
  transition: transform 350ms ease-in-out;
}

.burger-menu__bar {
  top: 50%;
  transform: translateY(-50%);
}

.burger-menu__bar::before,
.burger-menu__bar::after {
  content: '';
}

.burger-menu__bar::before {
  top: -8px;
}

.burger-menu__bar::after {
  bottom: -8px;
}

.burger-menu[enabled='true'] .burger-menu__trigger {
  display: block;
  width: 2rem;
  height: 2rem; /* Nice big tap target */
  position: relative;
  z-index: 1;
  background: transparent;
  border: none;
  cursor: pointer;
}

.burger-menu[enabled='true'] .burger-menu__panel {
  position: absolute;
  top: 0;
  left: 0;
  padding: 5rem 1.5rem 2rem 1.5rem;
  width: 100%;
  height: 100%;
  visibility: hidden;
  opacity: 0;
  background: var(--color-primary-shade);
  overflow-y: auto;
  -webkit-overflow-scrolling: touch;
}

.burger-menu[enabled='true'] .navigation ul {
  display: block;
}

.burger-menu[enabled='true'] .navigation ul > * + * {
  margin-top: 2rem;
}

.burger-menu[enabled='true'] .navigation li {
  font-size: 1.5rem;
}

.burger-menu[enabled='true'][status='open'] .burger-menu__panel {
  visibility: visible;
  opacity: 1;
  transition: opacity 400ms ease;
}

.burger-menu[enabled='true'][status='closed'] .burger-menu__panel > * {
  opacity: 0;
  transform: translateY(5rem);
}

.burger-menu[enabled='true'][status='open'] .burger-menu__panel > * {
  transform: translateY(0);
  opacity: 1;
  transition: transform 500ms cubic-bezier(0.17, 0.67, 0, 0.87) 700ms, opacity 500ms ease
      800ms;
}

.burger-menu[enabled='true'][status='open'] .burger-menu__bar::before {
  top: 0;
  transform: rotate(45deg);
}

.burger-menu[enabled='true'][status='open'] .burger-menu__bar::after {
  top: 0;
  transform: rotate(-45deg);
}

.burger-menu[enabled='true'][status='open'] .burger-menu__bar {
  background: transparent;
  border-color: transparent;
  transform: rotate(180deg);
}

You can use AVIF and WebP formats right now and still support old browsers by using a <picture> element like this:

<picture>
  <source type="image/avif" srcset="https://assets.codepen.io/174183/hankchizlbork.avif" />
  <source type="image/webp" srcset="https://assets.codepen.io/174183/hankchizlbork.webp" />
  <img src="https://assets.codepen.io/174183/hankchizlbork.jpg" alt="Me looking like a complete bork" width="1500 " height="1585" />
</picture>

This is a great example of how progressive enhancement can help you to provide the best experience for anyone that visits your site, regardless of how they access it.

This snippet works in every browser because HTML is an incredibly forgiving and intelligent programming language. If a browser doesn’t support a <picture> element, the browser will ignore it and render the <img> as usual. If a browser does support <picture>, but doesn’t for example, support AVIF images: it will pick the format it can understand, including the default jpeg. Handy!

Go ahead and try the following demo is various different browsers 👇