[cssom] How should extremely small <number>s be serialized?

[csnardi]

According to https://drafts.csswg.org/cssom/#serializing-css-values:

A base-ten number using digits 0-9 (U+0030 to U+0039) in the shortest form possible, using "." to separate decimals (if any), rounding the value if necessary to not produce more than 6 decimals, preceded by "-" (U+002D) if it is negative.

Note: scientific notation is not used.

However, what should this return? (see https://jsfiddle.net/ko5k3uxx/1/)

div.style.opacity = "1e-8";
div.style.opacity;

In Firefox, the answer is 1e-8; in Chrome, 1e-08; and in Edge, 1e-008. Clearly, scientific notation is being used, but even if it wasn't, the correct answer per the spec would probably be 0, if I read that text correctly (it should probably be reworded, as "decimals" is slightly unclear -- I assume it means "numbers after the decimal point"). However, this wouldn't round trip the value.

[upsuper]

Looks like the spec doesn't agree with any of the implementation here.

I think the idea here should be to keep 6 decimals starting from the first non-zero decimal, i.e. leading zeros are excluded from the count, so something like 0.00123456789 would be serialized to 0.00123457. This matches the current behavior of Firefox and Chrome.

The reason to choose 6 decimals is probably because precision of a single precision floating-point number is only 7.22 decimals. I'm not sure whether it is safe to do 7 decimals, but it definitely shouldn't go beyond that.

Regarding the scientific notation, it seems Firefox starts using scientific notation when it is smaller than 1e-6, while Chrome starts doing so when smaller than 1e-4. Also Chrome starts using scientific notation when the number is not smaller than 1e6, while Firefox always serialize the whoe number if it is an integer.

I guess it makes sense to allow serialization to scientific notation on a boundary decided by implementations. This should be clarified in the spec.

[Nadya678]

But the integer values should never be serialized as scientific. I cannot imagine my script read element.style.zIndex as 1e3 instead of 1000. It will cause error in scripts.

[csnardi]

<integer>s should never be serialized with scientific notation according to the current text, as all it says is:

A base-ten integer using digits 0-9 (U+0030 to U+0039) in the shortest form possible, preceded by "-" (U+002D) if it is negative.

The only part that this leaves open is for other types e.g. <length>s, in which the spec says that they should be serialized as <number>s. Perhaps the spec could state that only <number>s that are smaller than 1e-6 (e.g. would round to 0 if attempted to be serialized per current rules`) can be serialized in scientific notation? I'm not sure what a good solution would be.

[v-python]

I just ran into this problem this week. It is clear that scientific notation is being used in some cases of number token serialization. It is clear that some values don't round-trip. It is clear that browser implementations vary from each other and vary from the spec. The spec is very clear that scientific notation should not be used. It is very clear that leading whole number zeros should be dropped, and trailing digits after the decimal point should be rounded to no more than 6 digits.

As debugging code, I was trying to verify that CSS values set by Javascript setProperty calls actually have good syntax. I wrote the following:

// Setting a custom property value to a bad value doesn't return or throw
// an error in all cases, so double-checking the resulting value can catch
// errors sooner.
let setckprop = ( sty, prop, val ) =>
{ sty.setProperty( prop, val );
let dblck = sty.getPropertyValue( prop );
if( dblck != val )
{ console.err(setckprop "${prop}" to "${val}" resulted in "${dblck}");
}
}

Testing with Firefox, it caught only error cases. Testing with Chrome and Safari produced console error messages for non-error cases involving numbers. I had started using CSS custom properties to hold a variety of values, some to be used in later CSS, some to be used in other ways, simply using the cascade to make them available. By reading MDN and experimenting with Firefox, I expected that would work, but in reading the spec, I see that browsers validate custom properties by tokenizing them, and then are allowed to return, via getPropertyValue, the result of serializing the token sequence. This makes it possible that the result of getPropertyValue is not identical with the value passed to SetProperty (even when !important is not included).

So after reading the spec, particularly the part about numbers, which caused all of the differences I had encountered, I wrote some test code, to verify that no browser is conforming to my understanding of the spec,

Here is my HTML test case:
mangler.html.txt

The output from Firefox is:
test 1 ________ property width: in_35em_out_35em_
test 2 MISMATCH property width: in_35.33333333333em_out_35.3333em_
test 3 MISMATCH property width: in_-47.3333333333em_out_35.3333em_
test 4 MISMATCH property width: in_aoheuts_out_35.3333em_
test 5 ________ property --val: in_35em_out_35em_
test 6 ________ property --val: in_35.33333333333em_out_35.33333333333em_
test 7 ________ property --val: in_-47.3333333333em_out_-47.3333333333em_
test 8 ________ property --val: in_353.3333333333em_out_353.3333333333em_
test 9 ________ property --val: in_3533.333333333em_out_3533.333333333em_
test 10 ________ property --val: in_35333.33333333em_out_35333.33333333em_
test 11 ________ property --val: in_353333333.3333em_out_353333333.3333em_
test 12 ________ property --val: in_aoheuts_out_aoheuts_
test 13 ________ property --val: in_blathery77.3333333333foo_out_blathery77.3333333333foo_
test 14 ________ property --val: in_zip code 08619-4455_out_zip code 08619-4455_
test 15 ________ property --val: in_credit card 4396338722196122_out_credit card 4396338722196122_
test 16 ________ property --val: in_product bar code 9223346311036_out_product bar code 9223346311036_
test 17 ________ property --val: in_color value 87654321_out_color value 87654321_
test 18 ________ property --val: in_(3.77777777777turn)out(3.77777777777turn)_
test 19 ________ property --val: in_turn3.777777777777_out_turn3.777777777777_
test 20 ________ property --val: in_turn 3.777777777777_out_turn 3.777777777777_
test 21 ________ property --val: in_.777777777777turn_out_.777777777777turn_
test 22 ________ property --val: in_turn.777777777777_out_turn.777777777777_
test 23 ________ property --val: in_really big 439633872219612243963387221961224396338722196122_out_really big 439633872219612243963387221961224396338722196122_

Number of mismatches: 3

It appears that Firefox returns a copy of the supplied parameter value in all cases where that value can be correctly tokenized, and used as a proper value for the specified property. This makes it possible to detect erroneous values with a simple comparison such as is implemented in setckprop. This is user friendly. However, it is clearly a violation of the spec for getPropertyValue, because the spec states that it should return a serialization of the token sequence, and the number serialization does not occur according to the rules for number token serialization. But it does have benefits: in addition to simplifying the validation that a value was acceptable, it round-trips: the return value can be used to achieve exactly the same effect as the original value (because it is the original value). Javascript that created the original value may with to retrieve it and modify it, and there are no surprises or complications.

In Chrome and Safari, the output is apparently NOT the original input, but instead is a result of the serialization of tokens... but they don't properly follow the serialization rules, which in some cases result in values which, if directly resubmitted to setPropertyValue would produce a different token sequence. This is not user-friendly. Not only is validation harder (it would require something far more complex than my naïve setckprop function), round-trips are also not possible.

Here is the Chrome output (Safari looked the same to me, so I won't include it here):

test 1 ________ property width: in_35em_out_35em_
test 2 MISMATCH property width: in_35.33333333333em_out_35.3333em_
test 3 MISMATCH property width: in_-47.3333333333em_out_35.3333em_
test 4 MISMATCH property width: in_aoheuts_out_35.3333em_
test 5 ________ property --val: in_35em_out_35em_
test 6 MISMATCH property --val: in_35.33333333333em_out_35.3333em_
test 7 MISMATCH property --val: in_-47.3333333333em_out_-47.3333em_
test 8 MISMATCH property --val: in_353.3333333333em_out_353.333em_
test 9 MISMATCH property --val: in_3533.333333333em_out_3533.33em_
test 10 MISMATCH property --val: in_35333.33333333em_out_35333.3em_
test 11 MISMATCH property --val: in_353333333.3333em_out_3.53333e+8em_
test 12 ________ property --val: in_aoheuts_out_aoheuts_
test 13 MISMATCH property --val: in_blathery77.3333333333foo_out_blathery770.333333foo_
test 14 MISMATCH property --val: in_zip code 08619-4455_out_zip code 8619-4455_
test 15 MISMATCH property --val: in_credit card 4396338722196122_out_credit card 4.39634e+15_
test 16 MISMATCH property --val: in_product bar code 9223346311036_out_product bar code 9.22335e+12_
test 17 MISMATCH property --val: in_color value 87654321_out_color value 8.76543e+7_
test 18 MISMATCH property --val: in_(3.77777777777turn)out(3.77778turn)_
test 19 MISMATCH property --val: in_turn3.777777777777_out_turn30.777778_
test 20 MISMATCH property --val: in_turn 3.777777777777_out_turn 3.77778_
test 21 MISMATCH property --val: in_.777777777777turn_out_0.777778turn_
test 22 MISMATCH property --val: in_turn.777777777777_out_turn0.777778_
test 23 MISMATCH property --val: in_really big 439633872219612243963387221961224396338722196122_out_really big 3.40282e+38_

Number of mismatches: 20

I'll discuss the MISMATCH results, and whether or not I think they are conformant.

tests 2, 3, 4, 6, 7, 8, 9, 10, 18, and 20 seem to be almost conformant. The "almost" is due to providing 6 digits of precision, rather than 6 decimal digits (digits after the decimal point).

tests 11, 15, 16, 17, and 23 are non-conformant, as they uses scientific notation in the output.

tests 13, 19, 21, and 22 are non-conformant, as they don't produce the smallest representation: Note that the "77" is part of the prior token, not part of the number token. The number token starts with the decimal point. The serialization is not minimal, because it produces a leading zero prior to the decimal point, which is not conformant because it is not minimal. The only "leading" zero that is appropriate for a minimal representation is if the value is exactly zero, or rounds to exactly zero.

test 14 is conformant, the leading zero is dropped.

So it is clear that because of the possibility of getting a returned value that is a result of serialization, that it is not practical to store "numeric-looking" values in CSS custom properties, except by converting them to strings with surrounding quotation marks.

It is clear that because setPropertyValue does not return a error value when an input parameter value is invalid, that a simple equality check between setProperty and getPropertyValue is insufficient to do verification (except in non-conformant Firefox).

It is clear that this is a specification of a bug-prone interface: one cannot easily determine if a value was valid and accepted, except by writing a complex external validation function (and good luck verifying it), nor can one round-trip values from getPropertyValue to setProperty and expect consistent results.

Returning an error code from setProperty that could be checked, or throwing an exception for invalid values would be far friendlier, or requiring behavior like Firefox presently has, in returning the original string if it is valid, would be far friendlier. Of course, if all the browsers actually conformed to the specification, that would be helpful for cross-platform development, as dependence on non-conformity of one browser leads to problems running on others.

With such an unfriendly spec, I'm in a quandary regarding writing bug reports for the various browsers. I hardly want Firefox to change, and conformance to the current spec is not particularly better than what any of them are currently doing.