ericportis.com — Posts

Monochrome Summer

2026-02-04T00:00:00-08:00

When do you have to repeat redundant sizes attributes within a <picture>?

2025-08-15T00:00:00-07:00

TL;DR

Almost always, but that might be changing.

Okay, so—

Let’s say you’ve got a <picture> element that includes multiple candidate sources. If you’re doing art direction, those sources are probably each going to be laid out differently. This means they’ll each need their own sizes attribute.

<picture>
  <!-- landscape image over text -->
  <source
    media="(min-width: 600px)"
    srcset="landscape-lg.jpg 1920w, landscape-sm.jpg 960w"
    sizes="(max-width: 960px) 960px, 90vw"
  >
  <!-- square crop next to text -->
  <img
    srcset="square-lg.jpg 480w, square-sm.jpg 240w"
    sizes="25vw"
  >
</picture>

This pattern was generalized into a universal requirement: any time an element (<img> or <source>) had a srcset that included w descriptors, it also needed its own sizes.

But for media-switching that isn’t related to layout changes (e.g., responding to prefers-contrast), or for the type-switching use case, this requirement just leads to repetition.

<picture>
  <source
    type="image/jxl"
    srcset="lg.jxl 1000w, sm.jxl 500w"
    sizes="(max-width: 960px) 768px, 80vw"
  >
  <img
    srcset="lg.jpg 1000w, sm.jpg 500w"
    sizes="(max-width: 960px) 768px, 80vw"
  >
</picture>

When you’re using sizes=auto, it doesn’t even make sense in the art direction case, because the browser is just going to figure the sizes out on its own.

<picture>
  <!-- landscape image over text -->
  <source
    media="(min-width: 600px)"
    srcset="landscape-lg.jpg 1920w, landscape-sm.jpg 960w"
    sizes="auto"
  >
  <!-- square crop next to text -->
  <img
    loading="lazy"
    width="480"
    height="480"
    srcset="square-lg.jpg 480w, square-sm.jpg 240w"
    sizes="auto"
  >
</picture>

Thankfully, sizes=auto has been special-cased! If the <img>’s sizes value is auto, you don’t need to duplicate it across your <source>s. The previous example works the same in Chrome with or without sizes on the <source>. Yay!

Unfortunately,sizes=auto and its special-cased handling aren’t supported everywhere yet. So in this example:

<picture>
  <source
    type="image/avif"
    srcset="large.avif 2000w, small.avif 1000w"
  >
  <img
    loading="lazy"
    width="2000"
    height="2000"
    srcset="large.jpg 2000w, small.jpg 1000w"
    sizes="auto, 50vw"
  >
</picture>

Safari and Firefox will always use the last-resort 100vw fallback as the sizes value, after selecting the <source type="image/avif">. Even though we put a better fallback length in our <img sizes>, just for them!

Boo! This caught me out recently, and so here I am, blogging about it.

I think two things should happen:

Safari and Firefox should implement sizes=auto, post haste.
The spec should be updated so that the <img>’s sizes is used as a fallback, if the selected <source> doesn’t have a sizes of its own. This isn’t only useful in the sizes=auto case, it’s also useful for type-switching, and in any other situation where the sizes values within a <picture> would otherwise repeat.

I’m not the first person to have that idea. Jake Archibald had it four years ago. After some discussion, a handful of relevant parties seemed to agree. Jake even started a PR. So… let’s do it!

Update!

Looks like Jake is working on the PR again. Yay!

I finished a 50K

2025-08-12T00:00:00-07:00

In June I ran the Orcas Island 50K. When I finished the race I also finished a 2+ year journey, which I’d started, in part, because I was staring down 40-years-old and had feelings about aging and my body.

I signed up for the 2024 edition of the race way back in 2023. I started training early. Then, I sprained my ankle. I rested, recovered – and sprained it again! I’d thought running uphill was going to be the hard part of all of this, but once I learned to slow down and listen to my heart – it was the downs that got me.

Then I broke my pinky toe (on a donut run¹).

That series of injuries left me quite behind on my training. I tried to “catch up”, acquired a predictable case of runner’s knee, turned 40, and spent the 2024 race sitting behind a desk, volunteering:

Photo by Somer Kreisman

Try, fail, try again. Here I am in 2025:

Photo by Somer Kreisman

Feelings! I have feelings about aging and my body! And how do we process feelings? With charts.

Training

Here’s all of my long runs (the race is the last set of bars, on the right):

Someone recently asked me if they should run a marathon. I replied: I don’t know, maybe not? The training takes so much time. Time alone. I say I want a life rich with community and yet I spent seven months waving goodbye to my wife on weekend mornings, driving to the woods, and putting one foot in front of the other for hours (before spending the rest of the weekend wrecked).

So, if you like and/or value other people, maybe don’t pursue a solo endurance sport goal.

On the other hand! It is rewarding to work steadily at something, for a long time, and watch the impossible slowly become possible. That’s in these charts. They go up and to the right.

(Mostly.)

Runner’s knee bit me again in week 17; I spent week 18 icing and running less; when that didn’t fix it I spent week 19 not running at all. I instituted a regular routine of exotic squats. I built back distance and time, then re-introduced climbs and (scariest of all) descents. It went well. I fixed it!

Encountering and solving problems like that changed how I think about running, what I think it’s for. When I was younger running felt like a test of character. Success was about, alternately:

finding flow and getting in “the zone” or,
digging deep and pushing through.

Contrary to this, Matt Webb recently described training for a marathon as a kind of engineering challenge: learning to understand your body as a system; using that understanding to solve problems; new problems teach you new things about the system. That’s how it went with my knee. That’s how a bunch of things went. Patient research and careful trial-and-error hits different than a Nike commercial, but for a 39 40 41-year old, who has feelings about aging and his body? It hits deeper. It is thrilling.

Race Day

So after a more-or-less successful seven-month training cycle, my longest long run had been for just over 80% of the both the 50K’s distance and elevation gain. On the final descent of that longest training run, I contemplated what it would be like to run for six more miles and climb/descend another twelve hundred feet. The training plans say you can do it. I wasn’t so sure.

I did it.

During those last six miles of the race, here’s what I was thinking:

I am going to finish!
I need to slow down.

I did not feel like I was “finishing strong.”

