Elementary Standards
HTMLCSSWeb StandardsSEOBlogStart reading
Home / Blog / Firefox 158 Ships CSS Typed Arithmetic
News

Firefox 158 Ships CSS Typed Arithmetic, Closing the calc() Gap

The last gap in cross-browser calc() math just closed — dividing mismatched units now produces a usable number, not an invalid declaration.

6 min read·2026-10-14

Firefox 158 went to release on October 13, 2026, and buried under the headline JPEG XL support is a change that matters more to anyone who writes math-heavy CSS: typed arithmetic in calc(). Mozilla's own release notes and developer documentation confirm the ship date and describe the feature in detail, and independent coverage from outlets including 9to5Linux and OMG! Ubuntu independently verified the release the same day. Chrome shipped the same capability back at version 140, and Safari landed it in Safari 26 — Firefox 158 is what finally makes it safe to rely on in production without a fallback.

calc(100vw / 1px)unitless NChrome 140Safari 26Firefox 158

What changed in calc()

Before this release, calc() let you add and subtract values of the same type (two lengths, two angles) and multiply or divide by a plain number. What it would not let you do, in any shipping engine until Chrome 140 and Safari 26, was divide one typed value by another typed value of the same kind but a different unit — say, viewport width by pixels — and get a clean, reusable number back out. The CSS Values and Units module update that enables this is what the spec calls typed arithmetic, and MDN's guide lays out the exact rules.

The shape of it:

calc(100px / 10mm)   /* valid: same type (length), different units → unitless number */
calc(1000px / 2)     /* valid: always was — dividing by a plain number */
calc(1000 / 2px)     /* still invalid: unitless ÷ typed value doesn't resolve */

Addition and subtraction keep their existing rule — both sides must be the same data type, so calc(200px + 100ms) is still nonsense and still an invalid declaration, not a silent zero. Multiplication also keeps its old constraint: only one side of a product can carry a unit. Division is the one operation that got new powers, and only between two values of the same type.

Why this is more than a syntax footnote

The practical unlock is turning a viewport or container measurement into a plain number you can feed back into other property values — building ratios and breakpoint-free scaling without reaching for JavaScript or a preprocessor. MDN's own example captures the pattern:

:root {
  --viewport-in-pixels: calc(100vw / 1px);
}

p {
  font-size: calc(1em * (var(--viewport-in-pixels) / 200));
}

That single custom property becomes a reusable, unitless handle on the viewport width. Multiply it back against an em for fluid type, feed it into an lch() hue rotation, or use it to drive a counter — any place a property expects a plain number, this now works. Teams doing standards-compliant web development have been reaching for Sass functions or inline style calculations to do exactly this kind of unit conversion; typed arithmetic moves it into native CSS with no build step and no runtime script.

What this means for developers

When does this reach universal baseline

With Chrome 140, Safari 26, and now Firefox 158 all shipping, typed arithmetic has the three-engine support that Baseline typically requires before marking a feature "widely available" — though Baseline's own criteria also account for time-in-market, so expect the formal status update to lag the Firefox release by a cycle or two. For greenfield work, three-engine support today is already a reasonable bar to build against.

Back to the blog
More notes

Keep reading