import data from './data.json' with { type: 'json' };

// And…

const { default: data } = await import('./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 = await fetch('./data.json');
const data = await response.json();

Here's why…

Error handling

With a static import:

import data from './data.json' with { type: '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 } = await import(url, {
    with: { type: 'json' },
  });
} catch (error) {
  // Fallback logic
}

This is pretty good. Although the fetch() alternative:

try {
  const response = await fetch('./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.

I think the bigger issue is…

Caching and garbage collection

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:

const { default: results } = await import('/api/search?q=whatever', {
  with: { type: 'json' },
});

…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.

The same applies to cases like:

let { default: largeData } = await import('/large-data.json', {
  with: { type: 'json' },
});

const someSmallPart = largeData.slice(0, 10);
largeData = null;

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.

When should JSON modules be used?

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 treeshaking
import data from './package.json' assert { type: 'json' };
console.log(data.version);

// No treeshaking
import 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.

Let's dive straight into the kinds of progressive rendering that are currently available natively in browsers.

The current state of progressive image rendering 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

Let's go!

JPEG

Trusty old JPEG can be encoded in a progressive way, which is the default in Squoosh.

Here's a little web app that lets you test progressive rendering of any image, and here's the app ready-loaded with the JPEG version of the fox image.

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.

PNG

PNG generally renders from top to bottom. There's an interlaced mode, but it significantly increases the file size, so I don't recommend it.

For completion, here's a demo. I had to… umm… modify the image somewhat, in order to bring the file size down to some acceptable level.

WebP

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.

Here's a demo.

AVIF

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:

avifenc -s 0 -y 420 --layered \
  --scaling-mode:u 1/8 -q:u 0 fox.png \
  --scaling-mode:u 1 -q:u 16 fox.png \
  fox-progressive.avif

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.

Here's the issue for tracking progressive rendering of AVIF in Firefox.

JPEG XL

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.

We have a Rust implementation of JPEG XL underway in Firefox, but performance needs to get a lot better before we can land it.

But do we actually benefit from progressive rendering?

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.

But even with the 155 kB fox image, Kornel makes a good point:

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.

What about progressive rendering instead of responsive images?

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:

1. The browser receives some image data.
2. The browser performs a partial decode of the image data.
3. The browser realises it doesn't need any more pixel density.
4. The browser tells the server "stop sending me this resource".
5. 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:

<!-- Made-up example -->
<img
  srcset="
    img.jxl#range=0-10000   200w,
    img.jxl#range=0-30000   400w,
    img.jxl#range=0-70000   800w,
    img.jxl#range=0-150000 1600w
  "
  sizes="…as usual…"
/>

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.

Potential progressive rendering with JPEG XL

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.

jxl-oxide isn't fast enough for browsers, but it's an interesting preview of what's possible. There's also a neat wasm version, that lets you see partial renders. Here's a progressive version of the fox image, if you want to try it yourself. Otherwise, here's a rough guide:

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.

A better 'progressive' feature for AVIF?

This article got longer than I expected, but one last thing…

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.

I originally pitched this idea back in 2020 before the 'layers' idea was explored. But maybe it's time to consider it again. Here's hoping!

I asked folks on various social platforms 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.

Let's dig in…

Response streams

Streaming responses have been available in all browsers for years now:

const response = await fetch(url);
const reader = response.body.getReader();

while (true) {
  const { done, value } = await reader.read();
  if (done) break;
  console.log(value);
}

console.log('Done!');

This lets you get the response chunk-by-chunk, so you can start processing it as you receive it.

This is even easier with async iterators:

const response = await fetch(url);

for await (const chunk of response.body) {
  console.log(chunk);
}

console.log('Done!');

…but that isn't supported in Safari. I've proposed it for interop 2026.

The chunks are Uint8Arrays, but you can use TextDecoderStream to get the chunks as text.

const response = await fetch(url);
const textStream = response.body.pipeThrough(new TextDecoderStream());

But they're not ideal for measuring download progress

You could try to measure download progress like this:

// THIS DOESN'T ALWAYS WORK!
const response = await fetch(url);
const contentLength = Number(response.headers.get('Content-Length')) || 0;
let downloaded = 0;

for await (const chunk of response.body) {
  downloaded += chunk.length;
  if (contentLength) {
    console.log(
      `Downloaded ${((downloaded / contentLength) * 100).toFixed(2)}%`,
    );
  }
}

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.

Although, if you made that mistake, you wouldn't be alone. A few years ago I investigated how browsers handled download progress of compressed resources, and the results were… messy.

There's a feature request for a way to get the raw body, without decompressing.

Request streams

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 camera
const videoStream = getVideoStreamSomehow();
// Process it in some way, e.g. editing or transcoding
const processedVideo = videoStream.pipeThrough(new SomeVideoProcessor());

// Upload the stream
await fetch(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.

Restrictions

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.

But they're bad for measuring upload progress

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.

Using streams to measure upload progress could cause problems in future

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.

How to measure upload progress

Upload and download progress is unfortunately a missing feature in fetch. If you want progress events today, the best way is to use XHR:

const xhr = new XMLHttpRequest();

// Upload progress
xhr.upload.onprogress = (event) => {
  if (event.lengthComputable) {
    console.log(
      `Uploaded ${((event.loaded / event.total) * 100).toFixed(2)}%`,
    );
  }
};

// Download progress
xhr.onprogress = (event) => {
  if (event.lengthComputable) {
    console.log(
      `Downloaded ${((event.loaded / event.total) * 100).toFixed(2)}%`,
    );
  }
};

xhr.open('POST', url);
xhr.send(blobOrWhatever);

But in future…

Luke Warlow from Igalia is currently working on an API for fetch to add progress events for both uploads and downloads.

The API might change before it lands, but right now it looks like this:

const response = await fetch(url, {
  observer(requestObserver, responseObserver) {
    requestObserver.onprogress = (event) => {
      if (event.lengthComputable) {
        console.log(
          `Uploaded ${((event.loaded / event.total) * 100).toFixed(2)}%`,
        );
      }
    };

    responseObserver.onprogress = (event) => {
      if (event.lengthComputable) {
        console.log(
          `Downloaded ${((event.loaded / event.total) * 100).toFixed(2)}%`,
        );
      }
    };
  },
});

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.

XSLT and browser support

I want to get to the technical-fun bits quickly, so here's a quick rundown:

• XSLT is an XML language for transforming XML, including transforming it into non-XML formats, such as HTML.
• Browsers currently support a ~25 year old version of XSLT natively (examples coming up later).
• This feature is barely used. Usage is lower than features that were subsequently removed from browsers, such as mutation events and Flash.
• The feature is often the source of significant security issues.

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.

Currently, Chrome, Safari, and Firefox support removing XSLT.

If you want to know more of the process & history here, I recommend Eric Meyer's blog post.

Right, let's take a look at XSLT and the alternatives.

How XSLT works

Take some XML like this:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="books.xsl"?>
<authors>
  <author>
    <name>Douglas Adams</name>
    <book>
      <title>The Hitchhiker's Guide to the Galaxy</title>
      <genre>Science Fiction Comedy</genre>
      <cover>https://covers.openlibrary.org/b/isbn/0330258648-L.jpg</cover>
    </book>
    <book>
      …
    </book>
    …
  </author>
  <author>
    <name>George Orwell</name>
    <book>
      …
    </book>
  </author>
  …
</authors>

If you visit that document, you'll (for now, at least), see a grid of books, with formatting and images, and that's all down to:

<?xml-stylesheet type="text/xsl" href="books.xsl"?>

…which tells the browser to transform the XML using XSLT.

Here's the full source if you're interested, but here's the snippet that renders each book:

<xsl:template name="book">
  <div class="book">
    <img class="cover" src="{cover}" alt="" />
    <div class="book-info">
      <div>
        <span class="title"><xsl:value-of select="title" /></span>
        -
        <span class="author"><xsl:value-of select="../name" /></span>
      </div>
      <div>
        <span class="genre"><xsl:value-of select="genre" /></span>
      </div>
    </div>
  </div>
</xsl:template>

This template maps a <book> into a <div class="book">, although it reaches up into the parent <author> to get the author name.

I used to write XSLT as part of my first job ~20 years ago. Making this demo felt deeply weird.

Anyway, assuming the above will stop working someday, what are the alternatives?

Styling XML

In some cases, you might get away with just styling XML, which you can do using:

<?xml-stylesheet type="text/css" href="styles.css"?>

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…";
  }
}

Which is what I've done with my RSS feed.

For anything more complex, you need to do some kind of transformation of the source data.

Wait, do you really want to do this client-side?

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:

<link
  rel="alternate"
  type="application/rss+xml"
  title="Jake Archibald's Blog"
  href="https://jakearchibald.com/posts.rss"
/>

…meaning feed readers can find the RSS feed from any post.

But if you really need to, here's how to do the transformation on the client, without XSLT:

Transforming XML client-side without XSLT

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:

<authors>
  <script
    xmlns="http://www.w3.org/1999/xhtml"
    src="script.js"
    defer=""
  />
  …

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 data
const data = document.documentElement;
// Create an HTML root element
const 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:

const bookHTML = (bookEl) => html`
  <div class="book">
    <img
      class="cover"
      src="${bookEl.querySelector(':scope > cover').textContent}"
      alt=""
    />
    <div class="book-info">
      <div>
        <span class="title">
          ${bookEl.querySelector(':scope > title').textContent}
        </span>
        -
        <span class="author">
          ${bookEl.parentNode.querySelector(':scope > name').textContent}
        </span>
      </div>
      <div>
        <span class="genre">
          ${bookEl.querySelector(':scope > genre').textContent}
        </span>
      </div>
    </div>
  </div>
`;

It's very similar to the XSLT equivalent, and it can be debugged using regular JavaScript tooling.

Ensure you're creating HTML elements

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:

const h1 = document.createElement('h1');
h1.setAttribute('xmlns', 'http://www.w3.org/1999/xhtml');

However, innerHTML and setHTMLUnsafe will assume the content is HTML, which is what I used:

htmlEl.setHTMLUnsafe(html`
  <head>
    <title>Some books</title>
    <meta name="viewport" content="width=device-width, initial-scale=1" />
  </head>
  <body>
    <h1>Some books</h1>
    <ul class="book-list">
      ${[...data.querySelectorAll('book')].map(
        (book) => html`<li>${bookHTML(book)}</li>`,
      )}
    </ul>
  </body>
`);

Here's the full working demo, and the source. And that's it! Wow you made it to the end. Huh. I didn't think anyone would.

I hate footnotes¹, and hopefully by the end of this, you will too. Let's get down to it…

The UX of footnotes in printed media

You, the reader, encounter a tiny number² 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 article³, 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.

Footnotes on the 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: hyperlinks⁴.

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 footnote⁵.

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 text⁶.

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 ¹, ⁷, and sometimes even ¹². Not only is this as contextless as "click here", it also provides the extra frustration of a tiny-weeny hit target.

Update: Adrian Roselli pointed out that there are numerous bugs with accessibility tooling and superscript.

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.

Alternatives to footnotes on the web

Here are the goals:

• Provide easily-read supplementary content.
• Let the user easily skip over it if they're not interested.
• Make it easy for the user to decide if they're interested or not.

Given that:

Just, like… parentheses?

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.

A 'note' section

If your content is a little longer, you can use <section role="note"> and style it to look self-contained.

The heading makes the topic of the note clear, and since the content is semantically and visually contained, it's easy to skip over.

A 'details' section

If your content is too long for a note, consider using <details> and <summary>.

:root {
  interpolate-size: allow-keywords;
}

.details-demo {
  &::details-content {
    height: 0;
    overflow: clip;
    display: flow-root;
    transition:
      height 0.5s ease,
      content-visibility 0.5s ease allow-discrete;
  }

  &[open]::details-content {
    height: auto;
  }
}

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.

Update: are my alternatives too disruptive?

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:

1. Read "scanning for the next closing parenthesis is pretty easy".
2. Read "(unless you're nesting them".
3. Then one of the following:
   • Read " – don't do that)".
   • Or, if you've become disinterested in this supplementary information, scan along to ")".
4. 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:

1. Read "scanning for the next closing parenthesis is pretty easy⁸".
2. Decide, given no real clue as to the content of the footnote, to do one of the following:
   • Explore, by clicking the ⁸:
     1. Read "Unless you're nesting them – don't do that."
     2. Click outside the popover.
     3. Continue reading.
   • Or, skip over the ⁸.
3. 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.

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.

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.

The CSS is pretty simple:

.demo {
  transition: transform 1s ease;
}
.demo.zoom {
  transform: scale(3) translate(-33.1%, 20.2%);
}

But watch this… If I change the starting transform from the default (none), to rotate(0):

.demo {
  transition: transform 1s ease;
  transform: rotate(0);
}
.demo.zoom {
  transform: scale(3) translate(-33.1%, 20.2%);
}

The animation changes:

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.

Let's dig into why.

What caused the quirky animation?

Let's remove the rotate(0) for now and go back to the original code:

.demo {
  transition: transform 1s ease;
}
.demo.zoom {
  transform: scale(3) translate(-33.1%, 20.2%);
}

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.

How transforms are animated

The CSS spec has a somewhat complex algorithm to decide how to animate transforms. For our values, it takes the from and to values:

@keyframes computed-keyframes {
  from {
    transform: none;
  }
  to {
    transform: scale(3) translate(-33.1%, 20.2%);
  }
}

…and begins by padding them out, so they have the same number of components:

@keyframes computed-keyframes {
  from {
    transform: none none;
  }
  to {
    transform: scale(3) translate(-33.1%, 20.2%);
  }
}

Then, for each from and to pair of components, it converts them to use a common function that can express both types of value. In this case:

@keyframes computed-keyframes {
  from {
    transform: scale(1) translate(0, 0);
  }
  to {
    transform: scale(3) translate(-33.1%, 20.2%);
  }
}

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.

How to fix it

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:

.demo.zoom {
  transform: translate(-99.3%, 60.6%) scale(3);
}

And that's it!

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!

.demo.zoom {
  --scale: 3;
  --x: -33.1%;
  --y: 20.2%;

  transform: translate(
      calc(var(--x) * var(--scale)),
      calc(var(--y) * var(--scale))
    )
    scale(var(--scale));
}

Or even, split the transform into two separate properties:

.demo.zoom {
  --scale: 3;
  --x: -33.1%;
  --y: 20.2%;

  scale: var(--scale);
  translate: calc(var(--x) * var(--scale)) calc(var(--y) * var(--scale));
}

When you use the scale and translate properties separately, the translate is always applied first—which just happens to be the order we want.

Job done!

But wait, why did rotate(0) fix it?

Back at the start of the article (remember that?), I mentioned that the animation could be 'fixed' by making the starting transform rotate(0):

.demo {
  transition: transform 1s ease;
  transform: rotate(0);
}
.demo.zoom {
  transform: scale(3) translate(-33.1%, 20.2%);
}

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:

@keyframes computed-keyframes {
  from {
    transform: rotate(0);
  }
  to {
    transform: scale(3) translate(-33.1%, 20.2%);
  }
}

As before, it pads out the values with none so they have the same number of components:

@keyframes computed-keyframes {
  from {
    transform: rotate(0) none;
  }
  to {
    transform: scale(3) translate(-33.1%, 20.2%);
  }
}

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:

@keyframes computed-keyframes {
  from {
    transform: matrix(1, 0, 0, 1, 0, 0);
  }
  to {
    transform: matrix(3, 0, 0, 3, -673.75, 231.904);
  }
}

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.

Bonus round: scale vs 3D translate

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:

.container {
  perspective: 1000px;
}
.demo.zoom {
  translate: -33.1% 20.2% 666.666px;
}

The rather demonic translate-z value was calculated by converting the scale to a translate-z value, using the following formula:

const scaleToTranslateZ = (scale, perspective) =>
  (perspective * (scale - 1)) / scale;

And here's the result:

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.

The bug

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:

class MyElement extends HTMLElement {
  say(message) {
    console.log(message);
  }
  connectedCallback() {
    this.say('hello!');
  }
  disconnectedCallback() {
    this.say('goodbye!');
  }
}

customElements.define('my-element', MyElement);

And I'm going to create an instance of the element, and put it in an iframe:

// Create the iframe
const iframe = document.createElement('iframe');
document.body.append(iframe);

// Create the element, and put it in the iframe
const 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.

Unfortunately this has been a known issue for 6 years.

The fix

The fix is kinda simple. Just… put the prototype back. As in, make it an instance of MyElement again.

class CustomElementBase extends HTMLElement {
  // 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);
  }
}

