[geometry] DOMMatrix stringifier behavior doesn't seem to match implementations

[bzbarsky]

The spec says to just append the values of the (double) attributes to the string. But implementations seem to be appending as floats or something; they are certainly appending a much lower precision than a double would give.

[foolip]

@cabanier, any ideas for how to align spec with Blink and other implementations?

[gogag2]

I'd like to change Blink following the spec.
Link: https://codereview.chromium.org/2846523002/

[zcorpan]

The patch has this change to a test

-  assert_equals(matrix2d.toString(), "matrix(1, 2, 3, 3.1, 2, 1)");
+  assert_equals(matrix2d.toString(), "matrix(1.000000, 2.000000, 3.000000, 3.100000, 2.000000, 1.000000)");

It is not clear to me that this is a desirable result.

https://html.spec.whatwg.org/multipage/infrastructure.html#best-representation-of-the-number-as-a-floating-point-number uses JS's ToString, which doesn't produce trailing zeros. But can still represent double precision, right?

Related is how to serialize non-finite values. NaN and Infinity are invalid CSS keywords, so it wouldn't successfully parse again...

[zcorpan]

There's also https://drafts.csswg.org/cssom/#serialize-a-css-component-value :

<number>
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.

[gogag2]

Could I use String::NumberToStringECMAScript(double number) function?
I think it can represent double precision and serialize non-finite values.
Could you review my code?
https://codereview.chromium.org/2846523002/

Thanks.

[zcorpan]

I think using JS ToString is reasonable here, notwithstanding that non-finite values fail to roundtrip (that is already the case in Chromium and Gecko anyway). Adding Agenda+ (and emailed w3c-css-wg) to discuss this on the CSSWG telecon tomorrow.

[css-meeting-bot]

The CSS Working Group just discussed DOMMatrix stringifier behavior doesn't seem to match implementations, and agreed to the following resolutions:

• RESOLVED: In the case of NaN we would throw an exception during serialization.

The full IRC log of that discussion

<dael> Topic: DOMMatrix stringifier behavior doesn't seem to match implementations
<dael> github topic: https://github.com//issues/120
<dael> zcorpan: DOM Matrix has [missed] for parsing a string. The string is CSS syntax. Values are unrestricted doubles so you can have non and infinity and it's unclear whaht the serialized is to do. If it teruns non and infitity with JS.
<smfr> s/non/NaN/
<dael> zcorpan: I think the most reasonable things is to just use script to string.
<zcorpan> s/script/ECMAScript/
<dael> TabAtkins: I asked in the related thread what's the benefit of allowing infinity and NaN in CSS and I'm not sure how the thread on DOMMRect you pointed to answer the question.
<dbaron> my telephone connection apparently isn't good enough for webex to understand the pin
<dael> TabAtkins: At the bottom of fxtf draft you reference the issue 1343 in CSS.
<dael> TabAtkins: You prop CSS syntax should allow infinity and NaN so DOMMatric can round trip. I asked what was the benefit and you pointed to another thread.
<dael> zcorpan: It does cover DOMMatrixin that thread. It's part of the thread.
<dael> zcorpan: It's with one level of quotation for the reason of using unrestricted double i n geometry APIs.
<smfr> TabAtkins is referring to https://github.com/w3c/csswg-drafts/issues/1343
<dael> TabAtkins: What transforms can produce a NaN or infinity in here?
<dael> zcorpan: I'm not sure if it's possible.
<dael> TabAtkins: We don't allow the values. It can't be possible b/c then we'd have transforms without matrix.
<dael> ChrisL: You can generate one and reserialize it.
<dael> zcorpan: Exactly. If you do 1/0 it's an error now but it could be infinity instead.
<dael> TabAtkins: It could in theory but it doesn't yet and we don't have a proposal to do it yet. afaict the only thigns that can produce NaN or infinity are operations we don't allow. I'm still not clear on the benefit of allowing CSS to recognize them because it doesn't mean anything in CSS> IF you gave this to transform what would it do?
<dael> zcorpan: I don't know. How matrix work is above my head, but you can end up with NaN and infinity so I wanted to get a resolution on how this would parse. I don't have a use case for it.
<dael> TabAtkins: Alternative is in other cases where you can get into a state with a value that cannot be represented we jsut give up and do the empty string when you serialize. Can we do that? If you as for the CSS Serialization of a string with NaN or infinity you get an empty string.
<dael> zcorpan: Reasonable. I can live with that.
<dael> smfr: I know we're getting an empty string...
<dael> zcorpan: If you parse it again you get an indednty matrix.
<dael> Rossen: zcorpan you're okay with TabAtkins resolution I think. Is there anything else to explore on this?
<dael> zcorpan: Consensus on TabAtkins proposal sounds good.
<smfr> smfr: ; I don’t think think that returning an empty string is developer-friendly
<smfr> authors won’t know why they got an empty string
<dael> TabAtkins: smfr is disagreeing. Thanks for clarifying.
<dael> TabAtkins: I don't know what else you can do, though. The to string of DOM produces CSS matrix. If you have a matrix that can't be a valid CSS transform, what are you supposed to do?
<dael> smfr: Throw exception.
<dael> zcorpan: What happens in Chrome & Gecko you serialize NaN. When you parse you get an error.
<dael> Rossen: I still don't get what happens when you try and roundtrip. What's the expected behavior when you parse back.
<dael> TabAtkins: Yeah, it fails to parse.
<zcorpan> SyntaxError
<dael> Rossen: So if this was an error on input, why not an error on output?
<dael> TabAtkins: I'm okay with throwing as well. Just something that indicates the to string failed.
<dael> Rossen: That's what I'd lean towards as well.
<dael> Rossen: Let's try to resolve. Prop: In the case of NaN we would throw an exception during serialization.
<dael> Rossen: Objections?
<dael> RESOLVED: In the case of NaN we would throw an exception during serialization.
<zcorpan> InvalidStateError?