But we can do something like this with no text duplication whatsoever… The trick here is to put the text fill, the text stroke and the progress area each on one RGB channel. In my demo, the text fill uses the blue channel, the text stroke uses the red channel and the progress area uses the green channel.

I’m old enough to remember this pattern playing out with CSS itself: huge pushback when it was introduced in the mid 90s. It was clunky for layout and had terrible browser support — “why fix something that wasn’t broken?” folks cried… The majority resistance lasted until the mid '00s when it went from “this will never work” to “this was clearly the solution all along” almost overnight.

The bottom line is, web components reduce the number of use cases where we need to reach for a framework, but complex large applications will likely still benefit from one.

Back in 2020, Firefox released a prototype for doing ‘masonry’ layout in CSS. Now all the browsers are eager to ship something, but there’s a hot debate about the best syntax to use.

To create a more harmonious logo strip, we can adjust the height of each logo based on its aspect ratio. If a logo is significantly wider than it is tall (aspect ratio greater than one), we'll reduce its height accordingly. The wider the logo, the smaller its allowed height. This way, all logos maintain a visual balance.

For a few minutes, I felt like Indiana Jones staring at the holy grail. 230ms of savings from some CSS selector changes. This felt significant. And yet, the niggling phrase of “CSS selector efficiency is not something to worry about in 2024” kept ringing through my head.