function rescueElementPrototype(element) {
  // Return if everything looks as expected.
  if (element instanceof CustomElementBase) 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:

class MyElement extends CustomElementBase {
  say(message) {
    console.log(message);
  }
  connectedCallback() {
    super.connectedCallback?.();
    this.say('hello!');
  }
  disconnectedCallback() {
    super.disconnectedCallback?.();
    this.say('goodbye!');
  }
}

And that's it! The bug is undone, and everything works as expected.

Update: Your feedback was heard, and folks have agreed to change the behaviour here. See the update below.

A brief intro to customisable <select>

If you want to hear about it in depth, I talked about it on OTMT, and there's a great post by Una Kravets. But here's a whirlwind tour:

<style>
  /* Opt in to the customisable mode */
  select,
  ::picker(select) {
    appearance: base-select;
  }
</style>

<select>
  <!--
    The button is the thing that appears on the page.
    It's what you click to open the popover menu.
    You can style it and control its content as you would any other button.
  -->
  <button>
    …
    <!-- We'll get to this later -->
    <selectedoption></selectedoption>
  </button>

  <!--
    Any other content, which can include divs, images, etc etc,
    is displayed in the popover menu when the button is clicked.
    You can style these elements however you like.
  -->
  <option>…</option>
  <option>…</option>
  <option>…</option>
</select>

And that's as much background as you need for the rest of this post.

What about <selectedoption>?

<selectedoption> automatically displays the currently selected <option> within the <button> that opens the popover menu.

It's entirely optional, so if you wanted to manually update the content of the <button> when the selected <option> changes, you can, and you get a lot more control that way. But <selectedoption> is much easier, and works without JavaScript.

When the selected <option> changes, it clears the contents of the <selectedoption>, takes a clone of the contents of the newly selected <option>, and inserts it into the <selectedoption>.

This is kinda new and weird behaviour. I recently wrote that I didn't like elements that modify themselves, as I think the light DOM should have a single owner. But, I can't think of a better way to do this, given:

• The content needs to render in two places at once - in the button and in the menu.
• The selected option needs to be able to be styled differently to the equivalent content in the <option>.
• The solution must work without JavaScript.

But there are limitations

This is a clone in the el.cloneNode(true) sense. That means it's a copy of the tree, including attributes, but not including properties, event listeners, or any other internal state. So, if the selected option contains a <canvas>, the clone will be a blank canvas. An <iframe> will reload using the src attribute. CSS animations will appear to start over, since they're newly constructed elements. Custom elements will be constructed afresh, and may have different internal state to the cloned element.

As far as I can tell, in most cases this will be fine, as the kinds of elements you'd typically use in an <option> are fully configurable via attributes.

But what if the selected <option> is modified?

This is the bit I want your opinion on. I'm going to present a series of options, and point out potential limitations/gotchas/issues with each. Not all of these issues are equal, and you may even feel some of them are features rather than bugs (I certainly do).

Editing the content of <option> elements isn't super common, but it's possible, so we need to define what happens. It might happen when:

• Enhancing options with additional data. For example, you might discover asynchronously that an option is "almost sold out", and want to display that information in the <option>.
• Dynamically modifying styles in response to interaction. Most animation libraries modify element.style, which also updates the style attribute.
• Going from a 'loading' state to a 'loaded' state.

For example, imagine a React app like this:

function CustomSelect({ options }) {
  return (
    <select>
      <button>
        <selectedoption></selectedoption>
      </button>

      {options.map((option) => (
        <option value={option.value}>
          {option.icon && <img src={option.icon} alt={option.iconAlt} />}
          {option.text}
        </option>
      ))}
    </select>
  );
}

function App() {
  const [options, setOptions] = useState([
    {
      text: 'Loading…',
    },
  ]);

  useEffect(() => {
    // Fetch option data and call setOptions
  }, []);

  return <CustomSelect options={options} />;
}

Because the above example doesn't give each <option> a meaningful key, React will modify the first 'loading' <option> to become the first real <option> when the data loads. It's better to use key in this situation, which would cause React to create a new <option> element, but not everyone does this.

You might see a similar pattern to above when updating <select> depending on a choice made earlier in a form.

So what should happen?

Option: Nothing by default, but provide a way to trigger an update

When an <option> becomes selected, the content of <selectedoption> is replaced with a clone of the selected <option>'s content. If the content of the selected <option> is later modified, it would become out of sync with the <selectedoption> element.

A method like selectedOption.resetContent() would cause the content to be replaced with a fresh clone of the selected <option>'s content. Developers would have to call this if they've updated the <option>'s content in a way that they want mirrored in the <selectedoption>.

Any manual modifications to the contents of <selectedoption> will be overwritten the next time the selected option changes to another <option>, or when selectedOption.resetContent() is called.

Option: Automatically reset the content when anything in the selected <option> changes

Whenever the tree in the selected <option> changes, as in a node is added, removed, or attributes change in any way, the content of the <selectedoption> is replaced with a fresh clone of the selected <option>'s content.

This would be a full clone of the <option>'s content. So even if you deliberately only changed one attribute on one element within the selected <option>, every element in the <selectedoption> would be replaced with a fresh clone. This would cause state to be reset in those elements, and things like CSS animations within <selectedoption> would appear to restart.

Since the cloning is performed synchronously, it will probably happen more than you expect. In the above React example where <option>Loading…</option> is changed to an option with an icon, that's three changes within the selected <option>:

1. The <img> is inserted (it's already been given the alt attribute).
2. The text is updated.
3. The src of the <img> is updated.

So that's three times the content of the <selectedoption> is replaced with a fresh clone of the selected <option>'s content, and this is a really basic example.

What about this:

// Get the selected <option>
const selectedOption = select.selectedOptions[0];
// Move the first child to the end
selectedOption.append(selectedOption.firstChild);

Well, that's two clones of the selected <option>'s content, because an element 'move' is actually two tree modifications: a remove followed by an insert.

If you change 10 styles on an element within the selected <option> via element.style, each change updates the style attribute, so that's 10 times the content of the <selectedoption> is replaced with a fresh clone of the selected <option>'s content.

If you're using an animation library to do something fancy within one of the options, they tend to modify element.style per frame. So that means the content of <selectedoption> is being entirely rebuilt every frame, or more likely, many times per frame.

There may be cases where you don't want a change in the <option> to be reflected in the <selectedoption>. Since they're independent elements, you can give each independent :hover states via CSS. But, if you want to do something much fancier involving JavaScript, which modifies element.style on mouseenter, that will appear to be mirrored from the selected <option> to the <selectedoption>, which may not be your intent, because only the <option> is being hovered over.

This could actually become more of an issue in future. Right now, when you click on a <details> element, it becomes <details open> – it modifies its own attributes. If you had one of those in a selected <option> and the user clicked on it, the one in the <selectedoption> would appear to open too (via cloning since the attribute changed). Now, having a <details> in an <option> doesn't really make sense, but since this pattern is becoming more popular on the web platform, it may appear on an element that you would use in an <option>.

There isn't a way to prevent changes from mirroring to <selectedoption>. The only way around it is to avoid using <selectedoption> and doing things manually.

Also, this automatic 'mirroring' is one-way. If you manually alter content in the <selectedoption>, it won't cause the content in the selected <option> to be updated. Your manual changes in the <selectedoption> will be overwritten the next time the cloning operation occurs.

Option: Automatically reset the content when anything in the selected <option> changes… debounced

As above, but when the content of the selected <option> changes, the content of the <selectedoption> is replaced with a fresh clone after a microtask. This would always be before the next render.

This reduces the amount of cloning significantly. All the examples I gave above would only trigger a single clone of the selected <option>'s content.

However, it means that:

// Get the selected <option>
const selectedOption = select.selectedOptions[0];
// Get the <selectedoption>
const selectedOptionMirror = select.querySelector('selectedoption');

selectedOption.textContent = 'New text';

// This may not be true yet, because the mirroring is delayed.
console.log(selectedOption.textContent === selectedOptionMirror.textContent);

Also, you still have the behaviours where:

• Changing one inner element of the selected <option> causes all elements in the <selectedoption> to be replaced.
• Changes are mirrored even if you don't want them to be.
• Mirroring is one-way.

Option: Perform targeted DOM changes when something in the selected <option> changes

When the <option> becomes selected, the content of the <selectedoption> is replaced with a clone of the selected <option>'s content. However, the browser maintains a link between each of the elements and their respective clones. If you modify an attribute on an original element, the same attribute on its clone is updated, and only that attribute. This means that changes on one element in the selected <option> won't cause everything in the <selectedoption> to 'reset', such as CSS animations.

If a new element is introduced into the selected <option>, it will be cloned and inserted into the equivalent position in the <selectedoption>.

Changes will be performed synchronously, but the changes are just a repeat of your specific action. Your changes run twice, once in the selected <option>, and once in the <selectedoption>.

However, when the selected <option> changes to another <option>, the content of the <selectedoption> is fully replaced with a fresh clone of the newly selected <option>'s content.

You still have the behaviours where:

• Changes are mirrored even if you don't want them to be.
• Mirroring is one-way.

The one-way mirroring behaviour is different to the other options. In the 'clone' options, any change to the selected <option> will cause the content in the <selectedoption> to 'reset', as the content is completely replaced with a fresh clone. Whereas in this option, since the DOM changes are targeted, if you manually modify the <selectedoption> content, it's more like a fork.

For example, inserts will be done using an internal version of element.insertBefore, as in "insert node into element before referenceNode". If the content of <selectedoption> has been manually altered, it's possible this change will fail because referenceNode is no longer in element, in which case the node won't be inserted.

So, what do you think?

This is being actively discussed in the HTML spec, but I want a wider set of developers to have their opinions heard on this.

What should happen? Which options do you like? Which do you hate? Let me know what you think in the comments, social networks, Hacker News, or wherever else you can get my attention. I'll present this at the next OpenUI meeting.

Update

This was discussed in an OpenUI meeting, and the consensus was to go with the first option in this post: nothing by default, but provide a way to trigger an update.

Thank you for all the feedback!

Often a good solution here is to create the animation using web technologies, but sometimes video is a better solution for consistent frame rates, and allows for effects like motion blur which don't currently exist on the web.

I didn't know much about it, so I dug in to try and find the most robust and efficient way to do it. I thought it was going to be a nice little I-can-do-this-while-jetlagged hackday project, but it's way more complicated than I thought. It turns out, the 'native' ways of doing it are inefficient and buggy. If you handle the transparency yourself, you avoid these bugs, and serve a file that's half the size, or less.

If you just want the solution, here's <stacked-alpha-video>, an NPM package to handle the playback of these videos.

Otherwise, here's what I discovered, and the many bugs I filed along the way.

Native support for transparency in web-compatible video formats

Web-friendly video formats have supported transparency for 15 years. So by now it'd be well-supported and easy to use, right? Right?

Right?

AVIF ain't it

AV1 is a great video format in terms of the compression ratio, and the encoder is great for a variety of content. However, surprisingly, it doesn't support transparency.

AVIF is an image format built from AV1. AVIF does support transparency. Also, 'animated AVIF' is a thing. It's stored as two AV1 streams, where the additional stream is a luma-only (black & white) video representing the alpha channel.

Taking the example at the top of this post, I can get the size down to 504 kB with acceptable loss.

Here's a demo, but… don't get your hopes up:

Show AVIF demo

Hide AVIF demo

Given that AVIF is well supported, it sounds like the ideal solution. But…

It doesn't work in Safari

Although Safari supports AVIF, and supports transparency in AVIF, it doesn't correctly support transparency in an animated AVIF. It looks a real mess, and its horrendously slow.

Bug report.

The performance is prohibitively bad

Chrome and Firefox render the AVIF correctly, but it struggles to hit 60fps even on an ultra high-end laptop. On Android, it struggles to hit even a few frames per second.

• Chrome bug report.
• Firefox bug report.

Streaming is poor

When playing content back via <video>, browsers will delay starting playback until it thinks enough is buffered for uninterrupted playback. However, because this is <img> rather than <video>, Chrome will just display frames as soon as it has the data, making playback really choppy on slower connections.

This is really because…

Animated image formats are a hack

Im my opinion, animated AVIF doesn't make sense in a world where AV1 video exists. Even if all the above bugs were fixed, you'd still be unable to:

• Show browser video playback controls.
• Programmatically pause/resume playback, e.g. for accessibility reasons.
• Fallback to an alternative video format via <source>.
• Include audio.

There are benefits to being able to include animated content in an <img>, especially in contexts like forums that support <img> but not <video>. The good news is, Safari solved this back in 2018:

<img src="whatever.mp4" alt="…" />

The above just works in Safari. You can even use videos as image content in CSS. The bad news is, Chrome isn't interested in supporting this. Booooooooo.

Encoding animated AVIF

For completeness: here's how to create an animated AVIF using ffmpeg:

INPUT="in.mov" OUTPUT="out.avif" CRF=45 CRFA=60 CPU=3 bash -c 'ffmpeg -y -i "$INPUT" -color_range tv -pix_fmt:0 yuv420p -pix_fmt:1 gray8 -filter_complex "[0:v]format=pix_fmts=yuva444p[main]; [main]split[main][alpha]; [alpha]alphaextract[alpha]" -map "[main]:v" -map "[alpha]:v" -an -c:v libaom-av1 -cpu-used "$CPU" -crf "$CRF" -crf:1 "$CRFA" -pass 1 -f null /dev/null && ffmpeg -y -i "$INPUT" -color_range tv -pix_fmt:0 yuv420p -pix_fmt:1 gray8 -filter_complex "[0:v]format=pix_fmts=yuva444p[main]; [main]split[main][alpha]; [alpha]alphaextract[alpha]" -map "[main]:v" -map "[alpha]:v" -an -c:v libaom-av1 -cpu-used "$CPU" -crf "$CRF" -crf:1 "$CRFA" -pass 2 "$OUTPUT"'

• CRF (0-63): Lower values are higher quality, larger filesize.
• CRFA (0-63): Like CRF, but for the alpha channel.
• CPU (0-8): Weirdly, lower values use more CPU, which improves quality, but encodes much slower. I wouldn't go lower than 3.

VP9 + HEVC somewhat works

This solution isn't ideal, and definitely isn't the most efficient, but it's the best we've got when it comes to native support, meaning it works without JavaScript:

This is 1.1 MB in Chrome & Firefox via the VP9 codec, and 3.4 MB in Safari via the HEVC codec. The VP9 is double the size of the AVIF, which shows the generational gap between the codecs.

<video playsinline muted autoplay loop>
  <source type="video/quicktime; codecs=hvc1.1.6.H120.b0" src="video.mov" />
  <source type="video/webm; codecs=vp09.00.41.08" src="video.webm" />
</video>

The HEVC must appear first. Safari supports VP9, but it doesn't support VP9 with transparency (bug report), so we need to 'encourage' Safari to pick the HEVC file over the VP9.

I'm a little worried that a non-Apple device will try to play the HEVC file, but not support transparency (after all, it's an Apple extension to the format (pdf)), resulting in broken output. However, I haven't seen this happen yet.

Also, there are a couple of bugs to be aware of:

• Chrome Android gets the alpha channel wrong. Depending on how much transparency you use, it might not matter too much. This has been fixed in Canary, but at time of writing, it hasn't reached stable.
• Playback often stalls on Firefox for Android.

Encoding VP9

With ffmpeg:

INPUT="in.mov" OUTPUT="out.webm" CRF=45 EFFORT="good" bash -c 'ffmpeg -y -i "$INPUT" -pix_fmt yuva420p -an -c:v libvpx-vp9 -crf "$CRF" -b:v 0 -deadline "$EFFORT" -threads 4 -lag-in-frames 25 -row-mt 1 -pass 1 -f null /dev/null && ffmpeg -y -i "$INPUT" -pix_fmt yuva420p -an -c:v libvpx-vp9 -crf "$CRF" -b:v 0 -deadline "$EFFORT" -threads 4 -lag-in-frames 25 -row-mt 1 -pass 2 "$OUTPUT"'

• CRF (0-63): Lower values are higher quality, larger filesize.
• EFFORT (best or good): good is faster, but slightly lower quality.

Encoding HEVC

This is the format you need for Apple devices, so it might not surprise you to hear that you can only encode it on MacOS.

In addition, you really need to fork out £50 or whatever for Apple's Compressor.

But even then, the results aren't great. I don't think Apple's Compressor is designed with this kind of content in mind, so you usually end up with a much larger file size than the equivalent VP9.

Here's a quick video guide to using the Compressor app to encode video with an alpha channel.

If, after forking out £££ for an Apple device, you really really really don't want to spend £50 on Compressor, you can encode a kinda shitty version using ffmpeg. Note: this only works on MacOS, as it calls out to the built-in codec.

ffmpeg -i in.mov -c:v hevc_videotoolbox -require_sw 1 -alpha_quality 0.1 -tag:v hvc1 -q:v 35 -vf "premultiply=inplace=1" out.mov

• -q:v (0-100): Quality, where 100 is the highest quality with largest file size.
• -alpha_quality (0-1): Separate control of the alpha channel quality.

The reason this method is worse is because, for whatever reason, it uses the BGRA pixel format. This means the red, green, and blue channels are stored separately. This isn't very efficient. Video formats tend to use YUV, where brightness (Y) is stored separate to colour (UV). Human eyes are more sensitive to brightness than colour, so this separation means more bits can be spent on the brightness data vs the colour. I've filed a bug to see if this can be fixed. In the meantime, this method will yield around double the file size compared the already-not-great Compressor result.

There's a feature request for the open source & cross-platform x265 codec to support transparency, but it doesn't seem to be going anywhere.

Doing it manually

AV1 is the most efficient codec we have in browsers, but it doesn't support transparency. When it's in an AVIF container, it does, but the performance is prohibitively bad.

So, I thought, what if I split the video in two, making it double height, where the top half is the video without the alpha channel, and the bottom half is the alpha channel represented as brightness?

Then, a WebGL fragment shader can be used to efficiently apply the bottom half as a mask to the top half:

// The video frame
uniform sampler2D u_frame;

// The texCoords passed in from the vertex shader.
varying vec2 v_texCoord;

void main() {
  // Calculate the coordinates for the color (top half of the frame)
  vec2 colorCoord = vec2(v_texCoord.x, v_texCoord.y * 0.5);
  // Calculate the coordinates for the alpha (bottom half of the frame)
  vec2 alphaCoord = vec2(v_texCoord.x, 0.5 + v_texCoord.y * 0.5);

  // Pull the pixel values from the video frame
  vec4 color = texture2D(u_frame, colorCoord);
  float alpha = texture2D(u_frame, alphaCoord).r;

  // Merge the rgb values with the alpha value
  gl_FragColor = vec4(color.rgb, alpha);
}

And here it is:

For Chrome, Firefox, and Safari on a iPhone 15 Pro or M3 MacBook Pro, this is 460 kB. A huge reduction compared to 1.1 or 3.4 MB for the native version.

In fact, the alpha data in the bottom half of the video only adds 8 kB to the overall size. I guess this is because the content is a single channel (brightness), mostly flat color, and mostly unchanged from frame to frame. Cases where the alpha data changes more frequently, or includes a lot of semi-transparency, will likely contribute more to the overall file size.

Other Apple devices don't support AV1, so they need an HEVC version at 1.14 MB, which isn't as good, but still a lot smaller than the 3.4 MB version they'd get for the native version.

The 460 kB AV1 version is even significantly smaller than the 504 kB AVIF. I'm not really sure why. With the AVIF, I encoded with the exact same settings - I even encoded the alpha data lower quality in the AVIF, so in theory it should be at an advantage. I guess the AVIF has overhead by being two separate video streams, whereas the stacked version is one video.

Wrapping it up in a web component

I've published a little web component to handle the rendering:

<stacked-alpha-video>
  <video autoplay crossorigin muted playsinline loop>
    <source
      src="av1.mp4"
      type="video/mp4; codecs=av01.0.08M.08.0.110.01.01.01.1"
    />
    <source src="hevc.mp4" type="video/mp4; codecs=hvc1.1.6.H120.b0" />
  </video>
</stacked-alpha-video>

You control playback via the <video>, so you're in full control over how the video is fetched, and it can also start fetching before JS loads. The web component just handles the rendering.

I'm far from a web component absolutist, but it seemed like the perfect choice here to make the component useable across frameworks, or without a framework.

It's available on NPM, but I also export the internals, so you can access the WebGL bits without going via the web component.

The one thing I think it's missing is being able to use the native <video> controls, so I filed an issue for that too.

Encoding the video

Again, ffmpeg is the tool for the job. Here's the filter:

-filter_complex "[0:v]format=pix_fmts=yuva444p[main]; [main]split[main][alpha]; [alpha]alphaextract[alpha]; [main][alpha]vstack"

Breaking it up step by step:

1. [0:v]format=pix_fmts=yuva444p[main] convert to a predictable format.
2. [main]split[main][alpha] fork the output.
3. [alpha]alphaextract[alpha] with the 'alpha' fork, pull the alpha data out to luma data, creating a black & white view of the transparency.
4. [main][alpha]vstack stack the 'main' and 'alpha' forks on top of each other.

Encoding AV1

This is the ideal format:

INPUT="in.mov" OUTPUT="av1.mp4" CRF=45 CPU=3 bash -c 'ffmpeg -y -i "$INPUT" -filter_complex "[0:v]format=pix_fmts=yuva444p[main]; [main]split[main][alpha]; [alpha]alphaextract[alpha]; [main][alpha]vstack" -pix_fmt yuv420p -an -c:v libaom-av1 -cpu-used "$CPU" -crf "$CRF" -pass 1 -f null /dev/null && ffmpeg -y -i "$INPUT" -filter_complex "[0:v]format=pix_fmts=yuva444p[main]; [main]split[main][alpha]; [alpha]alphaextract[alpha]; [main][alpha]vstack" -pix_fmt yuv420p -an -c:v libaom-av1 -cpu-used "$CPU" -crf "$CRF" -pass 2 -movflags +faststart "$OUTPUT"'

• CRF (0-63): Lower values are higher quality, larger filesize.
• CPU (0-8): Weirdly, lower values use more CPU, which improves quality, but encodes much slower. I wouldn't go lower than 3.

Encoding HEVC

Safari on Apple devices will use the AV1 if they have a hardware decoder (iPhone 15 Pro, M3 MacBook Pro), otherwise they need an HEVC alternative. But, since we don't need native transparency support, we can use the open source & cross-platform x265 codec:

INPUT="in.mov" OUTPUT="hevc.mp4" CRF=30 PRESET="veryslow" bash -c 'ffmpeg -y -i "$INPUT" -filter_complex "[0:v]format=pix_fmts=yuva444p[main]; [main]split[main][alpha]; [alpha]alphaextract[alpha]; [main][alpha]vstack" -pix_fmt yuv420p -an -c:v libx265 -preset "$PRESET" -crf "$CRF" -tag:v hvc1 -movflags +faststart "$OUTPUT"'

• CRF (0-63): Lower values are higher quality, larger filesize.
• PRESET (medium, slow, slower, veryslow): The slower you go, the better the output.

I find I have to go with a much lower CRF than with the AV1.

Aside: limited range

The ffmpeg examples I've given here result in the videos being encoded in 'limited range'. This uses 16-235 rather than the full 8bit 0-255. This 'feature' exists due to old CRT TVs which would suffer from signal overshooting. Unfortunately, it still hangs around as a kind of default, even to the degree where Chrome has bugs when handling the full range.

8bit is pretty minimal when it comes to gradients, so this ~15% reduction can result in banding. If this is a problem, you can try encoding to one of the 10bit pixel formats by swapping out format=pix_fmts=yuva444p for format=pix_fmts=yuva444p10le, and changing the pix_fmt to yuv444p10le. I'll leave that for you to figure out 😀

function demo() {
  const bigArrayBuffer = new ArrayBuffer(100_000_000);
  const id = setTimeout(() => {
    console.log(bigArrayBuffer.byteLength);
  }, 1000);

  return () => clearTimeout(id);
}

globalThis.cancelDemo = demo();

With the above, bigArrayBuffer is leaked forever. I didn't expect that, because:

• After a second, the function referencing bigArrayBuffer is no longer callable.
• The returned cancel function doesn't reference bigArrayBuffer.

But that doesn't matter. Here's why:

JavaScript engines are reasonably smart

This doesn't leak:

function demo() {
  const bigArrayBuffer = new ArrayBuffer(100_000_000);
  console.log(bigArrayBuffer.byteLength);
}

demo();

The function executes, bigArrayBuffer is no longer needed, so it's garbage collected.

This also doesn't leak:

function demo() {
  const bigArrayBuffer = new ArrayBuffer(100_000_000);

  setTimeout(() => {
    console.log(bigArrayBuffer.byteLength);
  }, 1000);
}

demo();

In this case:

1. The engine sees bigArrayBuffer is referenced by inner functions, so it's kept around. It's associated with the scope that was created when demo() was called.
2. After a second, the function referencing bigArrayBuffer is no longer callable.
3. Since nothing within the scope is callable, the scope can be garbage collected, along with bigArrayBuffer.

This also doesn't leak:

function demo() {
  const bigArrayBuffer = new ArrayBuffer(100_000_000);

  const id = setTimeout(() => {
    console.log('hello');
  }, 1000);

  return () => clearTimeout(id);
}

globalThis.cancelDemo = demo();

In this case, the engine knows it doesn't need to retain bigArrayBuffer, as none of the inner-callables access it.

The problem case

Here's where it gets messy:

function demo() {
  const bigArrayBuffer = new ArrayBuffer(100_000_000);

  const id = setTimeout(() => {
    console.log(bigArrayBuffer.byteLength);
  }, 1000);

  return () => clearTimeout(id);
}

globalThis.cancelDemo = demo();

This leaks, because:

1. The engine sees bigArrayBuffer is referenced by inner functions, so it's kept around. It's associated with the scope that was created when demo() was called.
2. After a second, the function referencing bigArrayBuffer is no longer callable.
3. But, the scope remains, because the 'cancel' function is still callable.
4. bigArrayBuffer is associated with the scope, so it remains in memory.

I thought engines would be smarter, and GC bigArrayBuffer since it's no longer referenceable, but that isn't the case.

globalThis.cancelDemo = null;

Now bigArrayBuffer can be GC'd, since nothing within the scope is callable.

This isn't specific to timers, it's just how I encountered the issue. For example:

function demo() {
  const bigArrayBuffer = new ArrayBuffer(100_000_000);

  globalThis.innerFunc1 = () => {
    console.log(bigArrayBuffer.byteLength);
  };

  globalThis.innerFunc2 = () => {
    console.log('hello');
  };
}

demo();
// bigArrayBuffer is retained, as expected.

globalThis.innerFunc1 = undefined;
// bigArrayBuffer is still retained, as unexpected.

globalThis.innerFunc2 = undefined;
// bigArrayBuffer can now be collected.

TIL!

Updates

An IIFE is enough to trigger the leak

I originally thought this 'capturing' of values only happened for functions that outlive the initial execution of the parent function, but that isn't the case:

function demo() {
  const bigArrayBuffer = new ArrayBuffer(100_000_000);

  (() => {
    console.log(bigArrayBuffer.byteLength);
  })();

  globalThis.innerFunc = () => {
    console.log('hello');
  };
}

demo();
// bigArrayBuffer is retained, as unexpected.

Here, the inner IIFE is enough to trigger the leak.

It's a cross-browser issue

This whole thing is an issue across browsers, and is unlikely to be fixed due to performance issues.

• Chromium issue
• Firefox issue
• WebKit issue

I'm not the first to write about this

• A low level look at why this happens, by Slava Egorov, back in 2012
• Meteor engineers discover it, by David Glasser, in 2013
• This React-centric look at it, by Kevin Schiener, as recently as May 2024.

And no, this is not due to eval()

Folks on Hacker News and Twitter were quick to point out that this is all because of eval(), but it isn't.

Eval is tricky, because it means code can exist within a scope that can't be statically analysed:

function demo() {
  const bigArrayBuffer1 = new ArrayBuffer(100_000_000);
  const bigArrayBuffer2 = new ArrayBuffer(100_000_000);

  globalThis.innerFunc = () => {
    eval(whatever);
  };
}

demo();

Are either of the buffers accessed within innerFunc? There's no way of knowing. But the browser can statically determine that eval is there. This causes a deopt where everything in the parent scopes is retained.

The browser can statically determine this, because eval acts kinda like a keyword. In this case:

const customEval = eval;

function demo() {
  const bigArrayBuffer1 = new ArrayBuffer(100_000_000);
  const bigArrayBuffer2 = new ArrayBuffer(100_000_000);

  globalThis.innerFunc = () => {
    customEval(whatever);
  };
}

demo();

…the deopt doesn't happen. Because the eval keyword isn't used directly, whatever will be executed in the global scope, not within innerFunc. This is known as 'indirect eval', and MDN has more on the topic.

This behaviour exists specifically so browsers can limit this deopt to cases that can be statically analysed.