Dividing Scalars in calc()

[nmn]

Description

Calc currently doesn’t allow dividing one length by another.

Change this to allow dividing any pair of values than can be added and return a unit-less number. This number can then be used in various different scenarios.

A specification for this exists for many years. It’s possible to do this already using atan2() function with slightly buggy results in some browsers.

There are some very useful use cases where this would dramatically simplify layout code which would otherwise need a large number of container queries.

Specification

W3C: https://www.w3.org/TR/css-values-4/#calc-type-checking

Tests

css/css-values/getComputedStyle-calc-mixed-units-003.html
css/css-values/calc-in-media-queries-with-mixed-units.html

Browser bug reports

WebKit: https://bugs.webkit.org/show_bug.cgi?id=255280
Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1827404
Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1432187 and https://bugs.chromium.org/p/chromium/issues/detail?id=1213338

Additional Signals

This is a purely additive feature that should not cause any regressions.

• https://twitter.com/anatudor/status/1537881090223853568

[nt1m]

See last year's proposal for more context: #513

[nmn]

Let me quickly provide my own use-case for this:

I want a horizontally scrollable list of cards where the cards fit the available space perfectly regardless of the available space. This a fluid grid, but with all the rows combined on a single row.

This is how this ability in calc would make that possible:

width: calc(100% / round(down, 100% / var(--min-card-width)))

/* or with small parts */
--num-cards-that-fit: round(down, 100% / var(--min-card-width));
width: calc(100% / var(--num-cards-that-fit));

Without this calc function, we can use a long list of @container queries instead.
In production, I use a huge amount of nested clamp() function calls with the "fab-four technique". It works today, but it's ugly, unmaintainable code. Dividing lengths with calc would make it clean and obvious.

[scottkellum]

Great to see this here thanks for the submission @nmn 👍🏻 I submitted this last year and there has been progress, with Webkit supporting this in Safari TP 203.

My implementation and use case:

• https://github.com/Typetura/Typetura/blob/v4/typetura.css#L33
• I wrote up a post about it here: https://typetura.com/blog/unit-division-with-css-and-fallbacks/

[wpt-interop]

Thank you for proposing Dividing Scalars in calc() for inclusion in Interop 2025.

We wanted to let you know that this proposal was not selected to be part of Interop this year.

On behalf of the entire Interop team, thank you for submitting this proposal for consideration. We got many more proposals than we could include in this year's project, necessitating some difficult choices. Please note this should not be taken as a comment on the technology as a whole, or our willingness to consider it for Interop in the future. We appreciate the work you put into your proposal, and would welcome your participation in future rounds of Interop.

For an overview of our process, see proposal selection. Thank you again for contributing to Interop 2025.

Posted on behalf of the Interop team.

[nmn]

I received responses to all my proposals but this is the only one I find a bit perplexing. This feature has already shipped in Safari and Chrome in recent months. Is there major pushback from Firefox for implementing this or was this feature seen as something that is going to ship while not being on the interop priority list?

[benface]

is feature has already shipped in Safari and Chrome in recent months.

Safari yes, but I don't see that Chrome shipped it? The Codepen in this article requires the polyfill to work, even in Chrome Canary 135.0.7017.0.

[nmn]

@benface I was told it had either shipped or was about to ship. Chrome does support the feature by using a workaround based on atan2 so it feels like something the engine already supports even if it is not supported in calc.

The atan2 trick works in Firefox too. This is why I find it strange that they wouldn't all decide to just add it to calc. I don't see why it would be a controversial or difficult thing to do.

[scottkellum]

@nmn Safari only for now. It's disappointing to see this feature that clearly has solid community support continue to be looked over by browser vendors. Such is life, we'll try again next year and the year after that until it's baseline.

[foolip]

Interop 2025 launched last week and I've been going through comments on proposals before closing them. I don't want anyone to be perplexed so I will try my best to give some useful feedback here. Note that I'm not speaking on behalf of the Interop team.

This proposal was specifically for dividing length units. There is the tan(atan2()) trick, but it doesn't always work and isn't a foundation to build on. You can +1 and follow https://crbug.com/40768696 for progress on typed math (including division) in Chromium.

The new progress functions might also help with some use cases. I believe the syntax will be progress(50px, 0, 100vh) instead of calc(50px / 100vh) or the tan(atan2(50px, 100vh)) trick, neither of which work in Chromium AFAICT.

Thank you @nmn for proposing this and everyone for giving examples. I think the use cases and developer demand for this are clear. If it's not solved by the time Interop 2026 opens for proposals, I hope you'll consider proposing it again.

I'll go ahead and close the issue now, and sorry it wasn't the outcome you were hoping for.

[nmn]

Thanks for the explanation @foolip, hopefully this is something that happens in 2025 despite not being on the interop list (which is a great list on its own)