Since many people apparently didn’t read TFA, the issue is that when you have an expression such as calc(100% - var(—-x)), it is invalid if var(—-x) is 0 with no units, which is otherwise valid in CSS. This is clearly a bug in the spec.
No, you’ve misunderstood it. calc(100% - 0) is invalid too. There is no bug in the spec, this is reasonable and sensible behaviour (subtracting a unitless value from a length just doesn’t make sense as a concept, mathematically). You’re just surprised because the <length> grammar item allows unitless zero. It is the exception, not the mathematics functions. (Frankly, I think that if breaking changes were allowed in CSS with absolutely no considerations for compatibility, unitless zero lengths would probably be removed. It’s messy and inconsistent and consequently unpleasant.) As an example of another thing that requires a unit on zeroes: <time>, 0 is invalid, 0s and 0ms are valid.
CSS variables are often set in JavaScript, the consumer of the variable is not necessarily the same person as the one who defined it (who perhaps did not anticipate its use in a calc() expression).
Given that unitless zero is automatically coerced to a length when used as a constant (e.g. padding: 0), it is certainly a bug that this automatic coercion does not also happen when it is used in an expression.
Rather it is a bug that properties that accept lengths allow a literal zero—a design bug that won’t be fixed for compatibility reasons, but which strongly should not be propagated into new work. This is why not even `padding: calc(0)` works.
CSS is typed. Every other context requires units, and computed values always have a unit.
Especially because, as TFA points out, you might have even yourself written "0px" but your CSS linter "compressed" it to 0, thus making it invalid after compilation. This seems like an annoying thing to have to account for CSS compilers.
Any CSS processor that unconditionally removes the unit from zero values is clearly wrong. Any processing should be following the CSS grammar rather than being naive textual, and thus it should only be removing the unit of zeroes in <length> contexts—so properties like border-top-width and left and height, but not custom properties or mathematical functions, because in each of those cases it changes the semantics.
To be honest this isn't that strange, the parser needs to know what denomination you're trying to subtract.. Also as per the spec the `-` operand requires a whitespace. So it's not actually valid to use (100& -0) you're getting a false positive..
In this case though you're adding a 'special' condition for the parser/processor. Of course you could do it but as per the spec its not required - I'm just looking up the schema now to find the reference.
Example is you can * no problem, its expecting only a number for the 'read_next' but with the `-' it's expecting a denomination, otherwise it needs to keep a 'state' as such when moving on from reading a `0`
Edit : as pointed out by zarzavat : it does seem to be a bug in the spec in this case.
"For lengths, you can't use 0 to mean 0px (or another length unit); instead, you must use the version with the unit: margin-top: calc(0px + 20px); is valid, while margin-top: calc(0 + 20px); is invalid."
There’s nothing to fix, basic or otherwise. Safari is following the specification. There’s even a clarifying note about exactly this:
> Because <number-token>s are always interpreted as <number>s or <integer>s, "unitless 0" <length>s aren’t supported in math functions. That is, width: calc(0 + 5px); is invalid, because it’s trying to add a <number> to a <length>, even though both width: 0; and width: 5px; are valid.
In my case, that zero comes from a variable, which changes depending on context. I'm not trying to break the browser or be funny. It works fine in Chrome.
This isn’t a problem though. Why would the browser assume you’re subtracting px and not em or rem or most obviously %?
Note your preprocessor may be overly ambitious with stripping units, which I think is frankly a dumb linter rule always, but that’s not the browser’s fault.
But why should the browser have an exception for that, when subtracting zero is a no-op in the first place, and thus is pointless to even be asking it to do?
Because browsers themselves have set that expectation by accepting unitless 0 in most (all?) other places in CSS. e.g. "margin: 3px 0 4em 0" is a valid way to set the right and left margins to 0px.
