#268: Just in Time CSS, the EyeDropper API, and the problem with iOS

[Robin]: One of the criticisms thrown at writing Atomic CSS is that it generates a ton of classes that your users don’t need. Let’s say you want to add some padding to the top of an element, like this:

<div class="pt-20"></div>

This is all fine and dandy—and it sure is neat that I don’t have to write a custom CSS class just to add padding and all—but with a lot of frameworks you’d have all the classes for up, down, left, and right padding in your CSS like this:

.pr-20 { padding-right: 20px; }
.pt-20 { padding-top: 20px; }
.pb-20 { padding-bottom: 20px; }
.pl-20 { padding-left: 20px; } 

Now let’s say we don’t use the other three classes in our codebase, well, we’re now potentially sending a ton of code down the wire that the user never needs. Multiply that by all the classes in these sorts of frameworks and that could become a genuine performance concern.

This is where tools such as acss.io comes in. As Chris wrote about the other day, with acss.io you can write some HTML…

<div class="C(#333) P(20px)">

…and these declarations will then create CSS like this under the hood for you:

.C\(\#333\) {
  color: #333;
.P\(20px\) {
  padding: 20px;

(Those selectors only look weird because you have to escape certain characters in CSS selectors).

It sounds like folks are calling this “Just in Time” CSS and both the idea and the name makes a whole bunch of sense to me. For example, Assembler CSS leans into this hard:

And Tailwind supports it now, too:

My hunch is that this “Just in Time” CSS stuff is how folks will primarily use Atomic CSS in the future—which is good for us as developers and our users. The alternative, if you’re using utility classes / atomic CSS, is to purge the unused stuff. Gotta do one or the other to avoid sending far too much CSS and doing exactly the opposite of what you’re trying to do (ship more CSS instead of less).


The EyeDropper API just landed in Chrome Canary which lets you select a color from any part of your screen. Thomas Steiner showed how it works in this little example:

Riffing off all this, Andrew Walpole then made this particularly great petite-vue demo in CodePen where you can select a color from the screen and it’ll automatically add those colors to the :root in CSS to create a list of color variables for you to use. Smart!


Stefan Judis wrote about the problem with media queries today:

[…] if you’re using CSS custom properties (CSS variables) and wanted to reference them in a media query, you probably discovered that you can’t use custom properties in this context. CSS custom properties weren’t designed for that use case. Bummer!

He then shows this CSS example:

:root {
  --width: 20em;

/* that doesn't work :/ */
@media (min-width: var(--width)) {

I’m annoyed that I never thought to even try this! Of course, we should be able to create a media query with a variable we’ve defined elsewhere. Well, thankfully that seems to already be a part of the Media Queries Level 5 spec and they’d look something like this:

@custom-media --narrow-window (max-width: 30em);

@media (--narrow-window) {
  /* narrow window styles */

First, you define your variable and then you can use it throughout your CSS. I love this! Sadly, though, it doesn’t seem to have any traction from browsers yet, so this is me sulkily protesting and demanding that we get custom media queries soon please and thank you.

(I’m sure there’s a bunch of very reasonable and complex technical reasons why this hasn’t been done yet. But still. Boo! Go star the feature in in Chrome Bug to signal interest.)


Niels Leenheer wrote this great piece called Chrome is the new Safari. And so are Edge and Firefox. The problem? Well, you can download Chrome or Edge or Opera on iOS but under the hood all of them are using the same rendering engine as Safari. With all the hundreds of millions of iPhones in the world there always has been and—for now—always will be just one browser that we can use.

How does this hurt the web though? Niels explains:

So that new web standard you would like to use? Not until Apple implements it in WebKit. Is there a bug that causes problems? Wait until Apple fixes it and releases a new version of iOS.

And there lies the problem.

As Niels explains, this forces the web to move only as fast as Apple will allow it because iOS is such an important platform for us developers to support. And this is also a problem for us because we have to keep a long, running list of problems with Safari.

I was on the fence about this for a long time, as I felt like there were a ton of pseudo-conspiracies about Apple’s motivations here. (They are evil, they want to kill the web and replace it with the App Store, yada yada.) But now, the longer I think about it, the clearer it becomes that this is a big problem for the web regardless of Apple’s intentions here.

Ultimately, I agree with Niels’s conclusion when he says…

There can only be one proper solution: Apple needs to open up their App Store to browsers with other rendering engines. Scrap rule 2.5.6 and allow other browsers on iOS and let them genuinely compete. Even though Apple has been forced to compromise on some App Store rules, I have little hope for this to happen.

And this is why I think market regulators need to look into this. Apple claims the web is a proper alternative to the App Store, so regulators should take them up on that claim and ensure it becomes true.

As web developers, and as users of the web, we need more options, more features, more choice. Alex Russell goes even further on the situation as its implications.


Here’s a cool thing that Kassandra Sanch made with CSS: an old-school computer monitor that looks so good I had to double-take when I realized this wasn’t just a photograph…

If you’re looking for inspiration this week, then Kass’s whole CodePen account is worth checking out, too. Like this one Pen I saw earlier in the week that made me viscerally upset with what I call “extreme CSS and SVG jealousy.” Seriously though, take a look at this thing:

Incredible stuff.

A Free .design Domain Name for Your Website or Portfolio!

.design is the premier domain extension for all designers, from web and UX design, to interior design, to other design disciplines. Using a .design domain in your URL will bring your personal branding to a whole new level.

Netlify’s Deploy Previews

Gather feedback with images and video right from the browser. No coding, no setup, and preview links include the handy Netlify Drawer widget that enables reviewers to take screenshots, create screen recordings, submit issues, add comments, and make annotations.

[Chris]: This is just so good:


The fact that a reference site like this isn’t a part of our day-to-day work is the strength of the web.