4 ms·

CSS calc(100% – 0) is invalid, but calc(100% - 0px) is valid

40 points by mrzool 4y ago

bilekas 4y ago
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.. https://developer.mozilla.org/en-US/docs/Web/CSS/calc#notes https://developer.mozilla.org/en-US/docs/Web/CSS/calc#notes
- mrzool 4y ago
  > Also as per the spec the `-` operand requires a whitespace Thanks, my bad. I fixed the title.
- Izkata 4y ago
  But 0 is 0 in every unit, and because of that units aren't required for 0 anywhere else.
  - bilekas 4y ago
    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.
    - Izkata 4y ago
      > Edit : as pointed out by zarzavat : it does seem to be a bug in the spec in this case. Pretty much what we're saying. It also fails when typed directly, at least in Firefox (as unnecessary as that 0 is).
  - milliams 4y ago
    > But 0 is 0 in every unit While that might be true for all the length units defined in CSS, it's not true in general. E.g. in temperature, 0F != 0C
    - bilekas 4y ago
      I get where you're coming from, and I think you were pedantically downvoted but it's unsafe to assume 0 as 0.. :)
rado 4y ago
Had this issue on Safari only, not Chrome. I wish browsers would fix the basics before taking on ambitious new features.
- ethanbond 4y ago
  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.
  - zamalek 4y ago
    0 is 0 in all absolute units.
    - danaris 4y ago
      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?
      - SeanLuke 4y ago
        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.
        seba_dos1 4y ago
        It doesn't. Lengths are the exception that allows unitless zero, not the other way around.
      - zarzavat 4y ago
        Because it’s valid in all other contexts.
      - 4y ago
deleted 4y ago
[deleted]
zarzavat 4y ago
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.
- tolmasky 4y ago
  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.
  - chrismorgan 4y ago
    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.
- chrismorgan 4y ago
  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.
  - zarzavat 4y ago
    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.
mike_tempest 4y ago
This is obvious why it is invalid, 0 doesn't have an associated unit so the compiler doesn't understand.
- chownie 4y ago
  It accepts unitless zero in other contexts, which makes this scenario a lot less obvious
croes 4y ago
From MDN "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." https://developer.mozilla.org/en-US/docs/Web/CSS/calc?retiredLocale=de https://developer.mozilla.org/en-US/docs/Web/CSS/calc?retire...
leephillips 4y ago
Maybe CSS is evolving toward TeX?
beardyw 4y ago
I am a great proponent of the unitless zero pretty much everywhere. I am pleased CSS supports it. An empty chicken shed is just a shed. Sadly here it does force a special case where it either becomes a nop or it adopts the units required. Not sure which is best.
compressedgas 4y ago
Indirect post of https://www.oddbird.net/2022/08/04/zero-units/ https://www.oddbird.net/2022/08/04/zero-units/
seba_dos1 4y ago
This is something that, if you have any experience with CSS, seems confusing for a few seconds but then simply makes perfect sense.

40 points by mrzool 4y ago

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.. https://developer.mozilla.org/en-US/docs/Web/CSS/calc#notes https://developer.mozilla.org/en-US/docs/Web/CSS/calc#notes

mrzool 4y ago
> Also as per the spec the `-` operand requires a whitespace Thanks, my bad. I fixed the title.
Izkata 4y ago
But 0 is 0 in every unit, and because of that units aren't required for 0 anywhere else.
- bilekas 4y ago
  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.
  - Izkata 4y ago
    > Edit : as pointed out by zarzavat : it does seem to be a bug in the spec in this case. Pretty much what we're saying. It also fails when typed directly, at least in Firefox (as unnecessary as that 0 is).
- milliams 4y ago
  > But 0 is 0 in every unit While that might be true for all the length units defined in CSS, it's not true in general. E.g. in temperature, 0F != 0C
  - bilekas 4y ago
    I get where you're coming from, and I think you were pedantically downvoted but it's unsafe to assume 0 as 0.. :)

rado 4y ago

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

ethanbond 4y ago
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.
- zamalek 4y ago
  0 is 0 in all absolute units.
  - danaris 4y ago
    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?
    - SeanLuke 4y ago
      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.
      - seba_dos1 4y ago
        It doesn't. Lengths are the exception that allows unitless zero, not the other way around.
    - zarzavat 4y ago
      Because it’s valid in all other contexts.
    - 4y ago

deleted 4y ago

[deleted]

zarzavat 4y ago

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.

tolmasky 4y ago
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.
- chrismorgan 4y ago
  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.
chrismorgan 4y ago
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.
- zarzavat 4y ago
  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.

mike_tempest 4y ago

This is obvious why it is invalid, 0 doesn't have an associated unit so the compiler doesn't understand.

chownie 4y ago
It accepts unitless zero in other contexts, which makes this scenario a lot less obvious

croes 4y ago

From MDN "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." https://developer.mozilla.org/en-US/docs/Web/CSS/calc?retiredLocale=de https://developer.mozilla.org/en-US/docs/Web/CSS/calc?retire...

leephillips 4y ago

Maybe CSS is evolving toward TeX?

beardyw 4y ago

I am a great proponent of the unitless zero pretty much everywhere. I am pleased CSS supports it. An empty chicken shed is just a shed. Sadly here it does force a special case where it either becomes a nop or it adopts the units required. Not sure which is best.

compressedgas 4y ago

Indirect post of https://www.oddbird.net/2022/08/04/zero-units/ https://www.oddbird.net/2022/08/04/zero-units/

seba_dos1 4y ago

This is something that, if you have any experience with CSS, seems confusing for a few seconds but then simply makes perfect sense.