Browser Support Is a Product Decision

We spend enough of our day in Firefox to have built two extensions for it. Most visitors to the sites we build will arrive in something else, usually Safari or Chrome and often on a phone, with whatever settings and hardware they happen to have. The browser we like best tells us almost nothing about what to test.

At some point in planning a website, somebody says it should work in every browser. That’s a reasonable thing to want and an impossible thing to build to, because nobody has said what “work” means. Does every animation have to play in a five-year-old Safari? What about with JavaScript turned off, or inside the browser that opens when you tap a link in another app? A requirement we can build and test needs edges, and the edges come from the product: who uses it, what they came to do, and what it costs to reach each of them.

So the question we ask is what each environment should receive. Our own home page is the example we know best.

One home page, four versions

The home page of this site opens with a scroll-driven fly-through we call the dive. The camera starts on a laptop showing Burn After, closes in on the details of its design, magnifies one letter until its red, green, and blue subpixels fill the screen, passes between them into the code and the system underneath, and then pulls back to show every product in our lineup. It’s drawn with WebGL, and it’s the version we had in mind when we designed the page. We also built three others.

If you’ve asked your operating system to reduce motion, the camera cuts from one stage to the next instead of flying between them. A browser with data saving turned on, or a device with less than 2 GB of memory, gets the same treatment. Those two signals only exist in Chromium-based browsers, so in Safari and Firefox the motion setting is all we have to go on. If you turn reduced motion on in the middle of a visit, the page reloads into the still version.

If your browser can’t give us WebGL 2 on a real GPU, there’s no camera at all. We ask the browser to refuse rather than fall back to software rendering, because the dive can’t hold its frame rate that way. You get stills that tell the same story as you scroll: the laptop, a real crop of its pixels scaled up with hard edges, and the lineup with its screens lit. The words, the code, and the system diagram arrive on the same schedule as they do in the full version.

With JavaScript off, there’s no scrolling stage either. The same parts are stacked as an ordinary page: the opening image, the code, the system diagram, and then each stage’s text. The contact form further down is a plain HTML form with its script layered on top, so without JavaScript it falls back to an ordinary form submission.

All four tell a visitor the same things about us, with more or less spectacle attached, and the three smaller ones were designed as deliberately as the first. The full version also isn’t allowed to slow the others down. Everyone starts on a still image of the opening frame, positioned to match the camera’s first shot so the canvas can take over without a jump. Creating a WebGL context can tie up the browser for hundreds of milliseconds, so we hold off until there’s a sign you’re about to scroll, like a pointer movement, a touch, or a key press. That way the work never competes with drawing the first screen.

Four levels of browser support

On any project we sort browsers and environments into four levels of support rather than two. The dive touches all of them.

Fully supported

These are the browsers we test in, where a regression is a bug we fix. The list comes from the audience, which usually puts Safari on an iPhone near the top whatever the developers prefer. Full support includes details you only learn on the real device. iOS Safari zooms the whole page when you tap a form field with text smaller than 16 pixels, so the fields in our contact form use 16-pixel text on phones.

Expected to work

These are browsers we don’t open for every release but have good reason to trust, because the site is built on standards they support. The dive helps by never asking which browser you have. It asks for WebGL 2, reads your motion setting, and gives you the version that fits, so a browser we’ve never tested still lands in the right place. When something does break in one of these, we investigate it like any other bug, whether or not the browser was on a list.

Graceful degradation

Here an enhancement is missing and the important parts still work. The three smaller versions of the dive are this level. A quieter example sits in the contact form, where the message box on phones grows as you type. Browsers that support the CSS field-sizing property do that on their own, and the rest get a few lines of JavaScript that do the same job.

Unsupported

Unsupported should mean we made a decision and can say what it was. Easy Screenshot Plus and Tab Groups Switcher are Firefox extensions, and Chrome is unsupported for both. Easy Screenshot Plus began as a fork of a Firefox extension we already used, and Tab Groups Switcher is built around Firefox’s own tab groups. They are Firefox products by design. The dive has an unsupported case as well. We didn’t write a second renderer for browsers without WebGL 2, so they get the stills.

Every level has a price

Each of those versions is code we wrote and something to check again whenever the home page changes. That’s the argument for treating browser support as a product decision: it has a price, and whether the price is worth paying depends on the product. For our home page, which is the first thing a prospective client sees, four versions were worth it. For the 404 page they wouldn’t have been.

The decision also has to be made early, because it changes what gets built. The still image that opens the dive lines up with the first WebGL frame because both were laid out from the same numbers. A fallback added the week before launch wouldn’t have matched.

When we plan a website for a client, we ask the same things. Who visits, and on what? What has to work for every one of them, like reading the page and getting in touch, and what is an enhancement that can step aside? What does each extra environment cost to build and to keep working? The answers belong to the people who own the product as much as to the people writing the code.

What analytics can and can’t tell you

For a site that already exists, traffic data is the obvious place to start, and it needs reading with some care. A browser showing zero visits might mean nobody uses it. It might also mean the site is already so broken there that visitors never get as far as the analytics script. Some browsers go missing for another reason: Brave blocks Google Analytics by default, as we found on one of our own sites, so most of the people using it never show up in those reports. And on a busy site, a small percentage is still a lot of people.

Support decisions go out of date

Until Safari 15 arrived in 2021, requiring WebGL 2 would have shut out every iPhone. Today every current browser has it. The same thing will happen to the JavaScript that grows the message box: once field-sizing works everywhere, that code should be deleted. Audiences move as well, so the list is worth going back over now and then, which is part of looking after a site once it has launched.

You can check our work on the home page. Turn on reduced motion in your system settings, or switch off JavaScript, and scroll it again.