https://jakearchibald.com/Jake Archibald's blog2026-09-15T22:18:48.489Zhttps://github.com/jpmonette/feedhttps://jakearchibald.com/c/icon-CJ5sT8Gh.pnghttps://jakearchibald.com/favicon.icohttps://creativecommons.org/licenses/by/4.0/<![CDATA[Controlling when CSS custom property values are computed]]>https://jakearchibald.com/2026/css-custom-property-compute-time/2026-08-26T01:00:00.000ZWhen and how CSS custom property values are calculated might not be what you expect, and it has a big impact on your styles.
The question is, how much is the paragraph going to scale?
sibling-index() is 1-indexed, but is it going to pick up the index of the second div - where the custom property is defined, or its first child - where the custom property is used? The answer is: it depends.
If the code is taken in isolation, the value of the custom property will be stored as a token stream, so it's computed a little like this:
.second-item {--index: sibling-index();/* …Which computes to: */--index: sibling-index();/* (as in, no change) */& > :first-child {scale: var(--index);/* …Which is substituted for: */scale: sibling-index();/* …Which computes to: */scale: 1;}}
So the var() is substituted for sibling-index(), which is evaluated in that context. Since the paragraph is the first child of its parent, it will scale by 1.
This is reflected in getComputedStyle():
const div = document.querySelector('.second-item',);console.log(getComputedStyle(div,).getPropertyValue('--index'),);// Logs: "sibling-index()"
const div = document.querySelector('.second-item',);console.log(getComputedStyle(div).getPropertyValue('--index',),);// Logs: "sibling-index()"
const div = document.querySelector('.second-item');console.log(getComputedStyle(div).getPropertyValue('--index'),);// Logs: "sibling-index()"
const div = document.querySelector('.second-item');console.log(getComputedStyle(div).getPropertyValue('--index'));// Logs: "sibling-index()"
Custom properties you haven't registered behave as if they have syntax: '*', meaning 'anything', which computes to a token stream as before. But here we're using '<number>', meaning it computes the value as a number:
.second-item {--index: sibling-index();/* …Which computes to: */--index: 2;& > :first-child {scale: var(--index);/* …Which is substituted for: */scale: 2;/* …Which computes to: */scale: 2;}}
Registering the custom property & giving it a syntax meant the full value was computed earlier, in a different context, so the result was different.
Again, this is reflected in getComputedStyle():
const div = document.querySelector('.second-item',);console.log(getComputedStyle(div,).getPropertyValue('--index'),);// Logs: "2"
const div = document.querySelector('.second-item',);console.log(getComputedStyle(div).getPropertyValue('--index',),);// Logs: "2"
const div = document.querySelector('.second-item');console.log(getComputedStyle(div).getPropertyValue('--index'),);// Logs: "2"
const div = document.querySelector('.second-item');console.log(getComputedStyle(div).getPropertyValue('--index'));// Logs: "2"
And it's not just sibling-index() that behaves this way. This also impacts relative font units (em, ex, ch, cap, lh etc.), container query units (cqw, cqi, cqb etc.), and more. In all these cases, @property controls which element the values are computed against.
Another thing that's impacted, although slightly differently, is URLs. In CSS, URLs are generally resolved against the stylesheet's base URL at computed-value time - so if a token-stream custom property is defined in one stylesheet and var()'d from another, the URL resolves against the consuming stylesheet. Registering the custom property with syntax: '<url>' pins it to the stylesheet that declared it.
What happens here? Well, var() behaves differently to sibling-index(). var() is an "arbitrary substitution function", along with a bunch of other functions like if(), attr(), and ident(). These are substituted regardless of the syntax of the custom property. So:
What happens next depends on the defined syntax of --index. It'll either stay as the above token stream, or it'll compute down to 2 - the same rules as before. In both cases, --multiplier: 3 on the child is ignored.
This was a detail of CSS that I sort-of half-knew, as in, I knew @property changed computation timing somehow, but I hadn't fully understood when or how, until I looked it up today. I hope you understand it now too!
]]><![CDATA[Fixing my tooltip accessibility mistake]]>https://jakearchibald.com/2026/my-tooltip-a11y-mistake/2026-07-28T01:00:00.000ZI made an accessibility error, and I want you to learn from my mistakes.
I've been making short videos recently about web platform features as they land in Firefox, and also about other web standards & development stuff. If you'd prefer to watch a 3-minute video version of this article, pick your platform, and give the account a follow if this kind of thing interests you:
I did try to get it right! I spoke to friends who know more about accessibility than me, and they pointed me towards these demos by Scott O'Hara.
Now, Scott knows what he's talking about, so I figured I could just copy the patterns in his demo. Scott's demos predate hint popovers, so here's a modernised version of one of his examples:
It's a very similar pattern, although I have aria-label on the button, because it contains an SVG icon rather than text.
Like Scott, I added aria-describedby to the button, to connect the button to the tooltip.
I tested it in VoiceOver, and it said "Bold. Bold. Command B. Button". And I thought, that's not quite right - it doesn't need to say "bold" twice.
That was happening because, unlike Scott's example, where the tooltip contained just additional content, my tooltip also contains the label. Bold is said twice, because it's there, twice.
I got a message from Léonie Watson and Gez Lemon from the accessibility agency TetraLogical, telling me, very politely, that I'd done a silly.
Scott's pattern was correct, but I'd gone off the rails when I removed the aria-label, because now, the button has no accessible name. aria-describedby provides additional information - it isn't a replacement for the accessible name.
In fact, JAWS on Windows tries to gather accessible text from nearby elements, and ends up announcing the bold button as both bold and italic, since the italic tooltip element was a sibling in the DOM.
There was a bit of a clue when VoiceOver said "clickable image" - this was VoiceOver indicating it didn't have an accessible name to announce. I just didn't realise it at the time.
I think that's overkill in this case, but it might make sense if you have a tooltip with a longer description.
So there you go! Always ensure interactive elements have an accessible name. And test with multiple screen readers if you can. Testing in one screen reader is like testing in one browser - it doesn't always give you the full picture.
Here's the fixed demo, although it doesn't work quite right in Safari, as it doesn't yet support popover="hint".
]]><![CDATA[The Goldilocks customizable select height]]>https://jakearchibald.com/2026/goldilocks-select-height/2026-06-29T01:00:00.000ZI recently gave a talk on customizable (as in fully-stylable) <select>, and as I was building demos I realised there's a sizing 'pattern' that's almost always the-one-you-want, but it took me a long time to figure out how to do it in CSS.
Well, I say I figured it out. I actually failed, and asked a bunch of people for help, who (thankfully, for my ego) also struggled. Eventually, Ian Kilpatrick pointed me at the feature I was missing…
Unfortunately you're using Safari 26.5 or lower, which has a buggy implementation of anchor positioning, so these demos won't work for you. They work in Safari Technology Preview, so the techniques in this article should work by the time Safari ships custom select.
It isn't actually a custom select. Firefox and Safari are actively working on custom select, but haven't released it yet, so to make the demos work in more browsers, and to make it easier for you to inspect with DevTools, I've built the demos from popovers, and CSS anchor positioning, which are the same primitives custom select uses under the hood.
You can drag it around and see how it reacts to being in other parts of the viewport, and how it reacts to scrolling. If you can't be bothered with all that, here's a video:
Here are the default UA styles that impact the picker's position and height:
::picker(select) {margin: 0;inset: auto;min-inline-size: anchor-size(self-inline);max-block-size: stretch;position-area: self-block-endspan-self-inline-end;position-try-order: most-block-size;position-try-fallbacks:self-block-startspan-self-inline-end,self-block-endspan-self-inline-start,self-block-startspan-self-inline-start;/* Not part of the spec, but it's something Chrome does, so I've included it */min-block-size: 1lh;}
::picker(select) {margin: 0;inset: auto;min-inline-size: anchor-size(self-inline);max-block-size: stretch;position-area: self-block-endspan-self-inline-end;position-try-order: most-block-size;position-try-fallbacks:self-block-start span-self-inline-end,self-block-end span-self-inline-start,self-block-start span-self-inline-start;/* Not part of the spec, but it's something Chrome does, so I've included it */min-block-size: 1lh;}
::picker(select) {margin: 0;inset: auto;min-inline-size: anchor-size(self-inline);max-block-size: stretch;position-area: self-block-end span-self-inline-end;position-try-order: most-block-size;position-try-fallbacks:self-block-start span-self-inline-end,self-block-end span-self-inline-start,self-block-start span-self-inline-start;/* Not part of the spec, but it's something Chrome does, so I've included it */min-block-size: 1lh;}
As a result:
min-inline-size means the picker will always be at least as wide as the <select> button (or toggle button in this case).
max-block-size means the picker will not overflow the viewport. Its stretch size is the full anchor positioning cell (the area from the edge of the <select> button to the edge of the viewport).
position-area defines the default anchor positioning cell to use, which is below the <select> button, and from its left edge to the right edge of the viewport.
position-try-fallbacks defines fallbacks for the anchor positioning cell, so it can appear above the <select> button, and/or clamp to the button's right edge.
position-try-order means the picker will initially appear in the anchor positioning cell that offers it the most-block-size, which means vertical space in this writing-mode. This doesn't currently work in Firefox (ticket) or Safari (ticket), as it wasn't clear in the spec.
This is a reasonable set of defaults, but I think there are a number of things we can do to improve the UX.
Right now the picker extends to the edge of the viewport, making it hard to tell if it's actually stopping there, or if it's overflowing the viewport. The only visual clue is the small border & rounded corners.
Remember when I said pickers have max-block-size: stretch? Well, Firefox doesn't support that, so I threw in max-block-size: 100% as a fallback. However, with percent heights, margins don't take away from the height, so the picker still hits the viewport edge, and the margin is outside it.
Now, for Firefox, we're deducting the margin from the 100% max-block-size. For browsers that support stretch, we stick with the previous solution.
And here's the result:
It even does the right thing when the picker flips above the button! So… why am I not using this solution for the other browsers? Well, there's a slight imperfection with how the percent-based solution behaves. See if you can spot it - I'll come back to it later.
We need to fix the margin when the picker flips above the button. Now, there's a feature called anchored container queries which lets us apply different styles when the anchored item flips position, but it isn't supported in Safari. Thankfully, there's an even better solution that Safari does support. Watch this…
This replaces the UA default position-try-fallbacks, which were specific about the positioning, with these flip-* values that achieve the same thing. However, the flip-* values come with dark magic.
When the flips take effect, it tries to flip other styles too. This works with some properties, but not others. Here's the spec, good luck!
Margins are among the things it does work for, so when the picker flips above the button, our margin-block-end is treated as a margin-block-start. Spooky, yet convenient!
If you open the picker and drag it to the viewport edge, it gets really really small - unusably small, before it flips position. Chrome sets a default min-block-size of 1lh, so let's just make that bigger!
When the picker has only a few options, its full size is smaller than our minimum, so it looks kinda bad.
What we want is for our minimum size to be like min(fit-content, 12em), but min() doesn't allow intrinsic sizes like fit-content. Enter calc-size() - this was the bit Ian Kilpatrick unlocked for me:
calc-size() lets us state an intrinsic size in the first argument, then perform a calculation with it in the second argument, where the size keyword represents the intrinsic size. Yeah, it's a little weird, but it works! Well, it works in Chrome. It isn't yet supported in Firefox (ticket) or Safari (ticket), so we can use a bit of a hack in the meantime:
.custom-select::picker(select) {--min-size: 12em;min-block-size: var(--min-size);/* The calc-size way… */@supports (min-block-size: calc-size(fit-content,min(size, 1px))) {min-block-size: calc-size(fit-content,min(size, var(--min-size)));}/* The hacky fallback… */@supports not (min-block-size: calc-size(fit-content,min(size, 1px))) {&:not(:has(:where(option:nth-of-type(4))),:has(:where(optgroup:nth-of-type(2)))) {min-block-size: 0;max-block-size: fit-content;}}}
.custom-select::picker(select) {--min-size: 12em;min-block-size: var(--min-size);/* The calc-size way… */@supports (min-block-size: calc-size(fit-content,min(size, 1px))) {min-block-size: calc-size(fit-content,min(size, var(--min-size)));}/* The hacky fallback… */@supports not (min-block-size: calc-size(fit-content,min(size, 1px))) {&:not(:has(:where(option:nth-of-type(4))),:has(:where(optgroup:nth-of-type(2)))) {min-block-size: 0;max-block-size: fit-content;}}}
.custom-select::picker(select) {--min-size: 12em;min-block-size: var(--min-size);/* The calc-size way… */@supports (min-block-size: calc-size(fit-content, min(size, 1px))) {min-block-size: calc-size(fit-content,min(size, var(--min-size)));}/* The hacky fallback… */@supports not (min-block-size: calc-size(fit-content, min(size, 1px))) {&:not(:has(:where(option:nth-of-type(4))),:has(:where(optgroup:nth-of-type(2)))) {min-block-size: 0;max-block-size: fit-content;}}}
.custom-select::picker(select) {--min-size: 12em;min-block-size: var(--min-size);/* The calc-size way… */@supports (min-block-size: calc-size(fit-content, min(size, 1px))) {min-block-size: calc-size(fit-content, min(size, var(--min-size)));}/* The hacky fallback… */@supports not (min-block-size: calc-size(fit-content, min(size, 1px))) {&:not(:has(:where(option:nth-of-type(4))),:has(:where(optgroup:nth-of-type(2)))) {min-block-size: 0;max-block-size: fit-content;}}}
Ok, that's a lot. Here's what it's doing:
Set a minimum block size of 12em from --min-size.
If calc-size() is supported, use it as before.
Otherwise, if the picker has fewer than 4 options and fewer than 2 optgroups, remove the minimum block size, and prevent it from shrinking when it hits the edge of the viewport.
The last issue to tackle is preventing the picker from getting too big. Right now, it will always grow to fill the anchor positioning cell, which can end up feeling too tall. To solve this, we set a maximum.
However, we already used max-block-size to stop the picker hitting the edge of the viewport, so we need to use min() to allow for two max-sizes. One of the max sizes is max-block-size: stretch, so we need to use calc-size() again, which allows the intrinsic stretch size to be used in the min() calculation.
Because we're using calc-size() for the fix, which isn't supported in Safari, Safari is now using the 100% fallback as well as Firefox, which is almost perfect, but not quite. Have you spotted the imperfection? Here's the issue:
Once we get to the minimum height, the picker will move towards the edge of the viewport before flipping, whereas in Chrome which uses calc-size() + stretch, it flips as soon as it hits the minimum height. It's a minor thing, but it'll be nicer when all browsers support calc-size().
Here's the full CSS for the picker, which adds the margin to the viewport, applies a minimum size, and a maximum size, all in one place to copy-paste and for LLMs to steal:
This doesn't work in the current version of Safari (26.5), but it does work in Safari Technology Preview, so it should be supported by the time Safari ships custom select.
If the CSS above looks scary, it's mostly due to fallbacks for things browsers don't support yet, and a workaround for something the CSS Working Group will change. Eventually we'll be able to do the same thing with:
Well, not quite. The way the picker reacts to scrolling seems weird to me, and it's inconsistent across browsers and devices. I've filed a CSSWG issue to discuss it, because none of the behaviours seem right to me.
]]><![CDATA[Importing vs fetching JSON]]>https://jakearchibald.com/2025/importing-vs-fetching-json/2025-10-22T01:00:00.000ZThis year, JSON module imports became baseline 'newly available', meaning they're implemented across browser engines.
import data from'./data.json'with{type:'json'};// And…const{default: data }=awaitimport('./data.json',{with:{type:'json'},});
I'm glad JavaScript has this feature, but I can't see myself using it in a browser environment, other than small demos. I might still use it in frontend source code, but generally only in cases where it'd be bundled away before reaching the browser.
It comes down to the behaviour differences compared to this:
const response =awaitfetch('./data.json');const data =await response.json();
If the above fails, it takes the whole module graph down with it. Because of this, I'd never use this pattern with some third-party JSON, as I'd want to be able to provide a fallback if the third-party service fails.
But import() allows exactly that:
try{const{default: data }=awaitimport(url,{with:{type:'json'},});}catch(error){// Fallback logic}
This is pretty good. Although the fetch() alternative:
try{const response =awaitfetch('./data.json');const data =await response.json();}catch(error){// Fallback logic}
…allows much more introspection in event of a failure. There's response.status, or you can use response.text(), meaning you still have the source if JSON parsing fails. Maybe that doesn't matter in all cases.
When you import a module (be it JS, WASM, CSS, or JSON), it's cached for the lifetime of the environment (e.g. a page or worker), even if the result is a network or parsing failure. All imports for a given specifier & type return the same module.
This is generally a good thing, as it means your JS module returns the same objects every time, and state can be shared across all importers. But if you're doing something like:
…then you have a memory leak, because each set of search results will live in the module graph for the life of the page. That isn't the case with fetch(), where returned objects can be garbage collected once they're out of reference.
If the above used fetch(), then the data other than someSmallPart could be garbage collected. But with import(), the whole largeData object remains in memory for the life of the page.
It makes sense to use JSON module imports for local static JSON resources where you need all/most of the data within. Particularly since bundlers can understand JSON imports, and bundle the object with other modules. That isn't possible with fetch(), unless you use some pretty hacky plugins.
In server code, I might import package.json to get the version number. However, I wouldn't do this with frontend code, as it's wasteful to bundle all of package.json just to get a single value – bundlers don't perform tree-shaking of individual object keys.
Update:Jed and leah point out, many bundlers (esbuild, Vite, and Rollup at least) will expose top level keys as individual exports if you use their non-standard JSON import syntax.
// No treeshakingimport data from'./package.json'assert{type:'json'};
console.log(data.version);// No treeshakingimport data from'./package.json';
console.log(data.version);// Treeshaking works!import{ version }from'./package.json';
console.log(version);
This only tree-shakes the top-level keys, so if your data is deeply nested, you're still bundling more than you need. Generally, I try to turn any "fetch-and-process" logic into a Vite/Rollup plugin, so it happens at build time rather than runtime.
I'm glad native JSON importing feature exists, but it should be used with care, and not as a blanket replacement for fetch()ing JSON.
]]><![CDATA[The present and potential future of progressive image rendering]]>https://jakearchibald.com/2025/present-and-future-of-progressive-image-rendering/2025-10-15T01:00:00.000ZProgressive image formats allow the decoder to create a partial rendering when only part of the image resource is available. Sometimes it's part of the image, and sometimes it's a low quality/resolution version of the image. I've been digging into it recently, and I think there are some common misconceptions, and I'd like to see a more pragmatic solution from AVIF.
Let's dive straight into the kinds of progressive rendering that are currently available natively in browsers.
Here's the image I'm going to use for comparison, and you'll be sick of seeing it by the end of the article:
Due to its high resolution (1598x1753), and sharp detail, it's 155 kB, even using AVIF.
I created similarly file-sized versions of the image in other formats to compare when they start to render, and when they show enough detail to identify it as a fox in woodland
You get a top-to-bottom low resolution render that starts around 1.2 kB in, and it finishes its first pass at around 33 kB (21% of the file size). Interestingly, that looks different in Firefox and Chromium-based browsers compared to Safari:
In both cases you can tell what the image is, but the Safari rendering is blocky, whereas Firefox and Chromium are smoothed. I much prefer the Firefox/Chromium rendering.
After that, the resolution is improved over multiple passes.
With JPEG, progressive rendering seems to be free in terms of quality/size, but it isn't free in terms of decoding time. Here's another little web app, this one benchmarks image decoding in the browser. Comparing progressive JPEG with non-progressive JPEG, the progressive JPEG takes around 40% longer to decode, but on my M4 pro that's only about 1.3ms, which seems like a reasonable trade-off.
In Firefox and Chrome, WebP renders from top to bottom. It also takes around 43 kB (28%) before it renders anything. I guess the start of the file contains the colour data, so it can only render progressively as it starts receiving the final luma channel.
Unfortunately, Safari doesn't perform any progressive rendering of WebP. It doesn't render anything until it has the whole file.
Update: Since I posted this article, progressive support in AVIF has been massively improved. You can now provide progressive up to three progressive frames, processed in whatever way you want, and fractionally scaled. I intend to post more on this in future.
Regular AVIF doesn't support any kind of progressive rendering. You get nothing, then you get the whole image (demo).
But, AVIF does have a little-known progressive rendering feature! I couldn't get good results with the --progressive flag it offers, but I got something interesting with the lower level --layered flag. It's experimental, and I had to compile libavif myself to get it working. Here's the command I used:
This creates two layers, one at 1/8th resolution and 'minimum' quality, and one at full resolution and good quality. These layers work similarly to frames of a video, with the second layer using data from the first to save space (a P-frame in video terms).
Here's a demo. It only progressively renders in Chromium browsers. You get two renders: the full image when all the data has been received, and an earlier render at ~5.8 kB (4% of the data):
It looks… bad, but you can tell what it is, and it's pretty good for ~5.8 kB.
The downside is, something odd happens with the quality option when you use --layered mode. It doesn't equate to the same numbers as normal AVIF encoding.
Also, there seems to be some overhead in terms of file size, but it's hard to measure. From playing around with MS-SSIM, it seems to be in the region of 5-6 kB, so… the size of the initial pass.
The configuration of layers I used is just one example, but it seems pretty limited. Only particular scaling values are allowed, and 1/8 is the smallest. Supposedly, additional layers are possible, allowing for extra steps in the progressive render, but whenever I tried this, the encoder would error out, or explode the file size to ~400 kB, even at lowest quality. I guess that's why it's marked 'experimental'.
In terms of decoding time, here's progressive AVIF vs regular AVIF. In Firefox and Safari, the decoding time for progressive is about 1-2% longer. In Chrome it takes ~40% longer, which is 3.5ms on my M4 Pro. My guess is that Chrome is missing a fast-path for cases where it doesn't need to render the first layer.
If you ask web developers why they want JPEG XL (as I did on bluesky and mastodon), almost everyone mentions progressive rendering. Given that, I was surprised that Safari (the only browser to support JPEG XL) doesn't perform any kind of progressive rendering. Here's a demo, and a bug report.
I was also surprised to see that, in Safari, JPEG XL takes 150% longer (as in 2.5x) to decode vs an equivalent AVIF. That's 17ms longer on my M4 Pro. Apple hardware tends to be high-end, but this could still be significant. This isn't related to progressive rendering; the decoder is just slow. There's some suggestion that the Apple implementation is running on a single core, so maybe there's room for improvement.
JPEG XL support in Safari actually comes from the underlying OS rather than the browser. My guess is that Apple is considering using JPEG XL for iPhone photo storage rather than HEIC, and JPEG XL's inclusion in the browser is a bit of an afterthought. I'm just guessing though.
The implementation that was in Chromium behind a flag did support progressive rendering to some degree, but it didn't render anything until ~60 kB (39% of the file). The rendering is similar to the initial JPEG rendering above, but takes much more image data to get there. This is a weakness in the decoder rather than the format itself. I'll dive into what JPEG XL is capable of shortly.
I also tested the performance of the old behind-a-flag Chromium JPEG XL decoder, and it's over 500% slower (6x) to decode than AVIF. The old behind-a-flag Firefox JPEG XL decoder is about as slow as the Safari decoder. It's not fair to judge the performance of experimental unreleased things, but I was kinda hoping one of these would suggest that the Safari implementation was an outlier.
I thought that "fast decoding" was one of the selling points of JPEG XL over AVIF, but now I'm not so sure.
Thanks to modern image formats (AVIF in this case), the above image is 56.4 kB. That's pretty incredible for a more-than-HD image. The fox image is much larger because of its sharp details, but that isn't true for most images. This means that, for many images, there's little benefit to progressive rendering.
Congestion and bufferbloat make data arrive in laggy bursts rather than slowly. Very bad signal strength also tends to be on/off.
This means that even if it takes 5 seconds to receive the image, it's unlikely that 155 kB will be received gradually throughout that period. I'm currently on aeroplane WiFi, and yeah… most of the slowness is while nothing is being received.
That means seeing a progressive render requires a particular mix of good and bad luck:
Bad luck: your connection isn't great, so it's taking a while to fetch the whole image.
Good luck: a portion of the image has been received.
Progressive rendering is a good experience when you hit this (not-)sweet spot, but you might not get to see it even on slow connections. It certainly isn't an alternative to taking care over your image sizes.
Because of this, it feels like encoding an image in a way that enables a progressive render should be minimal cost in terms of file size overhead, and minimal/zero cost in decoding overhead in cases where progressive isn't needed.
I know that's a weak 'story'. When I set about writing this article, I intended it to be a strong argument for progressive rendering. But after digging into it, my feelings are less certain.
When I asked folks why they're interested in JPEG XL, some folks suggested it would enable them to replace responsive images with a single maximum-resolution JPEG XL file. The idea is:
The browser receives some image data.
The browser performs a partial decode of the image data.
The browser realises it doesn't need any more pixel density.
The browser tells the server "stop sending me this resource".
The server dutifully stops sending the resource.
I'm sorry to be the bad news guy, but I'm pretty certain this won't work.
The problem is there's significant lag between each of these steps, to the point where it's very likely that you'll receive megabytes of data you don't need, per image, before the response is successfully cancelled.
It might be workable along with a new browser feature, where the ranges are known up-front, so the browser can make the required partial request:
But even if we get this #range= feature (and there are some big questions around CORS that could make it a no-go), the complexity is about the same as responsive images today, and with responsive images you get more control over the available resolutions.
I guess an advantage of the 'range' approach is the browser could 'resume' the image download if it later finds it needs a higher resolution, such as going from thumbnail to full-screen. But even given that, current responsive images seem more versatile.
Aside from browser decoders, there's some promising work in progressive rendering of JPEG XL. However, it's unclear how much of it could make it into browsers, and the encoder settings are a little confusing.
The current version of cjxl (0.11.1) has a --progressive flag, but this creates a file that can't be rendered until a significant amount of the file has been received (39% of the file with the fox image).
To get an earlier render, you need to use --progressive_dc 1, which cjxl --help doesn't mention. You only get to find out about it if you use the verbose flag, twice: cjxl --help -v -v. It seems like this has been changed in the codebase, where --progressive now implies progressive_dc 1, but that hasn't made it into a release yet.
It doesn't seem like progressive_dc has an impact on file size. If it does, it's small. I haven't seen a difference in decode time either (from testing in Safari), but JPEG XL decoding is slow in general, so it isn't a huge win.
djxl doesn't support the earlier rendering that --progressive_dc offers, but there's also a Rust-based decoder, jxl-oxide, which can handle earlier rendering.
I'd say that the 6 kB mark gives you a decent impression of the image, and things get really clear around 46 kB. It could use some smoothing, like we saw with the JPEG progressive render in Firefox/Chrome.
After the 60 kB mark, the full detail appears in square blocks. A nice feature of JPEG XL is these can appear in any order, so you can see in the 68 kB render that sharpness appears around the fox's face before anywhere else. cjxl lets you specify a point to use as the "center", but a smarter encoder could detect things like faces and prioritise them.
It's subjective, but I'd say the 5.8 kB AVIF progressive render from earlier is, detail-wise, somewhere between the 17-27 kB JPEG XL renders, but make up your own mind:
So if the browser manages to download 6 kB then stalls, then AVIF can produce a better result. But since the AVIF rendering is only two-pass, if the browser has say 50 kB, then the JPEG XL rendering is much better.
This is all just 'in theory' until it becomes fast enough to land in a browser.
There's another JPEG XL rust decoder jxl-rs, being developed for Firefox. That team are also exploring how progressive rendering could work.
This article got longer than I expected, but one last thing…
Update: Since I posted this article, progressive support in AVIF has been massively improved. You can now provide progressive up to three progressive frames, processed in whatever way you want, and fractionally scaled. I intend to post more on this in future.
In my experience AVIF results in smaller files at what I'd consider 'web quality' compared to JPEG XL (particularly when optimising for high-density). And based on current implementations, AVIF decodes significantly quicker than JPEG XL. Smaller files and faster decode is a huge advantage, but that said, I'd like AVIF to have a better 'progressive' feature. It'd be great if it supported an early render that allows more control over the quality and scale of the initial pass, and ideally a configurable post-process blur effect to hide compression artefacts.
Maybe the 'layers' approach can be improved. Or maybe it's an over-complication. For example:
The above image is 1.97 kB. It's scaled down, compressed with AVIF at minimum quality, and has a post-process blur applied.
With the blur applied, I think this works great as a preview. So could this… just go at the start of the full image file?
This means the 'preview' is 100% overhead in terms of file size, but it also means as web developers, we can freely configure the quality of this 'preview' by deciding how much overhead we find acceptable. Maybe I'm being too conservative by only spending 1.97 kB, rather than, say, 10 kB:
And because it's an entirely separate image, the decoding overhead is zero if the browser doesn't see a benefit to displaying the preview. As in, in cases where the browser has the whole file, it can just skip the preview.
The post-process blur would need to be part of the format, rather than left to something like CSS. This would allow the format to use a 'cheap' blur filter, avoiding expensive rendering costs.
]]><![CDATA[Fetch streams are great, but not for measuring upload/download progress]]>https://jakearchibald.com/2025/fetch-streams-not-for-progress/2025-09-15T01:00:00.000ZPart of my role at Mozilla is making sure we're focusing on the right features, and we got onto the topic of fetch upload streams. It's something Chrome has supported for a while, but it isn't yet supported in either Firefox or Safari.
I asked folks on varioussocialplatforms what they thought of the feature, and what they'd use it for. The most common answer by far was "to measure upload progress", but… using it for that will give inaccurate results, and may even lead to bad implementations in browsers.
The good part is that you're measuring the point at which you have the data, which is what matters when it comes to download. Let's say you were receiving three packages via mail – you're measuring the point each package arrives in your possession, which is fine.
However, this all falls down if the response has a Content-Encoding (such as brotli or gzip), because in that case the Content-Length represents the encoded size, but the chunks are decoded chunks. This means your downloaded value is likely to exceed the contentLength value.
Request streams are basically the same as response streams, but for uploads rather than downloads. Imagine a video uploading app that did some transcoding/processing of the video before uploading:
// Get a video from disk, or from the cameraconst videoStream =getVideoStreamSomehow();// Process it in some way, e.g. editing or transcodingconst processedVideo = videoStream.pipeThrough(newSomeVideoProcessor());// Upload the streamawaitfetch(url,{method:'POST',body: processedVideo,duplex:'half',headers:{'Content-Type':'video/mp4',},});
In this model, the video processing can happen in parallel with the uploading. More traditional methods would require processing the whole video before the upload begins, which is potentially much slower.
duplex: 'half' means that the request must complete before the response becomes available. This 'reserves' a future feature where browsers can support handling the request and response in parallel.
If you want to have a request and response in parallel, you can perform two fetches – one that streams request data, and another that streams response data.
Also, since the Content-Length of the request isn't known, the feature is restricted to transports that are already used to handling request data in chunks, which is HTTP/2 onwards.
I'm not even going to show the code for this because it's too unreliable.
With request streams, you end up measuring the point at which the data is taken from your stream. In terms of the postal metaphor, you're measuring the point each package is collected by the courier, which does not represent the delivery of those packages.
Fetch is the courier. It will take some chunks off your hands and start handling the network parts. Successfully sending those chunks will happen later, or maybe it will fail.
This is normal behaviour with streams, and it helps keep everything running as smoothly as possible in cases where parts of the pipe flow quicker than others. Each stream has a "high water mark", which is essentially an ideal amount to buffer.
If you try to use streams to measure upload progress, the results will be inaccurate, but it may also limit the quality of this feature in future.
Let's say browsers ship this, and do a fairly small amount of buffering. If folks use this for upload progress, it won't be right, but it might be close enough.
Then let's say a browser discovers that they can get better performance by buffering more within fetch. If large parts of the web are using this feature for upload progress, that browser faces two choices: Ship the change, which means these websites' upload progress measurements become even less accurate, or avoid shipping the general improvement. I don't want browsers to end up having to make a compromise here.
This should give us all the modern benefits of fetch, while plugging the progress feature gap!
If you're interested in using request streams for things other than progress events, there's an Interop 2026 proposal for them. We also want to gauge developer interest via this survey, or via the interop GitHub thread.
]]><![CDATA[Making XML human-readable without XSLT]]>https://jakearchibald.com/2025/making-xml-human-readable-without-xslt/2025-09-02T01:00:00.000ZOk. This one is niche. But heh, you might enjoy a dive into this esoteric corner of the web – I certainly did.
This leaves browsers with a choice: Take development time away from features that have significant usage and developer demand, and instead use those resources to improve (probably rewrite) XSLT processing in browsers. Or, remove XSLT from browser engines.
Now you can style your XML document using regular CSS. Just make sure your document is served with Content-Type: text/xml (rather than, e.g. a more specific RSS content type), otherwise the browser won't use the styles.
What you can do here is pretty limited. In the XSLT example, I take the text content of the <cover> element, and make it the src of an image. I also repeat the author's <name> for each book. Neither of these is possible with CSS alone.
Also, the document will have the semantics of the XML document, which likely means "no semantics", so the result will have poor accessibility. For example, even if your XML contains <h1>, unless you've told it to be an HTML element, the browser won't recognise it as a heading.
That said, if you just want to catch users that mistakenly land on some XML, you can get away with something like this:
:root{& > *{display: none;}&::before{content:'Hi there! This is my RSS feed. '"It isn't meant to be human-readable…";}}
In almost all cases, the best thing to do is convert your data to HTML on the server, or as part of a build process. When you do that:
The HTML form of your data is more likely to be seen by crawlers and scrapers.
The browser can render the page in a streaming way, meaning a faster experience for users.
You can use whatever tools you like to do the transformation – you aren't limited to things the browser supports natively.
This might mean you end up with two published files, one for humans (as HTML), and one for machines (as XML or whatever). This is fine. My blog posts and my RSS feed are different resources, even though they have data in common. All my posts have this in the head:
If you just want to make some existing XSLT work in browsers that don't support it, check out Mason's XSLT polyfill. But if you don't need to use XSLT, JavaScript is, in my opinion, a better option.
Here's a demo that produces the same result as the XSLT demo, but this time using JS. Here's how it works…
In the XML, instead of including XSLT, I include a script as the first child of the root:
The xmlns attribute is important, as it tells the browser this is an HTML script element, rather than some other kind of XML element.
Technically, this is changing the data structure. Validating parsers would see a <script> they weren't expecting, and throw an error. However, most parsers are not validating, as they want to allow for extensions to whatever format they're reading.
Then, in that script:
// Get the XML dataconst data = document.documentElement;// Create an HTML root elementconst htmlEl = document.createElementNS('http://www.w3.org/1999/xhtml','html',);// Swap the two over
data.replaceWith(htmlEl);
Now all I had to do was populate that html element. I created a simple templating function to handle escaping. For example, here's the snippet that renders each book:
One gotcha when creating HTML in an XML document is it's easy to accidentally create XML elements rather than HTML elements. If you want proper semantics, accessibility, and behaviour, you want real HTML elements.
For example:
// In an XML document this will not create an HTML element:const xmlElement = document.createElement('h1');// Instead, you need to use:const htmlElement = document.createElementNS('http://www.w3.org/1999/xhtml','h1',);
If you're using a framework to create the elements, check that it's creating real HTML elements – el.namespaceURI should be "http://www.w3.org/1999/xhtml".
The xmlns attribute we used earlier only works via the parser, so this doesn't create an HTML element in an XML document:
You, the reader, encounter a tiny number2 within some prose. This indicates to you that I, the writer, have something more to say on this topic. And, for your inconvenience, I've put it way down at the bottom of the page.
The choice is yours: do you skip over it, and stay in the flow of the article, or do you set off on a side-quest to discover the extra wisdom I have to offer?
It's like one of those "choose your own adventure" books, except you know the destination is a dead-end, meaning you'll have to re-trace your steps so you can continue the main thread of the article.
Maybe if you know me well enough, you can be in tune with the kinds of things that I'd choose to leave in a footnote, and you can make some kind of judgement on whether it's likely to be worth your time. But since this is the first time I've used footnotes in an article3, you don't really have anything to go on. All that little 3 tells you is that there's some additional content that may or may not be contextually useful to you, and that it's the third time I've done this to you.
Whether you go out of your way to read the footnote content is really just a test of your curiosity.
If you did make your way down to the footnotes, I hope you appreciated that I set the text size to be a little smaller than the 'ideal' size that I chose for the main body content, making them harder to read, such is the tradition within the footnote community.
And if you enjoyed all of that, I have great news for you: many people bring this experience to the world wide web.
If reproduced as-is, footnotes on the web are even worse than their printed counterparts. In print, the footnotes are usually at the bottom of the current page, so they're a quick glance away, and you can use a finger to mark your place in the main text while you're off on your side-quest. Whereas on this beautiful pageless web of ours, you have to scroll all the way down to the end of the article. You can try flinging right to the bottom of the document, but if there's a sizeable footer or comments section, you'll overshoot the footnotes. And of course, after all of this, you have to scroll back to where you were, which is easier said than done.
However, most webby footnoters have realised that in the printed world, the numbering of footnotes is used to manually link the primary content to the supplemental content, and the web has a dedicated feature to enhance connections like this: hyperlinks4.
Of course, with footnotes being at the bottom of the article, sometimes these links will simply take you to the end of the document, so you'll still have to visually scan for the pertinent footnote5.
If the footnote markers are links, then the user can use the back button/gesture to return to the main content. But, even though this restores the previous scroll position, the user is still left with the challenge of finding their previous place in a wall of text6.
We could try to solve that problem by dynamically pulling the content from the footnotes and displaying it in a popover. In some browsers that will display like a tooltip, pointing directly back to the footnote marker. Thanks to modern web features, this can be done entirely without JavaScript.
But this is still shit! I see good, smart people, who'd always avoid using "click here" as link text, littering their articles with link texts such as 1, 7, and sometimes even 12. Not only is this as contextless as "click here", it also provides the extra frustration of a tiny-weeny hit target.
And all this for what? To cargo-cult academia? Stop it! Stop it now! Footnotes are a shitty hack built on the limitations of printed media. It's dumb to build on top of those limitations when they don't exist on the web platform. So I ask you to break free of footnotes and do something better.
Honestly, if you've got a quick little aside, just pop it in parentheses. If the reader really wants to skip it, scanning for the next closing parenthesis is pretty easy (unless you're nesting them – don't do that), and it keeps the reader in the flow of the article.
I thought the <aside> element would be ideal for this, but that uses the complementary role which doesn't seem like a good fit for this kind of content. Whereas the note role is specifically for "parenthetic or ancillary content", which sounds perfect.
The heading makes the topic of the note clear, and since the content is semantically and visually contained, it's easy to skip over.
Like the note section, the summary makes the topic of the details clear, and since the content is semantically and visually contained, it's easy to skip over. The benefit with <details> is the user doesn't have to scroll past lots of content if they're not interested.
I'm not a UX designer, so maybe you can think of better patterns. But if the alternative is footnotes, the bar is lowwwww.
I've really enjoyed the reasoned feedback to this post. Particularly those from Lea Verou, and Stuart Langridge. I recommend reading them in full (and also try a 'chello-bull for yourself), but I want to respond to the general sentiment that the alternatives are too disruptive.
Let's take my parenthetical example:
Honestly, if you've got a quick little aside, just pop it in parentheses. If the reader really wants to skip it, scanning for the next closing parenthesis is pretty easy (unless you're nesting them – don't do that), and it keeps the reader in the flow of the article.
Where the user experience is:
Read "scanning for the next closing parenthesis is pretty easy".
Read "(unless you're nesting them".
Then one of the following:
Read " – don't do that)".
Or, if you've become disinterested in this supplementary information, scan along to ")".
Continue reading.
And compare it to the popover-footnote experience:
Honestly, if you've got a quick little aside, just pop it in parentheses. If the reader really wants to skip it, scanning for the next closing parenthesis is pretty easy, and it keeps the reader in the flow of the article.
Where the user experience is:
Read "scanning for the next closing parenthesis is pretty easy8".
Decide, given no real clue as to the content of the footnote, to do one of the following:
Explore, by clicking the 8:
Read "Unless you're nesting them – don't do that."
Click outside the popover.
Continue reading.
Or, skip over the 8.
Continue reading.
Hopefully it's clear from the above that the simple parentheses solution is less disruptive, except maybe in the case where the reader is by-default disinterested in the extra content. And that's where the argument loses me.
Why are you optimising the reading experience for people disinterested in your content? Like, if the content is really that pointless, don't put it in the article – that's even less disruptive! But, if you've got something interesting to say, say it in context. If it's really optional, make it easy for readers to skip it once they realise it's not for them. Skipping over less-relevant content is a normal part of reading. We don't need to over-engineer it.
What about sidenotes?
One of the footnote patterns I didn't explore were sidenotes, which only really work on desktop. But the disruption is similar. You see the superscript, and then you have to find the related sidenote (which is especially annoying in implementations that Math.random() the note to either the left or right), then visually find your way back to the main content.
All that said, I will admit I was really pleased with the no-JS popover footnotes when I got them working (although they're Chromium-only right now). But, I think that might be more down to the excitement of playing with a new CSS feature for the first time. Oh, on the topic of CSS anchors, my advice is to ignore position-area, which included too much magic for me to figure out, and instead use anchor(). Although your mileage may vary.
You'll be glad to hear my new job starts in August, so I won't have as much time to waste on posts like this.
There. I hope you're happy.
]]>
<![CDATA[Animating zooming using CSS: transform order is important… sometimes]]>https://jakearchibald.com/2025/animating-zooming/2025-06-17T01:00:00.000ZI was using Discord the other day. I tapped to zoom into an image, and it animated in an odd way that I'd seen before. Like this:
Notice how it kinda 'swoops' into the wildcat's face, rather than zooming straight in? See how the right-hand side of the cat's head goes out-of-frame, and then back in again?
I recognised it immediately because I'd made the same mistake myself on another project.
Weird, huh? You wouldn't expect something like rotate(0), which is equivalent to none, to completely change how the animation works, but this is happening entirely as designed in the CSS spec.
When zooming into part of an element, scale(n) translate(x, y) feels like the easiest way to do it. You use the translate to get the subject into the centre, then adjust the scale to zoom in. Tweaking the values in DevTools is easy, as is calculating the values in code.
However, while this order of values is easy to write, it doesn't produce the most natural animation.
Now that the transforms are in a similar format, it produces an animation that linearly interpolates each component separately. This means that the scale is animated linearly from 1 to 3, and the translate is animated linearly from 0, 0 to -33.1%, 20.2%.
The animation itself isn't linear, as easing is applied, but linear interpolation is used as a starting point.
The problem is, with scale followed by translate, the scale acts as a multiplier for the translate values. Therefore, as the scale increases, even though the translate values are interpolated linearly, the effect is non-linear:
At the start of the animation, a 1px shift in the translate value results in a ~1px shift on screen, as the scale is ~1. But, towards the end of the animation, a 1px shift in the translate value results in a ~3px shift on screen, as the scale is ~3. The position appears to change faster towards the end of the animation, which creates the 'swooping' effect.
To fix this, we need to avoid the scale acting as a multiplier for the translate, and the way to do this is to put the translate first.
We can't just swap the order, since we're relying on the multiplying effect of the scale to make the translate do the right thing. To achieve the same effect, we need to manually multiply the translate values by the scale value:
Although the translate values are still multiplied, they're multiplied by a constant 3, the end scale, rather than a changing scale value. The result is a steady move towards the target. Each 1px shift in the translate value results in a 1px shift on screen.
Unfortunately, this format is harder to tweak in DevTools, but you can fix that with a bit of calc!
Even though the scale and translate are in the wrong order, we get the animation we want. What gives? Well, I don't actually recommend using this 'fix', because it only 'works' by hitting an edge case in the CSS spec.
Let's go through the algorithm again, but this time with the rotate(0) transform:
Then, as before, it tries to convert each component pair to use a common function that can express both types of value. However, it can't. rotate and scale are considered too different to be converted into a common type.
When this happens, it 'recovers' by converting those values, and all following values, to a single matrix:
And then it animates them as it would two matrices. The 'incorrect' order of the scale and translate is lost, and the translate is already pre-multiplied by the scale. By coincidence, it animates exactly the way we want it to.
In this article, we've been animating scale to achieve the effect of 'zooming in'. But, depending on the effect you want, you could use a 3D translate instead.
When you animate scale, the result is that the width and height of the target changes linearly throughout the animation (although, as before, easing can be applied). This feels similar to a camera zoom effect.
However, you may want an effect that's more like the object moving towards the camera, or the camera moving towards the object. To achieve this, you don't want the visual size of the object to change linearly.
This is because, when a far-away object moves by 1 metre, the amount of space it takes up in your field of view doesn't change much. But, when a close-up object moves by 1 metre, the amount of space it takes up in your field of view changes a lot. This is the effect of perspective.
So, instead of using scale, let's use the perspective property, and a 3D transform:
Ok, it's subtle. Here's the scale version again for comparison:
It's mostly noticeable on the zoom-out part of the animation. The 3D version feels like it starts much faster than the scale version. Personally, I think the scale version feels better, since the intention is more of a 'zoom' than a 'move'. But, it's good to know the differences, so you can choose the right one for your desired effect.
Thanks to Ana Rodrigues for feedback that helped this make a lot more sense.
]]><![CDATA[Firefox + custom elements + iframes bug]]>https://jakearchibald.com/2025/firefox-custom-elements-iframes-bug/2025-02-14T01:00:00.000ZOver at Shopify we've been building a bunch of web components to use internally and in third party contexts. All of a sudden, we found some strange errors in our logs, all from Firefox. This is the post I wish existed when we discovered it.
Update: This is now fixed, and should land in Firefox 151.
The bug happens when a custom element (or web component) is moved to a document from another JavaScript Realm [spooky noises]. A Realm is a separate JavaScript context with its own global, own implementation of Array etc etc. An iframe or popup window provides a document in a new JavaScript Realm.
The result of the bug is that the element's custom prototype is lost, and things like instance methods disappear.
Ok ok, sorry, I'm trying to hit all the terms that people might search for to find a fix for this issue. Anyway, here's a simple custom element:
And I'm going to create an instance of the element, and put it in an iframe:
// Create the iframeconst iframe = document.createElement('iframe');
document.body.append(iframe);// Create the element, and put it in the iframeconst myElement = document.createElement('my-element');
iframe.contentDocument.body.append(myElement);
This fails in Firefox with "this.say is not a function", within connectedCallback. In fact, Firefox has lost all of the instance methods of the custom element. It's 'downgraded' to an instance of HTMLElement in the iframe Realm, rather than MyElement.
It's kinda funny, because the error happens within connectedCallback, which is an instance method, but even that instance method has gone. I assume the calling of connectedCallback was queued up before the prototype was lost.
If I put the element in the main document before moving it to the iframe, it fails in disconnectedCallback for the same reason.
The fix is kinda simple. Just… put the prototype back. As in, make it an instance of MyElement again.
classCustomElementBaseextendsHTMLElement{// This is called when the element is moved to a new document.// This is where we solve the bug if the element is moved to an iframe// without first being put into the main document.adoptedCallback(){rescueElementPrototype(this);}// This is called when the element is disconnected from a document.// This happens whenever the element is moved around the DOM,// but it also happens when the element is moved to a new document.// This happens before adoptedCallback,// so we need to fix it here,// to avoid the bug in subclass disconnectedCallback calls.disconnectedCallback(){rescueElementPrototype(this);}}functionrescueElementPrototype(element){// Return if everything looks as expected.if(element instanceofCustomElementBase)return;// Otherwise, get the intended constructor…const constructor = customElements.get(element.tagName.toLowerCase());// …and set the prototype.
Object.setPrototypeOf(element, constructor.prototype);}
Thanks to my colleague Anthony Frehner who realised customElements.get is a simple way to get the original constructor back, rather than the mad WeakMap hack I was using.
Now, make sure your custom elements extend this base class, and ensure you call super methods:
Mastodon
LinkedIn