One fun (?) thing about a race though, is that you get to compare yourself to other people. A lot of other people needed to slow down, too.

Here’s a box plot of the distribution of racers’ paces over the four officially-timed segments, with the median pace marked by a black line and my pace marked in blue:

Thoughts:

Everybody slowed down during the second segment, due to the steep climb up Mt Constitution. I felt strong going up the mountain and it’s cool to see that in the data!²
Most people slowed down during the last segment. I don’t think this was because of the terrain – I think it was because of exhaustion. It’s nice to know that’s normal.

The distributions are interesting; there were few-enough racers that a chart of everybody’s paces through the four segments is more-or-less legible, too:

I’ll close with the best piece of endurance-running advice I’ve heard: “If you feel bad, eat something. If you feel good, slow down.” Advice for life.

We were camping with friends, about a mile from our car. I woke up early to hike out and drive into town to buy the best donuts in the world, which are only available for a few hours on Saturday mornings. After hiking, driving, waiting in line, buying donuts, and driving/hiking back to camp, I held the best donuts in the world aloft and made a triumphant entrance, exclaiming, “donuts!—OW!” as I stubbed my toe on a root. ↩︎
All credit to my wife. Not only did she materially and emotionally support me along every step of this journey – encouraging me to commit after I half-heartedly floated the idea of signing up, clearing schedules and picking up slack ensuring I had time to train, cheering me on as my training progressed, and listening to and advising me when it didn’t – she surprised me at the base of the race’s biggest climb with leaping cheers, a high five, and a kiss. LFG.

I couldn’t and wouldn’t have done this race without her. Thank you. ↩︎

A House Full of Wizard-Shaped Holes

2025-02-28T00:00:00-08:00

We adopted Wizard on March 12th, 2016 and we said goodbye to him on January 13th, 2025.

2016 (Gotcha Day)

2016

2025

They said he was six years old when we got him, but I don’t believe it. He weighed about 75 lbs and he taught us a lot about love. He was our first dog, but we were not his first people. We all figured it out, eventually.

It became a thing that old men, passing us in public, would express a particular affinity for Wizard. “That’s a good-lookin’ dog!” they’d say. I told kids he was half-dog, half-tiger.

Portrait by Evan Douglas (aka Wild Masterpieces)

Portrait by Matt Cummings

Family portrait by Hannah B. (aka fuzzzbrain)

KidPix portrait by Trish Reynolds

Sock portrait by unknown sock artist

He hated getting wet and he loved the sun. All dogs seem pretty food-motivated but he was, like, very food-motivated? The first time we gave him turkey he started humping. He was curious, coy, sleepy, and sweet. He’d kerchuck-kerplunk down the stairs forty-five minutes after I got up, find me in the kitchen, and lean into me with his warmth and his weight. Good morning! More than anything, he hated being alone. So we made sure he wasn’t, for nine years.

We loved him so much, and he loved us right back. It was all so automatic.

And now he’s gone and our house is too big and lonely. It’s full of holes: where his beds used to be, where his stuff used to be, where he used to be. Holes in our hearts.

Buddy. Wizzy. Boo! Wizard. Thank you.

Fixing my Sony WH-1000XM3s by sticking some sponge in there

2024-09-04T00:00:00-07:00

Five years ago, I bought a pair of Sony WH-1000XM3s. They’re great!

Three years ago, they stopped turning on consistently. The problem got worse and worse. I Googled. I Reddit-ed. I YouTube’d. I – carefully, gently – learned how to open them up. I developed a series of incorrect hypotheses about possible problems and solutions, the funniest of which involved tapping a series of internal solder points with the tip of my screwdriver in order to, I don’t know, release some excess charge or something? It seemed to work! (For a while). When I began flying again (remember?) I packed a little screwdriver in my carry-on, in case the ol’ headphones needed a good solder-tapping during a flight. TSA only caught it once.

All of my “solutions” worked just well enough to string me along. But steadily, inevitably, they lost effectiveness. I almost gave up! Until I stuck some sponge in there.

These things have taken a dozen drops from head-height onto hard floors. Perhaps the sponge is applying pressure to some impact-loosened contact, allowing the electrons to flow? I don’t know.

What I do know is: now, my headphones turn on every time, for months at a time, and when they do occasionally start to fade on me (once a year or so?), I stick some more sponge in there, and they are revived.

The last time I performed this “repair,” I remembered to take some pictures.

First, we gather our materials.

We’re going to start by going in through the front. Pry the ear pad off of the left headphone. I remember this being difficult and nerve-wracking the first time I did it, but I must have worn the plastic bits down by doing it so often over the years – now it’s easy.

Remove foam.

Here’s what the inside looks like. We’re gonna remove the four circled screws.

I asked my parents for this set of Wiha precision screwdrivers for my ~17th birthday. I distinctly remember my dad not-quite-derisively asking me what I thought I was going to use them for. Well!

Now, we open up the back. Carefully flip the headphones over and carefully lift the back shell off, using the ribbon cable that runs between outer/right side the shell and the main body of the headphone as a hinge.

Stick some sponge in there!

Reassemble. All better!

Now that I’m Redditing this again, it looks like other folks have also discovered this solution. Cool! All remaining WH-1000XM3 owners should know! Maybe try sticking some sponge in there? Worked for me!

Endless Shrimp Jesus

2024-06-03T00:00:00-07:00

This post is about a cynical analogy for understanding the generative AI boom. The analogy is not perfect! It minimizes the (real, even to skeptics) present utility of generative AI, and completely discounts the technology’s hypothesized future benefits. But, as I try to process what in the heck is happening in tech right now, this analogy has been helpful for me. Maybe it’ll help you, too.

Red Lobster just went bankrupt. A particularly funny (if ultimately small) part of Red Lobster’s financial decline was that, over the past year, the company lost tens of millions of dollars selling Endless Shrimp.

The Endless Shrimp promotion, which let patrons exchange $20 for (theoretically) infinite shrimp, has since come under scrutiny. Why would a failing business try to sell as many money-losing shrimp as possible? Perhaps as a loss leader, to get folks in the door, so that Red Lobster could try to make money off of them in other ways? That’s the boring explanation.

