We Checked 554 Web Features. 15 Are Gated by the OS, Not the Version.

On 12 October 2026 Apple launched a Switch to Safari campaign: a dedicated page, two videos, and claims about battery life, privacy and performance. It is aimed at users choosing a browser. The question a development team has to answer is different, and it sounds simpler: what can we rely on being there?

Every tool we use to answer that question gives the same shape of answer. A browser, and a version number. Your browserslist config, your CI matrix, your BrowserStack grid, the Baseline badge on a documentation page: all of them select browsers by version. On 14 October 2026 we read the underlying datasets to see whether the version number is actually the thing that decides. For fifteen features in current releases, it is not.

TL;DR

• We read all 554 features in the caniuse dataset at the current release of eight major browsers, which is 4,432 support cells. 231 of them are marked partial.
• 15 features are gated by the operating system, the OS build, or the hardware rather than the browser version. Safari 27 decodes AV1 only on a device with a hardware decoder. It accepts zstd only on macOS 26.3. WebGPU is on by default only from macOS 26. Seven of these cells are marked as full support.
• Your build tool never sees any of this. caniuse-lite 1.0.30001816, the package browserslist actually reads, ships 583 feature files with four keys each and zero occurrences of the string “macOS”. The note text is stripped at packaging time.
• Baseline collapses it further. In web-features 3.42.0, all 1,214 statuses are seven browser keys mapped to a version string. There is no partial state and no OS axis. Three features that Baseline calls Widely available carry an OS-conditional caveat in caniuse, including tabindex.
• Five of the fifteen are absent from Baseline entirely, because it does not model codecs or font rendering.

What we measured, and how

Two datasets, both pulled live on 14 October 2026.

The first is data.json from the caniuse repository: 554 features, each with a support code per browser per version, plus a notes_by_num map holding the prose behind every footnote marker. We resolved the current release of each browser from the dataset’s own era index rather than hard-coding versions, giving Chrome 154, Safari 27, Firefox 157, Edge 154, Safari on iOS 27.0, Chrome for Android 154, Samsung Internet 30 and Opera 135. One cell per feature per browser produced 4,432 cells: 3,660 full, 521 none, 231 partial, 17 polyfill, 3 unknown.

We then pattern-matched every numbered note attached to a current-release cell for a condition naming an operating system, an OS version, a device or a hardware requirement. That returned 46 cells across 26 features. Reading all 46 by hand, we discarded 18 as historical rather than live: Chromium dropping drag and drop on Android 6, SPDY deprecations, a getUserMedia quirk fixed before iOS 14.3. What survived is 28 cells across 15 features where the condition still applies to a shipping release.

The second dataset is web-features 3.42.0, the package behind Baseline, read with its own JSON schema alongside it. We also unpacked caniuse-lite 1.0.30001816 to see what survives the trip from the caniuse dataset into a build tool.

Finding 1: the browser comparison is the least interesting number

Start with the question Apple’s campaign implies. At current releases, Safari 27 is behind Chrome 154 on 49 features, 34 of them with no support at all. Going the other way, Chrome is behind Safari on 15, and that list is mostly deprecated technology or Apple’s own media formats: SPDY, SVG fonts, FIDO U2F, HEIF, HEVC. The only genuinely interesting entries are CSS anchor positioning and the filter() function.

So the reputation holds. It is also close to useless for planning, because it says nothing about the 231 partial cells, and partial is where the cost lives.

Finding 2: “partial” is 34 different things in Safari alone

Safari 27 is marked partial on 34 features. We read every note attached to them. They are not one kind of problem:

• A missing property value. mix-blend-mode works, except for hue, saturation, color and luminosity.
• An accessibility defect. Buttons are not accessible with display: contents applied, in both Safari and Chrome.
• A hardware requirement, which is a different category entirely, and the subject of the next section.
• Nothing at all. Five of the 34 carry no numbered note: CSS counter styles, ruby annotation, SVG effects for HTML, WAI-ARIA and X-Frame-Options. The dataset tells you the feature is partial and declines to say which part.

A flat “no” is cheap to handle: you detect it, polyfill it, degrade. A partial is expensive precisely because feature detection returns true and the failure arrives at runtime, on a subset of your users, in a way nobody can reproduce on the machine that reported it.

Finding 3: fifteen features where the version is not the answer

These are the 28 surviving cells, grouped by feature. Every condition below is quoted or paraphrased from the note attached to the current release.

Feature	Browsers	What actually decides
AV1 video	Safari 27, iOS 27	Hardware decoder only, e.g. iPhone 15 Pro, M3 MacBook Pro
HEVC/H.265	Chrome, Firefox, Edge, Chrome Android, Opera	Device hardware support; macOS 11 and Android 5 blanket-supported
WebGPU	Safari, Firefox, Chrome, Opera	Safari: default on from macOS 26. Firefox: Windows, or macOS 26 on Apple Silicon. Chrome on Linux: depends on drivers
zstd encoding	Safari 27	Requires macOS 26.3
Opus audio	Safari 27	Requires macOS 15.4
Fullscreen API	iOS 27	iPad only, not iPhone
Media Source Extensions	iOS 27	Fully supported only on iPadOS
Audio element	iOS 27	Volume is read-only
Picture-in-Picture	Chrome Android	Android 8.0 and newer
theme-color	Chrome Android	Ignored on devices with native dark mode unless installed as a PWA
font-smooth	All five Chromium and Gecko browsers	Works only on macOS
Variable fonts	Firefox 157	macOS 10.13 or Windows 10 1709 and later
tabindex	Firefox 157	On macOS, links are not keyboard-focusable unless Full Keyboard Access is enabled
Video element	Safari 27, iOS 27	autoplay ignored by default; user-configurable per site
Web Serial API	Chrome Android	Over Bluetooth RFCOMM

