Safari 26.6 landed on July 27, 2026, and its headline is a WebAssembly options parameter. I read that sentence and nearly closed the tab. Then I got to the bug list, and three of the eight fixes turned out to be CSS problems that had been quietly changing what shipped stylesheets do on real devices.
So why write up a maintenance release at all? Because nobody else does. There's no feature to demo, and a fixed rendering bug still changes your site's behaviour on every updated device without you deploying anything, which makes it more urgent than a feature you get to adopt on your own schedule.
TL;DR: Safari 26.6 adds one WebAssembly change and eight bug fixes. Three of the fixes are CSS: the
iclength unit scaling wrongly under page zoom,position-areafailing to fall back on a scrollable body, and CSSzoommangling font properties in iPad desktop mode (WebKit, 2026).
What Safari 26.6 Actually Shipped, and When
One feature, eight repairs, six platforms. The feature is a compileOptions parameter on WebAssembly.compileStreaming() and WebAssembly.instantiateStreaming(), which means Wasm JS String Builtins no longer force you back to non-streaming compilation. Useful, narrow, and not a design concern.
The repairs are spread across five areas, and the CSS group is the biggest one:
| Area | Fixes |
|---|---|
| CSS | 3 |
| Service Workers | 2 |
| Networking | 1 |
| Web Extensions | 1 |
| WebRTC | 1 |
It ships on iOS 26.6, iPadOS 26.6, visionOS 26.6, macOS Tahoe 26.6, and back to macOS Sequoia and Sonoma. That reach is why I'd treat this as a live change rather than something to check next quarter. Users on three-year-old macOS versions get the new rendering behaviour too.
What Went Wrong With the ic Unit Under Page Zoom
One ic is the advance measure of the CJK water ideograph, U+6C34. It exists so a designer can say "this column is 20 characters wide" in a script where that's the meaningful measurement, rather than guessing in ems and hoping. When the browser can't work out that advance measure, the CSS specification tells it to assume 1em.
Safari 26.6 fixes a case where ic scaled incorrectly with page zoom, so it stopped equalling 1em the way the spec requires. Read that again with a zoom control in mind. A user at 125 percent got different column widths than a user at 100 percent, from the same stylesheet, with no media query involved.
Is this the most widely used unit in CSS? Obviously not. But zoom is an accessibility path, not an edge case, and a unit that drifts under zoom is a unit that breaks for exactly the people relying on it. If your type scale mixes relative units, the fix is a good excuse to re-derive your numbers rather than trusting the ones that happened to look right.
Why the position-area Fix Matters More Than the Feature
Anchor positioning shipped in Safari 26.0, and it's the reason tooltips, popovers and dropdowns can finally position themselves against a trigger without a JavaScript library measuring rectangles on every scroll frame. The whole value proposition rests on the fallback: you declare a preferred position, and the browser flips to an alternative when the preferred one would overflow.
That fallback had a hole. Safari 26.6 repairs position-area fallback on a scrollable body, where fixed-position elements refused to flip at all. OddBird documented the same class of problem in their anchor positioning write-up: with a scrollable containing block, the fallback simply never triggered.
A scrollable body is not an exotic condition. It's every long page you've ever built. So the practical shape of this bug was: correct CSS, correct fallback declaration, and a menu that ran off the bottom of the viewport anyway on one browser. Anyone who hit it probably blamed their own position-try-fallbacks and wrote a workaround. Delete the workaround.
Why iPad Desktop Mode Mangled Your Font Stack
Requesting the desktop website on iPad renders the page at a desktop viewport and scales it down, and that scaling shares plumbing with the CSS zoom property. Safari 26.6 fixes zoom interacting incorrectly with font-size, font-weight, font-variant and font-style in that specific mode.
Four properties. All typography. The symptom was type at the wrong size or weight on an iPad in desktop mode and correct everywhere else. When did you last check that mode? I've seen teams lose an afternoon to bugs shaped like this one, and the answer is usually not in their code.
What This Changes In Your CSS
Nothing you write. Everything you should check.
Retest these three things
- Any anchored overlay (tooltip, dropdown, popover) near the bottom or right edge of a long scrolling page, in Safari specifically.
- Your type scale at 125 and 150 percent browser zoom, if
icappears anywhere in it. - A representative page in iPad desktop mode, looking at weights and sizes rather than layout.
Feature-detect, don't version-sniff
None of this justifies a user-agent check. If you need to know whether anchor positioning is available at all, @supports (position-area: block-start) answers the question honestly and keeps working when Firefox and older Safari builds catch up. Version sniffing gets you a rule that's wrong on the next release, which is the same mistake people made writing up Chrome 150 features that actually shipped two versions later.
The wider lesson holds for any CSS layout system you maintain. Bug-fix releases move your rendering baseline silently, and relative units are the part most exposed. Define your sizing once and derive the rest, the way a fluid type scale does, rather than hand-tuning values per breakpoint until they look right on the machine in front of you.
Run the numbers yourself
The arithmetic above is easy to follow and easy to get wrong by a decimal place. Put your own sizes in below and the tool hands you the finished declaration, then drag the viewport slider to see where the curve flattens. It also checks the two limits this article cites, the 16px floor and the 2.5x ratio, while you type.
