I’ve happily used (and wrote about) CSS and @media nesting for about six years now. Primarily through PostCSS, where it gets compiled away, and directly for the styling in Polypane where I know the exact browser engine. I have also had to implement my own parser for it in early 2023, when I implemented support for it in Polypane’s Elements panel (one of the first browsers that supported it).

So I’m far from a stranger to the workings of native CSS Nesting.

Progressive enhancement in context #

Progressive enhancement is a way of setting up your code such that you provide a well-supported basis that works across all the browsers you target, and then you add functionality when support is better.

In the context of accessibility, we often say that you should build the accessible variant as the default (for example, no animations) and only when the user indicates they don’t need the accessible variant (for example, no-preference for reduced motion) then you add features on top of that accessible default (by adding animations).

This makes the accessible version the one that gets used when anything goes wrong, and if everything goes right and people want a little extra, they can get that without hampering the experience for others.

The issues that brings #

Unfortunately in ‘traditional’ CSS this often ends up with having styles of an element living in two different places (one inside and one outside a media query).

.my-element {
  width: min(1000px, -1rem + 100vw);
  max-height: calc(-2rem + 100svh);
  /* ...and a bunch more */
  scale: 0.5;
  opacity: 0;
}

/* potentially lots of other CSS until 
   you get to the "accessibility block" */

@media (prefers-reduced-motion: no-preference) {
  .my-element {
    transition: 0.5s ease-in-out all;
    /* maybe some additional styling to make this work well */
  }
}

That causes quite a few potential complications, especially for the long-term maintenance of code:

• Accidentally editing the wrong ruleset
• Not updating both when needed
• Forgetting to remove one of the rulesets when a component gets removed
• Selector ordering issues causing the wrong styles to apply

Because there is nothing that keeps track of the inherent link between the two rulesets, it’s one of those “great in theory, slightly more complicated in practice” situations.

Progressive enhancement with CSS Nesting #

A couple of days ago I nested an @media query, something I must’ve done hundreds of times over the course of all those years. But in this case, here’s what I did:

.my-element {
  width: min(1000px, -1rem + 100vw);
  max-height: calc(-2rem + 100svh);
  /* ...and a bunch more */
  scale: 0.5;
  opacity: 0;
  
  @media (prefers-reduced-motion: no-preference) {
    transition: 0.5s ease-in-out all;
  }
  
  &:open {
    opacity: 1;
    scale: 1;
  }
}

Nothing out of the ordinary, but when looking at the ruleset I realized that this is now a fully self-contained, progressively enhanced CSS style!

The transition only gets applied for users with no-preference for motion. The logic for the progressive enhancement is co-located with the rest of the styles, and should I ever remove this component, I won’t need to hunt down a second place where I use the same selector.

Obvious? #

After writing it down it seemed really obvious, but that wasn’t the case for me before I had written it, and neither was it to folks on Bluesky, who seemed to enjoy my short post on it. So I figured it was worth a quick article on my blog as well.

If it was obvious to you and you had been doing it for a long time: that’s great! If this made you go “huh, yeah” then I hope it makes your progressive enhancements a little bit easier going forward.

All I know about capital-s Software Development, I learned as I went from various sources. The result is that I now carry with me a number of maxims, sayings and rules-of-thumb that help me make development choices while I’m building something. Late last year I finally sat down and wrote about these principles over on Piccalilli:

Programming principles for front-end developers

The article really resonated with people. Not only was it the most read article on Piccalilli in 2025 (despite being released at the end of November), I also got numerous messages from people about how this helped them think about their code in new ways. It was difficult to find the right way to articulate my approach in a way that made sense (The article idea was on my backlog for well over a year) and didn’t just present the end result but instead showed how to think about code in a way that works for you.

I’m very excited to share that I will be presenting this topic as various conferences throughout the year. The first will be at Confoo in Montreal, at the end of February. Later this year I’ll be presenting it at a conference in Europe too, but that hasn’t been announced yet.

I’d love to give this talk at more conferences and meetups. If you checked out the article and think it would be a good fit for your audience, please reach out!

My 2025 Pick: text-wrap: balance;

I can’t remember the last time a new CSS property was introduced that I could just add to any stylesheet new and old. It’s a little magic one liner that makes your titles much nicer with zero downsides. Add it to your css resets!

There have been many awesome new CSS features in the past 12 months, like view transitions, scroll driven animations, anchor positioning, @starting-style, field-sizing, animating to auto and ::details-content to name just a few.

They’re great, but most of those aren’t fully cross-browser yet and they are all fairly specific features around animation or positioning for where there isn’t really a good fallback in other browsers (you’d have to feature detect and use a polyfill or equivalent javascript).