Seven of those 28 cells are marked y, full support. The condition exists only in prose. Two of them are accessibility-relevant and one is a conversion-path problem: a volume control you render on an iPhone is a control that silently does nothing, and caniuse records iOS as supporting the audio element since version 3.

The tabindex row is the one worth sitting with. It is among the oldest interactive primitives on the platform, supported since Firefox 1.5 and Safari 3.1. On macOS, unless the user has turned on Full Keyboard Access, an anchor with tabindex="0" is not keyboard-focusable in Firefox. That is an accessibility audit finding that depends on a System Settings toggle, not a browser version, and no amount of version-matrix testing will surface it.

Finding 4: your build tool is told none of this

browserslist is where most teams encode their support policy, so we checked whether it can express an OS condition at all. Its grammar file is 131 lines. The only query axes are usage statistics, country and region codes, version ranges, release dates, Baseline status, Node.js versions, and support for a named caniuse feature. The strings ios and android appear in that grammar nine times, every one of them inside a browser identifier such as ios_saf or chromeandroid. An operating system is only ever part of a browser’s name, never a condition on it.

That is a defensible design decision. The harder problem is upstream. browserslist does not read the caniuse dataset we analysed; it reads caniuse-lite. We unpacked version 1.0.30001816: 583 feature files, each exporting an object with exactly four keys, being a bitmask-encoded stats table, a category index, the feature title, and a boolean.

Across all 583 files, the string “macOS” appears zero times. “Tahoe” appears zero times. “hardware” appears once, in the title of navigator.hardwareConcurrency. The notes are not compressed or encoded. They are simply not shipped.

So when you write fully supports zstd in a browserslist query, the answer comes from a bitmask that knows Safari 27 is partial and has no idea the reason is macOS 26.3. The information was in the source dataset and discarded before your toolchain saw it.

Finding 5: Baseline flattens it one step further

Baseline is the industry’s current answer to “can I use this yet”, and a genuine improvement on reading five columns of a table. We read its data model directly.

web-features 3.42.0 contains 1,226 features, 1,214 with a status. Each status is a baseline value of high, low or false (650, 123 and 441 respectively) plus a support object keyed by exactly seven browsers. We checked every support value in the dataset. All of them are version strings. There is no partial state, no note field, and no dimension for an operating system.

Of our fifteen OS-gated features, ten exist in Baseline and five do not, because Baseline does not model codecs or font rendering: AV1, HEVC, Opus, font-smooth and variable fonts have no entry. Of the ten that do:

• Three are Baseline Widely available: tabindex, the video element and the audio element. All three carry a live OS-conditional caveat in caniuse. Widely available is a true statement about version coverage and a misleading one about behaviour.
• zstd is Baseline Newly available, listed as Safari 26.3. caniuse marks Safari 27 as partial for the same feature. Two tools, opposite answers, same current browser.
• Fullscreen and Media Source Extensions list desktop Safari and omit Safari on iOS entirely. That is the model’s only way to say “iPad yes, iPhone no”. Fifteen features in the dataset have desktop Safari support with no iOS entry.

JPEG XL makes the same point: Baseline lists it as supported in Safari 17, while caniuse marks Safari 27 partial because animated sequences and progressive decoding are missing. We wrote about the delivery half of that problem last week.

What we are not claiming

Fifteen features out of 554 is under three per cent, and most teams will never touch twelve of them. This is not an argument that the web platform is unreliable, or that Baseline is wrong. Baseline answers the question it was designed to answer, accurately.

The caveats on our own numbers: every condition here is caniuse’s reporting rather than our own device testing, and notes go stale. Filtering 46 cells down to 28 by hand is a judgement call, and a stricter reader would drop the Android 8 and macOS 10.13 rows as effectively universal by now. The caniuse dataset carries 554 features while caniuse-lite ships 583 files, a discrepancy we have not chased.

What to do about it

Treat media and GPU features as capability-detected, never version-gated. Every codec row above, plus WebGPU, needs a runtime probe: MediaCapabilities.decodingInfo() for video, navigator.gpu.requestAdapter() for WebGPU, an Accept-Encoding check at the edge for zstd. Your config cannot answer these and should not be asked to.

Add an OS dimension to the test matrix for the handful of features that need it. Not the whole grid. An iPhone and an iPad are two entries, not one, if you use fullscreen or MSE. An Intel Mac and an Apple Silicon Mac are two entries if you use WebGPU.

Read the note, not the letter. When caniuse says partial, the prose is the deliverable, and the five Safari partials with no prose are a signal to go and test rather than assume.

Write the support policy in prose alongside the config. A browserslist line cannot express “Firefox on macOS without Full Keyboard Access” or “iPhone but not iPad”. A paragraph in the repository can, and it is what a new engineer reads before trusting the config. The same argument applies to support floors.

REPTILEHAUS builds and maintains web applications where this decides whether a feature ships or gets pulled in week three. If you want a support policy that survives contact with real devices, or a frontend audit that reads the notes rather than the letters, get in touch.

All figures measured first-hand on 14 October 2026 against the live caniuse dataset, caniuse-lite 1.0.30001816, web-features 3.42.0 and the browserslist grammar specification. Support conditions quoted from caniuse note text.

📷 Photo by Firmbee.com on Unsplash