Here’s the exciting one: Endless Shrimp was launched last June because Red Lobster was, at that point, owned by its shrimp supplier (Thai Union). Thai Union saw the writing on the wall — Red Lobster was in a tailspin — and wanted to squeeze as much money as they could out of a bad investment. How? Get zombie-Red-Lobster to spend as many of its remaining dollars as possible on Thai Union’s shrimp.

I learned about all of this from Matt Levine. In a recent episode of the Money Stuff podcast, Matt drew on some analysis from Apoorv Agrawal to make an analogy.

The essential conflict of interest here – one company both owning and supplying another – is also pervasive in the AI industry. AI company valuations have been driven by enormous investments from cloud computing companies. Those deals give the AI companies tons of cash, which they turn around and hand right back to their investors in exchange for compute.

So in this analogy:

OpenAI/Anthropic/Databricks = Red Lobster
Microsoft/Amazon/NVIDIA = Thai Union
GPUs = raw shrimp
✨ buttons = Endless Shrimp (eat up!)

Again, this is not a perfect analogy. I don’t think that Microsoft thinks OpenAI is a zombie – worth $0 – which they must extract as much value as possible from, before an inevitable bankruptcy; I think they think generative AI is going to unlock wildly valuable new ways of computing and that their investment in OpenAI is going to pay off big-time.

And yet, this idea does help me make sense of a couple of things.

First: how on earth AI companies are flying so high, when the rest of tech is struggling in a “high-interest-rate environment.” It’s not just that the folks who still have money to spare think AI is the next big thing. It’s also that it’s much easier to invest a couple billion in something when you know you’re going to get a bunch of it right back.

Second: the feeling I have, as a user of technology, that I am being offered more, and more, and more AI stuff (shrimp). Shrimp at all costs; shrimp beyond utility, or reason. Don’t these shrimp cost money? How can they afford all of these shrimp? No matter; cloud compute companies are slamming their collective feet on their own growth accelerators. The shrimp must flow.

Through this lens, the reason that generative AI is booming is not that it produces value for customers, but rather that it consumes a lot of what the folks with money to spare are selling. This is a cynical and incomplete model for what’s happening; it doesn’t explain everything. But it has helped me see some things that I was missing.

Amen 🙏🏻🙏🏻🙏🏻.

Okay, Color Spaces

2024-02-20T00:00:00-08:00

Colors… in… spaaaaaaace

What is a “color space?”

Well first you take some colors.

red
yellow
blue

And then you arrange them, however you like, into some kind of space:

The space has coordinates. In the little toy color space we've just defined, red is at $(x = 0, y = 1)$ , yellow is at $(-1, -1)$ , and blue is at $(1, -1)$ . That’s a color space!

You might ask: what kind of color might we find at the origin: $(0, 0)$ ? Right now, it’s undefined, but we could put anything there: black, gray, brown, heck – even hotpink if we wanted.

Which brings us to the first point: color spaces are all constructs. People just make them up! Useful ones are constructed in order to do useful things, but there’s no, like, One True Fundamental Color Space.

The red-yellow-blue color wheel
(as handed down from Newton and Goethe).

When I was a kid, various art teachers taught me about The Color Wheel with its Three Primary Colors and its Three Secondary Colors and while that wheel did help me make greenish paint when the classroom only had yellow and blue, it also gave me some wrong ideas about color.

You see, just like the food pyramid, the RYB color wheel is made up. It’s a conceptual model, invented by people, who invented it by arranging a set of things into an abstract, hierarchical geometry, as a problem-solving tool. The RYB color wheel was developed in order to give artists and eight-year-olds a (rough) way to (loosely) predict what might happen when they mixed certain pigments. But colors – like tastes, touches, and smells – don’t have any kind of innate geometric relationship to each other. When we arrange colors around a wheel, or set them into any other space: we did that.

All of this is to say: color spaces can’t really be “right” (or “wrong.”) They can only be useful.

CIE XYZ: a very useful color space

The toy color space that I constructed at the beginning of this post is useless. It doesn't help us do anything.

What might a useful color space do? Well, just like the RYB color wheel, maybe it could help us predict how different colors will mix.