However text-wrap: balance (and its buddy text-wrap: pretty) is this delightful single line of CSS that makes your site a tiny bit better, and support is great:

Text-wrap: balance will make sure that the words are properly balanced across lines, avoiding the situation where the last line will have one or two words.

No one will notice if it’s missing, but you can just add it to all your headings in your CSS reset and they will look slightly better:

h1,
h2,
h3,
h4,
h5,
h6 {
  text-wrap: balance
}

Or, in some future version of your browser:

:heading {
  text-wrap: balance
}

Having new CSS that is so widely useful and applicable, that you can add without any negative consequences for non-supporting browsers is pretty rare (and pretty exciting!) and that’s why it’s my pick of the year.

Go check out the State of CSS survey to read everyone else’s picks!

ps. I completely nicked this post idea from Ana, who wrote about her pick: My pick of the year for the State of CSS Survey by Ana Rodrigues

Thanks Frederick for having me on, and for the great conversation (on and off camera!)

Visit Software Engineering Daily for the show notes and transcript.

Thanks Joel for asking me to be on the podcast, and thanks Josh for a wonderful conversation!

Why did you start blogging in the first place? #

This is what I wrote back in December of 2006 (19 years 💀) in the first post:

I’m gonna use this online space to talk about CSS, Design, the web in general, GTD, and maybe some javascript and php once I become a bit more familiar with it (That is, once I’ve crossed the border between “I think this should work” to “damnit, this should work!”)

Which.. yeah, tracks pretty well. I particularly like that the “GTD” category has existed since 2006 and has zero posts.

I also wrote this:

Short story: I make websites, I like to be involved in the online community, and (perhaps unfortunately) I think I could add something to it.

Which I’d like to think I also managed decently.

As with most people’s blogs, mine is also terribly neglected. Reading back on that makes me pretty happy with the past 19 years though.

What platform are you using to manage your blog and why did you choose it? Have you blogged on other platforms before #

I used WordPress and have since 2006. It’s nicely full-featured with RSS and categories and tags and widgets and I don’t have to think about anything. It has also survived all WordPress updates since I first put it up on WordPress 2.0.

I’ve played around with a bunch of blogging systems for other projects but I’m pretty lazy when it comes to platforms so I’ve never felt a strong need to move away from WordPress.

That said, if I ever, ever get around to doing a proper redesign, I’d probably move to Astro and have a static site that lets me write markdown directly, doesn’t use PHP or a database and is generally just easier to fiddle with.

How do you write your posts? For example, in a local editing tool, or in a panel/dashboard that’s part of your blog? #

I’m pretty low tech. I usually write in a plain text editor, either gedit or, if I already have it open, VS code. Most often just directly as HTML(-ish: WordPress makes the paragraphs for me, but headings, links etc I do manually) but sometimes it’s markdown if I feel like it, and then I compile the HTML from that.

I use the classic editor in WordPress so I just paste it in when I’m done, and check the preview to make sure everything works well.

This post is a gedit post.

When do you feel most inspired to write? #

Usually I find out about some technical thing that I think People Should Know, so I write about it. Nowadays, those kind of posts tend to go on the Polypane Blog because, well, marketing, but also because it’s much easier for me to add inline widgets, get code highlighting etc.

This blog nowadays is more about updates on stuff I do elsewhere (like podcasts), which I write about after they happened.

Do you publish immediately after writing, or do you let it simmer a bit as a draft #

Almost always immediately after writing it. Usually I just need to get something out and there’s no point in refining it unless it’s a release announcement. If it’s technical, I just write it up, check it for spelling and grammar mistakes and then ship it.

What are you generally interested in writing about? #

Technical stuff I’m working on right now. That’s almost always HTML/CSS/JS, with some Electron and A11y thrown in.

What’s your favourite post on your blog? #

Back in the dayâ„¢ my series on CSS Positioning was one of my first long, extensive explorations of a topic and it ended up being used in university courses, mentioned in books etc. Still proud of that.

More recently (…by which I mean 4 years ago) I wrote an article titled You want overflow: auto, not overflow: scroll. My idea was to just get to point instantly and then when people want to read more they can, or they can just go “oh right” and apply it.

Since then, the “you want X, not Y” format keeps popping up, which makes me happy. Like on CSS Tricks or Scroll-Driven Animations: You want overflow: clip, not overflow: hidden by Bramus.

To me it’s a very pleasing way to write titles, like anti-clickbait.

Who are you writing for? #

Ideally, “me” from a day or so ago when I didn’t know The Thing. Or me from a day ago that used to know The Thing, but forgot, and now needed a reminder/refresher to know The Thing again.

