[Webkit-unassigned] [Bug 218880] Serialize CSS <number> values with rounding, limited decimal precision, and no exponents per-spec

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=218880

--- Comment #13 from Tyler Wilcock <twilco.o at protonmail.com> ---
Thanks for the review, Darin!

> This does seem to match the specification language, but I’m not sure there’s enough test
> coverage of edge cases for this, even in WPT. I’d like to see more test
> cases.
OK, I'll craft some more testcases.

> > Source/WTF/wtf/dtoa.cpp:123
> > +        // If we've truncated the trailing zeros and a trailing decimal, we may have a -0. Remove the negative sign in this case.
> > +        if (builder.position() == 2 && buffer[0] == '-' && buffer[1] == '0')
> > +            builder.RemoveCharacters(0, 1);
> 
> What about the case where the value *is* negative zero?
That is an interesting question.  Doing a bit of spec-lunking: 

https://www.w3.org/TR/css-values-4

> Additionally, IEEE-754 introduces the concept of "negative zero", which must be tracked within a calculation and between nested calculations...
> Note: Note that negative zeros don’t escape a math function; as detailed below, they’re "censored" away into an "unsigned" zero.
This seems to suggest negative zeros are disallowed outside math function context.  And given this:

<style> #target { font-size: -0px; } </style>
<div id="target">abc</div>
<script>
    let target = document.getElementById('target')
    let result = document.createTextNode(
        `getComputedStyle font-size: ${window.getComputedStyle(target)['font-size']}`
    )
    document.body.appendChild(result)
</script>

Chromium, WebKit, and Gecko currently serialize a 0px font-size.

In contrast, negative zero is technically valid according to the definition of <integer> (https://drafts.csswg.org/cssom/#ref-for-integer-value)

> 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.
MDN (while not authoritative) also explicitly states negative zero is valid (https://developer.mozilla.org/en-US/docs/Web/CSS/integer).

And as another data point, CSS2 states negative zero is the same as zero, and not actually negative.

https://www.w3.org/TR/CSS2/syndata.html#numbers

Based on my current implementation, allowing negative zero will result in some web animation tests serializing with negative zeros.  For example, this one:

https://github.com/WebKit/webkit/blob/4b9823872aa4c74dac7080e5ebf6c86b54bb0f95/LayoutTests/imported/w3c/web-platform-tests/css/css-transforms/animation/matrix-interpolation-expected.txt

May look something like:

...but got matrix3d ( 1 , 0 , - 0 , - 0 , 0 , 1, ... )

However, since -0 seems to be valid, maybe it's OK.  I can try removing the aforementioned code.

> > Source/WTF/wtf/text/WTFString.cpp:510
> > +String String::numberToStringFixedWidth(double number, unsigned decimalPlaces, TrailingZerosTruncatingPolicy trailingZerosTruncatingPolicy)
> 
> I think you could use a shorter name for this local, since its scope is
> really small and there is no ambiguity. Maybe just "policy" in fact.
Agreed.

> > Source/WebCore/css/CSSPrimitiveValue.cpp:909
> > +    return makeString(String::numberToStringFixedWidth(m_value.num, 6, TruncateTrailingZeros), suffix);
> 
> Instead of String::numberToStringFixedWidth, this should be using
> FormattedNumber::fixedWidth. That is more efficient and avoids allocating
> memory every time. 
Really helpful, thanks — will do this.

> > LayoutTests/imported/w3c/web-platform-tests/css/css-flexbox/animation/flex-shrink-interpolation-expected.txt:22
> > -FAIL Web Animations: property <flex-shrink> from neutral to [2] at (0.3) should be [1.65] assert_equals: expected "1.65 " but got "1.55 "
> > +FAIL Web Animations: property <flex-shrink> from neutral to [2] at (0.3) should be [1.65] assert_equals: expected "1.65 " but got "1.54 "
> 
> What explains this change and the others like it, where the second digit
> after the decimal point changes?
That is a good question.  Let me look more into these.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20201116/f6168e5d/attachment-0001.htm>