[geometry] DOMMatrix stringifier behavior doesn't seem to match implementations #120
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.
The text was updated successfully, but these errors were encountered:
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
Related is how to serialize non-finite values.
The CSS Working Group just discussed
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.
<dael> zcorpan: I think the most reasonable things is to just use script to string.
<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.
<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.
Since it came up in the discussion, one practical case where a DOMMatrix would have infinite values is
Note: I just tested, and neither Chrome nor Firefox currently actually use
The other cases where you you'd get non-finite values in a matrix are where you tried to invert a non-invertable matrix (like
You wouldn't expect these matrices to have CSS-parse-able equivalents, though. Skews are a special case because the non-finite matrix representation has a finite transform-function representation.
Also, so it doesn't get forgotten: The main substance of this issue still needs to be resolved.
When you stringify a matrix to CSS notation, do you follow the "6-decimals & no scientific notation rule" from CSSOM, or do you maintain full double precision, or what? Currently, Firefox and Chrome seem to use 6-digit precision (which isn't the same as 6-decimals) with scientific notation:
m = new DOMMatrix(); m.a = 1/3; m.b = 1/300000; m.c = 100000 + (1/3); m.d = Number.MAX_SAFE_INTEGER; "" + m; // Chrome 58 & Firefox 54 both return: // "matrix(0.333333, 3.33333e-06, 100000, 9.0072e+15, 0, 0)"
@AmeliaBR thanks for the examples for Infinity and NaN!
I missed to bring up on the call the precision issue. In #148 I defined it in terms of JS's
It seems in Safari TP for
None of the current browser implementations match CSSOM's serialization rule for numbers.
I think JS