And then I imagine there’s many other people like me that also benefit from The Thing.

Any future plans for your blog? Maybe a redesign, a move to another platform, or adding a new feature? #

The current design is from 2016 and pretty long in the tooth. I’d like to do a new design with a homepage less focused on just the articles since I do so many other things elsewhere now. And then technically I’d like to use Astro. But updating this blog is so far down the list of priorities that it’s even quite far down the “things I would be doing if I had infinite time” list.

Next! #

Should they accept the challenge, I tag Adam, Stefan, Bramus and Manuel!

Check it out:

Or watch the video:

Thanks Salma and and Andreas for having me on, I had a lot of fun!

Starting off right: Where autofocus shines on HTMHell

the autofocus attribute is one of my favorite ways to improve very specific interactions on HTML pages, and in the article I explain what those are, where to add it and where to definitely not it as well.

CSS box-decoration-break on 12 Days of Web

box-decoration-break is a CSS property that lets you decide what the decorations of a box should do if that box is broken across multiple lines. If that sentences reads like gibberish to you, check out the article!

What determines the accessible name of an element? on Fronteers

The accessible name of an element is how the browser passes an element to assistive technologies like screen readers or braille displays, and forms the way someone who cannot (fully) see a site consumes the content.

This article was originally written in Dutch, so if you prefer that you can read it here: Wat bepaalt de toegankelijke naam van een element?.

All the best for 2025!

And here it is among friends:

Looks pretty good right?

Outline version #

I can’t wait to see this replace the “CSS3” badge across the web and wanted to update the icon for the Live CSS panel in Polypane too.

All the icons in Polypane are from the Tabler icons icon set which are all in “outline style” on a 24 by 24px grid, so last Friday I spent a few hours creating a 24 by 24 pixel outline version of the logo, shown here at 24px, 48px, 128px and 256px.

The official repo isn’t accepting variants but I’ve proposed it for inclusion in Tabler icons here: CSS icon #1266 so if you’d like to see it added make sure to leave a comment or Emoji response there.

Grab it here #

While it hopefully will be added to an icon set soon, you can also just grab the icon from this page, for example by right-clicking them in Polypane and selecting “Copy SVG as code”.

This is useful because a lot of tools will happily take “Chrome >= 128” as a configuration option for e.g. transpilation and minification, but it’s pretty annoying to look up the chromium version of your electron release each time.

A lot of tools use browserslist for this browser-to-support-table mapping and thanks to electron-to-chromium you can write Electron >= 32 and that will be supported in everything Browserslist uses: Babel-preset-env, autoprefixer, stylelint and a bunch more. All in all, `electron-to-chromium is currently downloaded almost 47 million times each week.

The automation setup #

Because Electron releases relatively frequently, the creator of Browserslist suggested that I automate the entire process to avoid a ton of manual work. I’m glad he did! For the past 6 years that automation has been smoothly humming along on my DigitalOcean server. Here’s how it works:

• Every 15 minutes, a cron job kicks in.
• It updates the `electron-releases` dependency and runs my automated-update.js script.
• That runs the build and test scripts.
• If those fail I get sent an e-mail with the problem.
• Otherwise with a new version of Electron the build step has generated new files and so `git status –porcelain` returns text.
• That means we need to publish a new version, so the script adds the new files, creates a new patch version and pushes the update and the new tagged release to GitHub.
• As a last step, it releases the version to NPM and I get a confirmation email.

2026 update #

With NPM no longer allowing automated publishing I have moved the publishing step to GitHub Actions. My server is still responsible for checking for updated and keeping the git repository humming along, but going from git to NPM is handled by GH actions.

Benefits #

This automation has made my life so much easier:

• Updates go live super fast – usually within minutes of an Electron release.
• The package is always current without me having to babysit it.
• Automated tests mean fewer chances for bugs to sneak in and there’s a number of fail saves.
• I can focus on other stuff instead of manual updates.

Other updates #

Other than keeping up to date with Electron I haven’t needed to do a whole lot of maintenance on the package but last month I configured it to no longer include nightly versions in the released package. That brought the package size down from 299kB to 144kB.

With 47 million downloads per week, that’s almost 7TB of data saved every week!

A shout-out to DigitalOcean #

electron-to-chromium has been sponsored by DigitalOcean’s open source sponsoring for a couple of years now, which is really great. That gets me very flexible infrastructure with DigitalOcean footing the bill. Thank you DO!

That’s pretty much it! It’s not groundbreaking stuff, but it’s a fun bit of automation that keeps things running smoothly. If you’re maintaining a package that needs frequent updates, you might want to try something similar!