Hacker News Reader

Comment by rado | Hacker News Reader

Had this issue on Safari only, not Chrome. I wish browsers would fix the basics before taking on ambitious new features.

View on HN

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.

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

(This also appears in the latest Editor’s Draft.)

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.

0 is 0 in all absolute units.

This is a darn good answer! :)

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.

Because it has the exception for zero everywhere else except there. It's inconsistent.

IMHO the issue is that an exception for zero exists at all. Units should be required in all places.

It doesn't. Lengths are the exception that allows unitless zero, not the other way around.

Because it’s valid in all other contexts.

Reply on news.ycombinator.com