And lo, in 1931, an international team of experts got together in England and laid out a color space that does exactly that¹. They used science and math. They called themselves the International Commission on Illumination (aka le Commission Internationale de l'Éclairage, aka the CIE), and they called their color space CIE XYZ.

Here are three colors plotted in CIE XYZ: a red, a green, and a blue.

Click/touch and drag to rotate the space

The first thing you might notice is, it's 3D! Turns out, most useful color spaces have at least three dimensions, although in order to visualize various things, people will often flatten 3D spaces into 2D.

Now, CIE XYZ isn’t limited to three colors. In fact, it contains all of the colors².

So let’s fill our visualization out a bit. The red, green, and blue that that I plotted above happen to be the three primary colors that define the P3 color gamut. Here’s the rest of the P3 gamut, plotted in CIE XYZ:

Cross section

Y

Sweep the “cross section $Y$ ” slider to get a sense of how colors are distributed in the solid’s interior.

Unlike our toy color space, which defined three discrete colors, CIE XYZ is continuous. I could pick any point in the CIE XYZ space and get a unique color. That’s cool, but it’s still not useful. What’s useful about CIE XYZ is the way it helps people solve the related problems of predicting mixes and creating matches of arbitrary colors.

CIE XYZ is built out of three functions. Those functions take some wavelength of light as input, and give $X$ , $Y$ , and $Z$ as output. This means you can sample some real-world light with a spectrometer, do some math, and get an $X$ , a $Y$ , and a $Z$ , which locate that light’s color within the CIE XYZ space.

Let’s say I’ve got a pair of spotlights:

color(xyz-d65 0.40 0.25 0.05) (red)
color(xyz-d65 0.30 0.50 0.10) (green)

What color will I see if I shine them both, full-blast, at the same spot? CIE XYZ lets me predict the result. The space has been structured in just such a way that all I have to do is add up the $X$ s, $Y$ s, and $Z$ s:

color(xyz-d65 0.70 0.75 0.15) (yellow!)

By slicing a lil’ parallelogram out of the CIE XYZ space – with one corner at black, two corners at the locations of our two spotlights, and the last corner at the location of their full-blast mix – I can predict what any combination of these two lights, at any intensity level, is going to look like.

Red spotlight intensity 100%

Green spotlight intensity 100%

Left: simulated spotlights. Right: the white circle shows the location of the mixed color within CIE XYZ.

With a little matrix algebra, I can go the other way: CIE XYZ lets me take a color and figure out whether-and-how I can replicate it by mixing another set of colored lights. This is extremely useful! Once I know the CIE XYZ coordinates of the subpixels that make up a physical pixel on a display, I can calculate how to mix them to precisely replicate all kinds of colors. With CIE XYZ, I can dial up, say, color(xyz-d65 0.12 0.07 0.31) on wildly different displays and get consistent results.

CIE XYZ turns color mixing problems and color matching problems into math problems. This has proven so useful that every modern color space is defined in terms of CIE XYZ. When we say that a system is “color managed” what we’re saying is: it’s built on top of CIE XYZ.

So! CIE XYZ! It’s useful! But it’s not useful for everything.

Perceptual uniformity (is hard)

Predicting mixes was one thing I learned in art class. Another? Creating even gradients.

Still got it

When you’re learning a new medium or technique – crosshatching, watercolors, whatever – this is the 101 lesson; it’s like playing scales in music. Practicing gradients gives you a facility with the tools and teaches you how to judge and create even intervals of color.

CIE XYZ is very bad at this. If we draw a straight line through the CIE XYZ space and mark that line at evenly-spaced intervals, sampling at each mark, we get bad gradients. Like this lopsided grayscale:

CIE XYZ gradient

Something better, for comparison

CIE XYZ hangs out in the light-gray zone forever, and then gets very dark very fast – that last step is a doozy.

All CIE XYZ transitions from lighter colors to darker colors suffer from this problem³.

Yellow yellow yellow yellow, yellowish-gray… mauve… purple!

This one has the same number of yellows and purples, and puts the middle color in the middle.

Transitions between light colors and dark colors aren’t the only problem. Gradients between different hues can look lopsided, too.⁴.

I can barely tell the difference between the first two swatches. But things are getting green quickly, over on the right.

Better.

My favorite perceptual problem with CIE XYZ is that transitions between blue and gray get weirdly purple in the middle:

Blue lights actually do this in real life!

True blue, all the way through.

Color nerds call color spaces that are good at creating even gradients “perceptually uniform.” Meaning, the distance between any two colors in the space corresponds to “how different” they look, to people. There are all sorts of reasons folks might want a color space like this.

Maybe they’re making a data visualization and want to use color differences to communicate value differences.
Maybe they’re making image-editing software, and want modifications to feel consistent and intuitive.⁵
Maybe they’re storing colors digitally, and want to store as many perceptually-different colors in as few bits as possible.
Maybe they’re trying to measure color contrast in order to ensure accessibility.
Maybe they’re trying to render a nice, even-looking gradient as a design element.

For these tasks (and more!), a perceptually-uniform color space is the right tool for the job.

As discussed, CIE XYZ ain’t it.

(sRGB, the web’s dominant, default color space, was constructed in order to model a typical 1990s cathode-ray tube display; sRGB also ain’t it.⁶)

The first attempt at “it” (a perceptually-uniform color space) was made by Albert Munsell, who described his space in 1905 (charmingly, as a “COLOR TREE”) and published an “Atlas” to it in 1913.

The central “trunk” of Munsell’s TREE goes from black at the bottom, through grey in the middle, to white at the top. The middle expands outwards into a rainbow of “branches”, with each angle around the trunk representing a particular hue. Each branch starts off desaturated near the middle, and gets more and more saturated the further out it goes.

Left: A wood engraving illustrating Munsell’s COLOR TREE from A Grammar of Color by T. M. Cleland, 1921. Right: An excellent cutaway visualization of the Munsell Renotation Data by the stellar Wikipedian, Mike Horvath, aka Datumizer

Whereas every color theorist before Albert Munsell (and many, after him) worked from the “frame in”, trying to cram all visible colors into a regular shape like a wheel or a sphere or whatever, Munsell instead worked from the “content out”, trying to create even intervals between adjacent colors and letting each “branch” extend as far as it could before he reached some limit of saturation. The resulting solid resembles a lumpy, lopsided spinning top.

Albert’s COLOR TREE was immediately recognized as useful, and is in fact still used. But as time passed, problems accumulated:

It was based on his own personal judgements rather than scientific experiments, and it showed.
(Just like our toy color space!) the COLOR TREE is discrete, and only specifies the positions of a few hundred individual colors.
Those colors didn’t cover anything close to the range of colors that people can actually see.

In the decades that followed, people tried to solve all of these problems, both iterating on Munsell’s tree and creating wholly new continuous color spaces that attempted to be perceptually uniform. Arguably, the most significant of those spaces was constructed by the CIE, in 1976: CIELAB. (Ever heard of “Lab color”? This is that.)

CIELAB is a relatively simple mathematical transform of CIE XYZ, making it easy to implement in “color managed” digital contexts. But – tragically! – CIELAB isn’t exactly perceptually uniform. Worse, the more experiments people did, the clearer it became that no three-dimensional space could ever be perceptually uniform; three dimensions just cannot capture all of the weird and wonderful ways that our eyes and brains process color comparisons. As anyone who has entered a Turrell or debated The Dress can tell you, color perception is wild. When trying to predict how people are going to perceive the difference between two colors, we need to account for way more than three variables. For instance:

How large are the color samples? Where are they in the subject’s field of vision?
How long have they been there? What other colors were there recently?
Crucially, what other colors surround the samples?
What’s the ambient background lighting like?

(I’m not even going to mention the ways in which we “read” scenes within semantic and cultural contexts, which also matter.)

So, after 1976, people started developing more-and-more complicated models that attempted to account for more-and-more of this complexity. We’ve spent fifty years coming up with these things. Many of the resulting color models are considered too complex for most practical applications, and yet none of them is considered perfect.

I am fascinated that the CIE knocked predicting color mixes and matches out of the park in 1931, and yet here we are, almost a hundred years later, still trying to solve the problem of predicting color differences. Our mastery of mixing and matching makes us very good at capturing and replicating colors. But, because we can’t predict differences well, we’re still bad at automating all sorts of other color tasks, which remain as much art as science.

One thing that’s absolutely clear is that the problem of perceptual uniformity is never going to be solved with a plain-Jane three-dimensional color space. But! The entire universe of digital imaging is rooted in such spaces, because it’s all built on top of CIE XYZ.

So – what is someone who wants a perceptually-uniform space in a digital context supposed to do these days?

Oklab: it’s okay!

Until a few years ago, the best tool for these sorts of jobs was still CIELAB. So I was excited when CIELAB-for-the-web was first proposed in 2016. And then I waited for five years, until it finally shipped.

While I was waiting, in December of 2020, a guy named Björn Ottosson wrote a blog post. In it, he introduced a brand-new three-dimensional color space that he’d been working on: Oklab.

In an over-simplified nutshell, here’s how Björn came up with Oklab:

He picked a couple of best-in-class color models⁷.
After choosing a set of values representing “normal” viewing conditions, he used those models to generate a set of color comparison data.
He transformed CIE XYZ in a mathematically clean/easy way to approximately fit all of that color comparison data pretty well.

Et voila: Oklab. Here’s what it looks like:

Cross section

L

The P3 gamut, plotted in the Oklab color space.

Is it perfect? No, it is not. But is it mathematically and computationally simple? Yes! And does it perform better at most tasks requiring perceptual uniformity than all of the other simple, three-dimensional color spaces? Sure seems like it!

What happened next was astonishing: the web platform rapidly adopted Oklab. Oklab went from a blog post to shipping in Safari in fifteen months! Wild!

Photoshop soon followed suit.

So, Oklab: if you want perceptual ~uniformity, it’ll do.

OKLCH, because Munsell was a good API designer

What do Oklab’s $L$ , $a$ , and $b$ parameters actually mean?

$L$ is lightness. This represents how light or dark a color looks. $L$ goes from zero to one.
$a$ is “greeness-to-redness” with gray at zero. It’s theoretically unbounded but in practice it goes from around -0.4 to +0.4.
$b$ is “blueness-to-yellowness” with gray at zero. Same-same with the practical approximate -0.4 to +0.4 range.

So, in Oklab, blueviolet is oklab(53.38% 0.1303 -0.2137): medium lightness, somewhat red, and rather blue.

Are you thinking what I'm thinking? $a$ and $b$ are weird.

Munsell’s COLOR TREE has much nicer dimensions:

Lightness: height up the tree; black to white.
Hue: angle around the trunk; just like the color wheels of my youth.
Chroma: how far away from the trunk are we? Gray in the middle and more saturated the further away we get.

These three dimensions seem to express ways that our brains actually process color. When comparing one color to another on the same branch of Munsell’s COLOR TREE, it feels like only one thing has changed: chroma. Likewise when we go up and down the tree, or around it – both lightness and hue feel like independent variables. Whereas when we change, say, the $a$ of an Oklab color, it feels like we’re changing two things – both the hue and the chroma – simultaneously. It’s not easy to predict how changing $a$ or $b$ is going to look.

Thankfully – turns out! – Oklab was explicitly designed so that movement up/down, in/out, and around the $L$ axis works exactly like navigating Munsell’s COLOR TREE. Each type of movement changes just one, psychologically-independent thing: the lightness, chroma, or hue of the color. In order to navigate Oklab like this, we need to use a polar coordinate system, instead of a rectangular one. When we do, we refer to the space by another name: OKLCH⁸.

Same same; oklab(53.38% 0.1303 -0.2137) = oklch(53.38% 0.2503 301.4deg).

I should note that OKLCH was not the first color space to adopt Munsell’s lightness-chroma-hue “API”; even CIELAB had a polar version that worked like this, called LCH. But OKLCH does appear to be one of the best.

Both OKLCH and Oklab have their uses. Gradients in polar spaces work differently than gradients in rectangular spaces. They’re not better or worse, mind you – just different.

In a rectangular space, a gradient between two colors that lie on opposite sides of the space gets gray in the middle:

In a polar space, instead of drawing a straight line through the space to get from one color to the other, we orbit the origin, creating a half-rainbow of evenly-separated hues.

Some tasks (like measuring color difference) are simpler in rectangular spaces. But whenever we want to change the hue or chroma of a color independently – say, when we want to turn a color’s saturation up a notch, or theme and scheme with code – only a perceptually ~uniform, polar space will do. Right now, on the web: that means OKLCH.

So!

What have we learned?

Color spaces are constructs, which arrange colors into some coordinate-based space.
Colors don’t have any kind of innate spatial relationship to each other, but arranging them in various ways can be useful.
CIE XYZ is an extremely useful color space, because it turns color mixing problems and color matching problems into math problems.
All “color managed” digital imaging is based on CIE XYZ.
Measuring how we’ll perceive the difference between two colors is a whole other kettle of fish; predicting differences remains an unsolved problem.
Solving that problem – by constructing a model with perfect “perceptual uniformity” – is going to require more than three variables, but oops! We built all digital imaging on top of CIE XYZ, a three-dimensional space.
Oklab tries to resolve this by making many assumptions and simplifications, in order to model everything we’ve learned about perceptual uniformity in a simple three-dimensional space.
Oklab is pretty good!
People tend to think about color in terms of three variables: lightness, chroma, and hue.
Oklab does a good job of isolating these variables, but in order to use them, we have to navigate it using polar coordinates instead of rectangular ones. When we navigate Oklab this way, we call it OKLCH.

Time to play

Enough reading! Go! Explore!

Evil Martians’ OKLCH color picker is fantastic.
I couldn’t have written this post without Color.js. It’s doing all of the color math in the interactive visualizations, and I had multiple color notebooks open at all times, while writing.
Speaking of the interactive illustrations, if you want to visualize other gamuts in other color spaces, the ColorAide Interactive 3D Color Space Models demo by Isaac Muse and Hueplot by Alexey Ardov have you covered.
For a different entry point into understanding color spaces in general and CIE XYZ in particular, check out Bartosz Ciechanowski’s Color Spaces. It’s chock full of interactives.
I know I linked to it earlier, but Björn Ottosson’s original Oklab blog post is very good.

Okay, bye! 🌈

…for colored light, not colored pigments. Predicting how pigments will mix is hard. ↩︎
In addition to containing all of the visible colors, CIE XYZ contains a bunch of imaginary colors, which are, uh, outside of the scope of this article. ↩︎
…because CIE XYZ represents intensity linearly, but like all of our senses, human vision responds ~logarithmically to input. ↩︎
…because we’re more sensitive to some hues than others. An implication of this is that there are many times more photons shooting out of the blue side of that gradient, than there are from the green side, even though every swatch on the gradient has the same apparent lightness. Weird! ↩︎
Many image editing operations (for instance: compositing and downscaling) require a color space like CIE XYZ that models how light works. But many others (for instance: changing hue, saturation, and/or lightness) benefit from being done in a perceptually uniform space that models how our eyes and brains process light.↩︎
Although, interestingly, cathode-ray tubes respond to input non-linearly, kind-of-sort-of like people do. ↩︎
CAM16-UCS and IPT. ↩︎
Pronounced “Oklachroma”. ↩︎

Sizes="auto" pretty much requires width and height attributes

2023-12-05T00:00:00-08:00

Writing, reading, and maintaining sizes attributes is the worst part about authoring responsive images; auto-sizes for lazy-loaded images is a fantastic addition to the platform.

(It is very funny that the Chrome Platform Status entry for sizes=auto currently describes web developers’ collective opinion about the feature as “no signals.” One-in-ten sizes attributes on the web are already using auto, via lazysizes.js! But I digress.)

Auto-sizes just shipped behind the Experimental Web Platform Features flag in Chrome Canary. Which makes this a good time to try to explain the one weird thing about it. In short: in addition to requiring loading=lazy, sizes=auto also basically requires that <img> elements have width and height attributes.

But don’t take my word for it. Here’s a note from Section 4.8.2.2 of the HTML specification, Sizes attributes:

Note: […] it is strongly encouraged to specify dimensions using the width and height attributes or with CSS. Without specified dimensions, the image will likely render with 300x150 dimensions because sizes="auto" implies contain-intrinsic-size: 300px 150px

What!? 300×150? It’s true! Here’s an <img> element that uses sizes=auto:

<img
	loading="lazy"
	sizes="auto"
	srcset="
		https://o.img.rodeo/w_1200,h_1200,b_tomato/t_WxH/_.png   1200w,
		https://o.img.rodeo/w_900,h_900,b_goldenrod/t_WxH/_.png   900w,
		https://o.img.rodeo/w_600,h_600,b_forestgreen/t_WxH/_.png 600w,
		https://o.img.rodeo/w_300,h_300,b_dodgerblue/t_WxH/_.png  300w"
	src="https://o.img.rodeo/w_300,h_300,b_forestgreen/t_WxH/_.png"
	alt="An example image that reports its natural dimensions"
>

And here’s what that looks like right now, in Canary, with the Experimental Web Platform Features flag on:

Note that Canary did load the best resource to fit (300px@2x = 600 device pixels).

Before I answer some obvious questions (what is happening, why), let’s tackle the practical: how do I fix it?

What values should I use for `height` and `width`?

You should use the height and width, in pixels, of the largest resource that your <img> can serve. If you’re using srcset, that means the dimensions of the largest resource in your srcset:

<img
	loading="lazy"
	sizes="auto"
	width="1200"
	height="1200"
	srcset="
		https://o.img.rodeo/w_1200,h_1200,b_tomato/t_WxH/_.png   1200w,
		https://o.img.rodeo/w_900,h_900,b_goldenrod/t_WxH/_.png   900w,
		https://o.img.rodeo/w_600,h_600,b_forestgreen/t_WxH/_.png 600w,
		https://o.img.rodeo/w_300,h_300,b_dodgerblue/t_WxH/_.png  300w"
	src="https://o.img.rodeo/w_300,h_300,b_dodgerblue/t_WxH/_.png"
	alt="An example image that reports its natural dimensions"
>

(If you’re using Client Hints, you should use the dimensions of the full-size resource, before any server-side downscaling for delivery. Here’s a (Chrome-only) example that uses Client Hints.)

Depending on what else you have going on in your CSS, adding width and height to your HTML might unexpectedly distort your <img>, giving it a garish, fixed height which will pair terribly with its delightfully flexible width. One line of CSS will fix that for you:

img {
	height: auto; 
}

All together, now:

<style>
img {
	width: 100%;
	height: auto;
}
</style>

<img
	loading="lazy"
	sizes="auto"
	width="1200"
	height="1200"
	srcset="
		https://o.img.rodeo/w_1200,h_1200,b_tomato/t_WxH/_.png   1200w,
		https://o.img.rodeo/w_900,h_900,b_goldenrod/t_WxH/_.png   900w,
		https://o.img.rodeo/w_600,h_600,b_forestgreen/t_WxH/_.png 600w,
		https://o.img.rodeo/w_300,h_300,b_dodgerblue/t_WxH/_.png  300w"
	src="https://o.img.rodeo/w_300,h_300,b_dodgerblue/t_WxH/_.png"
	alt="An example image that reports its natural dimensions"
>

And here’s a screenshot of what that looks like in Canary with the flag on:

All better!

Perhaps you’re already adding height and width to your responsive image HTML and height: auto to your CSS in order to prevent layout shifts. Great! Change nothing!

Ok, so:

What is happening and why?

By default, images on the web are rendered at their natural (aka intrinsic) dimensions. If you stick a 300×300 resource into an <img> and do nothing else, its layout size will be 300×300.

The natural dimensions of responsive images get surprisingly weird, fast, but:

There are a number of ways that a loaded resource’s natural dimensions can affect the layout dimensions of its <img>.
The value of sizes=auto updates whenever an <img>’s layout dimensions change, possibly triggering a new resource load.
A new resource will have new natural dimensions, which can affect the <img>’s layout dimensions, which will update the sizes=auto value, which may trigger a new resource load; the new resource will have new natural dimensions, which …&c.

A lot of the spec discussion around sizes=auto was just: people coming up with corner cases that would load every single resource in a srcset, one-after-the-other, using this mechanism.

Simon Pieters, who wrote the auto-sizes spec, made a few valiant and clever attempts to define all of the cases that could possibly trigger cyclical dependencies and work around them in ways that wouldn’t be too weird or noticeable for authors. But when the rubber hit the road and implementers started implementing, those workarounds didn’t hold up. Ultimately, ’twas decided that the only way forward was to make a clean cut: mandate that a loaded resource’s natural dimensions cannot affect its <img>’s layout in any way, ever, when sizes=auto is involved. Luckily, we have a fairly new feature that explicitly does exactly that: size containment.

Snip snip!

So now, this is in Chrome Canary’s UA stylesheet:

img:is([sizes="auto" i], [sizes^="auto," i]) {
    contain: size !important;
    contain-intrinsic-size: 300px 150px;
}

That says: are we dealing with an <img> with sizes=auto? Then its natural dimensions are 300×150. NO EXCEPTIONS.

300×150 was chosen because that’s what <video> and <canvas> do; all of these elements use this smallish-but-non-zero default size in order to encourage you to do better.

Finally, we get to the load-bearing weasel-words in the title of this post: “sizes=auto pretty much requires width and height attributes”. width and height are not the only way! I think the pattern that I’m pushing, where you describe the aspect ratio of your content in HTML, and give it a flexible size in CSS – provides a better separation of concerns than any other solution. But the fundamental takeaway is: when you use sizes=auto, your image will be assigned a natural size of 300×150 and a natural aspect ratio of 2:1, and it’s on you to override those dimensions.

The Maintenance Race (and me)

2023-10-04T00:00:00-07:00

A couple of days ago, Dave Rupert shared an excellent article that I’ve been thinking about for, like, a whole year: Steward Brand’s The Maintenance Race.

The article is about a round-the-world solo sailboat race held in 1968, and you should go read it before you read any of this.

After Dave shared it, I sarcastically quipped back:

@davatron5000 me, looking at a sink full of unwashed dishes and piles of unsorted mail on the counter, before retiring to the couch: “every day a new boat”

…who responded in earnest…

@eeeps Yeah. Looking at my desk I felt the shame. I like the attitude tho and aspire to get there.

…and made me realize that:

My pithy reply was cheap and insufficient.
My year-of-mulling-this-thing-over has left me with some thoughts that are too big for toots.

First: the whole premise of a solo around-the-world race represents something I am both deeply drawn to, and increasingly wary of.

Men sailing alone

Austin Kleon quoted James Hollis the other day:

I have suggested that women look at men this way: if they took away their own network of intimate friends, […] concluded that they were almost wholly alone in the world, and understood that they would be defined only by standards of productivity external to them, they would then know the inner state of the average man. They are horrified at this notion.

Through this lens, the Golden Globe Race was the ideal man scenario: each competitor was completely alone, in complete control of themselves and their tools, and placed in complete opposition to the vast and unforgiving world around them. They were in a competition where “success” and “failure” were externally defined and objectively measured.

I feel the appeal of all of this in my bones. But, like Austin, I am trying to fight it. I can see the person that this stance towards the world would lead (and, in some ways, has already led) me to become – and I don’t like him! I want to make more of my own meaning, and find – and share! – that meaning in community.

Moitessier, the hero of the story, does end up finding his own meaning: both in the journey (love this) and in being alone (oh no). It’s beautiful, but it’s not who I want to be.

The old ways are best

So, toxic/solitary masculinity is the setting for our story. Within it, three protagonists attempt to build and maintain systems in order to achieve their goals. And hey, aren’t we all just out here, attempting to build and maintain systems in order to achieve our goals, in one way or another? Here’s how they fared:

The one who relied on schmantzy tech but had no interest-in/discipline-for the fundamentals of sailing began lying about his progress, went mad, and ultimately died (this is React).
The one with a ramshackle, roll-with-the-punches, can-do attitude won the race (this is PHP).
Finally, there was one sailor who pursued simplicity above all else. He stuck to the basics and perfected the fundamentals. He double-checked and triple-reinforced everything before setting off. And then he found a serene monk-like meaning in maintenance and routine. What happened to him? Well, he just kept on sailing, on and on and on (this is me, reciting passages from the Dao, floating an inch above my office chair, exuding HTML Energy).

Clearly, there are value systems at play here that I am deeply attracted and attached to. I love seeing my mindful-minimalist guy become the transcendent hero. I love (the idea of) prepared, focused discipline. Less is more! Choose boring technology! Perhaps most of all I love a story that richly illustrates the superiority of my technological sensibilities using historical boats.

But.

Inbox zero for boats

Back to me in the kitchen. Here’s the passage I referenced in my quip to Dave, and often reflect on, when I find myself half-assing maintenance of various sorts:

One time, when I remarked on how fit [Moitessier’s] boat looked, he said, ‘My rule is, a new boat every day’. His years at sea had taught him that if you don’t fix something when you first see it beginning to fail, it is very likely to finish failing just when it is the most dangerous and the hardest to deal with, such as in the midst of a storm.

I look at my life, and “a new boat every day,” applied broadly, is untenable. There are too many systems; there isn’t enough time to maintain everything to 100% every single day. Some days I look around and all I see are undone tasks; aspirations half-met, things in various states of disrepair. So why don’t I ruthlessly simplify, like Moitessier?

I guess it’s because Moitessier was living a life that had been maximally-scoped-down: it was just him, his boat, and the sailing.

I’ve got, like, more than that going on? And my life is richer for it. My life has other people in it, and I’m doing all sorts of stuff – changing my mind, trying new things, negotiating, compromising – and there’s a variety and opportunity to the resulting, sometimes messy, push-and-pull that I wouldn’t trade for the serenity of a deep-cleaned kitchen every morning.

Like Marie Kondo herself said, not too long ago:

My home is messy, but the way I am spending my time is the right way for me at this time at this stage of my life.

There have been (and still are!) spaces, places, and seasons in my life for reduction; for focus; for discipline. You gotta pick your boats, though. Maybe your inbox is one; maybe your backlog is one; maybe your kitchen is a boat.

But a whole entire life lived so rigidly? Not for me. Too limiting. Gotta find a balance.

View Transitions Break Incremental Rendering

2023-08-22T00:00:00-07:00

By default, webpages render like this:

Image swiped from Phil Walton’s web.dev article on First Contentful Paint

Stuff pops in as it’s loaded, parsed, and styled. This is called incremental rendering.

Incremental rendering is cool and good. It is especially cool/good for people on slow connections. They get to see pieces of the page ASAP; incremental rendering shows them something while the page is in flight, instead of nothing.

First Contentful Paint and Page Load Time distributions from the June 2023 RUM Archive, on Observable

For the 99th percentile of page loads in a recent batch of RUM Archive data, incremental rendering gave folks something after 10 seconds. Without it, they would have spent 40 seconds looking at nothing.¹

While incremental rendering is especially helpful for people in slower contexts, we don’t have to look to the 99th percentile to see tangible benefits. For the median page load, incremental rendering halved the time people waited to see something, cutting it from just over two seconds to just over one.

So that’s incremental rendering. I like it a lot.

Cross-document View Transitions render like this:

Video swiped from Dave Rupert’s Getting started with View Transitions on multi-page apps

Upon clicking a link, we leave one fully-rendered page, and usher in a new fully-rendered page, in an animated/orchestrated manner.

I ❤️ View Transitions. Being able to:

establish object permanence across navigations, and
direct attention with motion in order to highlight important arriving/departing elements

…is going to give designers the ability to make websites easier to navigate and understand. We’re going to be able to establish freaking spatial hierarchies across pages, on regular websites! Death to jarring, abrupt transitions!

Death to single-page-apps!

And, uh, death to — incremental rendering? (oh no).

The problem

Consider a View Transition to a partially-rendered page.

It might look fine, sometimes. For instance, if an <img src> hasn’t loaded, but that <img> element is otherwise all parsed and styled and includes height and width attributes, its dimensions will be reserved on the layout. We’ll get a transition to a solid background-color placeholder or something, which is not the end of the world. A not-loaded-yet font feels similarly not-horrible: we might View Transition in some invisible FOIT text, which, worst-case, triggers a reflow after it loads, jostling surrounding elements some time later. We lose the transition effect, but it’s kinda-sorta falling back to the experience you would have had, without the View Transition.

But. If we initiate a View Transition before things that are producing DOM or layout are loaded and parsed – CSS, HTML, and JS – that could be a disaster. Let’s say a bit of DOM hasn’t been loaded/parsed/styled/rendered yet when a View Transition starts, and then sometime later, when that piece of DOM is ready to render, it ends up having the same view-transition-name as something on the outgoing page. This means that the author intended for the old element to transition smoothly into the new one. Instead, the old one exits the page, and then the new one pops in, sometime later, not part of the transition process at all.

This is bad. At best it’ll look glitchy. At worst it does the exact opposite of guiding the eye to the most important elements on the page, and establishing object permanence. Instead of showing users that this thing is the same as that thing, we’ve told them, perhaps with extra motion/panache, that even though these the two things might seem the same, they are in fact distinct. It’s like shaking your head “no” while telling someone “yes.” Or perhaps it is more like walking out of the room and then teleporting back into place before you even answer their question. It is disorienting, surprising, and unsettling. It is much worse than having no transition at all.

This is a fundamental problem with View Transitions. And because browsers can and regularly do render partial pages – even on fast machines with fast connections loading fast pages – it’s going to affect everyone.

How to solve it?

Paint slower

The folks prototyping cross-document View Transitions in Chrome are solving this fundamental problem by building and extending features which delay the first paint until the page is ready to transition.

Already spec’d and implemented: blocking=render on scripts and stylesheets
A proposed extension: blocking=render on <html>

Two important points about these:

In order to use View Transitions, you are going to have to use these features (no matter how fast your site is).
You can use these features to disable incremental rendering, even when you’re not using View Transitions.

They are not tied to View Transitions because they are also supposed to solve the other (IMO all bad) use-cases people have for disabling incremental rendering:

If you’re at the 25th percentile in that chart at the top of the post – experiencing a First Contentful Paint at ~600ms, with a total Page Load Time of ~1100ms – trading an extra half-second of time-spent-staring-at-nothing in exchange for a less hurk-jerk-y experience might seem like an improvement.

But if you’re in the 99th percentile, you would never choose to stare at nothing for forty seconds when something — please, anything! — could have appeared after ten.

I worry that giving developers tools to explicitly block render – with or without View Transitions – is going to make experiencing the web on slow connections and cheap devices much worse. Because while the web’s authors generally experience the web at the left side of our chart, and make decisions based on those experiences, significant portions of the web’s users live their lives over on the right.

But not too slowly

The render-blocking specs have made room for implementation-defined timeouts for render-blocking features (ala font-display: block), and there is currently an open discussion on how/whether to bail out of View Transitions when things are taking too long. I think this is vital. We need tuned timeouts that ensure that the long tail of slow devices/connections don’t wait for View Transitions if they would excessively delay first paint.

It’s probably good that this timeout is left to implementers to define but it’s not great that Chrome currently sets it to network timeout which I think is, like, 240 seconds!? I fully expect this all to get better as View Transitions moves towards shipping, though.

Paint just slowly enough?

The specs also try to give authors tools to tell the browser a bare-minimum amount of HTML, CSS, and JS that’s needed to paint the initial viewport, but that’s incredibly hard to do well. I fully expect everybody who wants to use View Transitions – especially toolmakers and template/component authors who don’t know much about the content they’re working with or the context they’re working in — will simply slap blocking=render onto everything.

Paint… faster?

I have low expectations, but sincere hope, that we can do better. Maybe instead of significantly delaying the first paint for View Transitions, quick render-blocking timeouts could serve as a stick which, paired with the carrot of View Transitions, might motivate authors to push their pages to paint faster.

Besides quick timeouts, what else could View Transitions and blocking=render do, here? What other platform-level changes could make faster and more-complete first paints hard to screw up, rather than hard to do at all – especially on slower connections and devices? I don’t know but I want to spend some time thinking about it.

Low expectations. High hopes!

Thanks to Mat Marquis, Stuart Langridge, and Jason Grigsby for reviewing an early draft!

Important caveat! For this analysis, I used two metrics: Page Load Time and First Contentful Paint. (I also assume they are perfectly correlated, but let’s leave that aside; bigger fish to fry). First Contentful Paint is the exact metric we need; Page Load Time isn’t. The proposed features would delay first paint until the document and many scripts and stylesheets have been loaded. Page Load Time, on the other hand, measures how long it took for everything to load, notably including images (which the proposed features would not wait for). So this chart likely overstates the case. I would love to get a more accurate picture of the potential impact of the proposals; alas this is the best I know how to do at the moment. ↩