[css-syntax-3][css-values-4] Add informative note about tokenization of negative 0

[cdoublev]

I cannot tell which behavior is "right", if there is one, and I cannot think of an example for which it could matter, but I feel like an informative note (something like the note removed in this commit) about removing the sign of 0⁻ in convert a string to a number is required, especially in regards to calculations because a consequence is that calc(1 / -0) is calc(infinity) instead of calc(-infinity), which matches the output in JS, which performs division according to the rules of IEEE 754-2019, whereas in Type Checking (CSS Values):

Math functions follow IEEE-754 semantics for these operations

• Dividing a positive value by zero produces +∞.
• Dividing a negative value by zero produces −∞.

[...]

In other words, multiplying or dividing with 0⁻ follows standard sign rules

Can you also please tell me if there is any other difference between convert a string to a number and JS Number(), please?

[tabatkins]

Writing -0 in your CSS does not produce a negative zero; as you point out, the "convert a string to a number" algorithm produces the mathematical number zero, rather than the IEEE-754 signed zero. This is why all the examples in V&U that talk about negative zero produce it via a calculation, like (-5 * 0), or handwave about the value space with 0⁺/0^- which clearly aren't actually valid CSS.

(something like the note removed in this commit)

Note that I didn't remove anything in that commit, I just switched from a misleading way to writing negative zero (-0, which looks like it's valid CSS) to a less-misleading way (0^-).

I'm somewhat loathe to put an explicit note or example about this into the spec, because it's a corner case that matters to approximately zero authors. For implementors, the right behavior just falls out if they follow the specs.

Can you also please tell me if there is any other difference between convert a string to a number and JS Number(), please?

I didn't write the algorithm with any regard to JS's algorithm, but I expect they're probably very similar? I know that there's at least one difference, tho - "-0" produces a negative zero in JS, but not in CSS.

(If implementations are indeed producing a negative zero from -0 in CSS, I'd be fine with changing Syntax to match, tho.)

[cdoublev]

Note that I didn't remove anything in that commit

I was referring to this part: Note: that, outside of [=math functions=], ''-0'' just produces a "standard" zero, identical to ''0''-- CSS as a whole doesn't recognize the concept of signed zeros.

Without this note, if CSS claims that it obeys IEE754 semantics for dividing a positive value by zero produces +∞, I can not know why calc(1 / -0) is not calc(-infinity)...

I'm somewhat loathe to put an explicit note or example about this into the spec, because it's a corner case that matters to approximately zero authors.

... but I'm fine with this position, ok.

For implementors, the right behavior just falls out if they follow the specs.

For a JS implementation of conversion from string to number, following the spec does not help. I have to return unsigned 0 if the conversion equals 0.

I didn't write the algorithm with any regard to JS's algorithm, but I expect they're probably very similar? I know that there's at least one difference, tho - "-0" produces a negative zero in JS, but not in CSS.

I think there is no other difference. From reading the JS spec, I can only note that 'Infinity', and decimal numbers in the exponent part, are valid but they are not allowed by the CSS grammar, therefore it does not matter.

[tabatkins]

For a JS implementation of conversion from string to number, following the spec does not help. I have to return unsigned 0 if the conversion equals 0.

Actually, upon review you're right - the "convert a string to a number" algorithm will, upon seeing "-0", set s to -1, i to 0, the other parts to their default values, and then the expression at the end will multiply -1 by 0 and yield -0 in any IEEE-754-compatible language.

So that's a bug on my part and should be fixed.

[cdoublev]

I came back to this issue after a while and I am not entirely sure of your intention, because of this comment:

-0 looks like it's valid CSS

It is valid CSS.

I assume you do not want to make it invalid, but to remove its sign in convert a string to number, right?

Basically:

  2. An integer part: zero or more digits. If there is at least one digit, 
     let i be the number formed by interpreting the digits as a base-10 integer; 
     otherwise, let i be the number 0.
+    If i is the number 0, set s to 1.

So calc(-1 / -0) would result to -infinity?

Alternatively, -0 could be a special case in serialize a CSS component value. It would match the JS behavior:

-0; // -0
(-0).toString(); // '0'

But I may be missing the historical reasons for CSS not recognizing the sign of 0.

[tabatkins]

It is valid CSS.

Right, and that was the problem - I was trying to refer to a negative zero, but -0 in CSS does not produce a negative zero, it just produces the unsigned zero. So writing something that appears to be interpretable as CSS, but refers to something other than what that CSS would produce, was misleading. That's why I switched to the 0^- notation instead, as it's clearly not CSS, and thus can't be misread in that way.

So calc(-1 / -0) would result to -infinity?

Right. Like I said, "This is why all the examples in V&U that talk about negative zero produce it via a calculation", rather than writing -0 because that won't work, per spec.

[cdoublev]

Fixed in 3560680, isn't it?

Edit: nope, sorry, it does not.

[tabatkins]

Right, that commit's irrelevant to this issue.