Re: [csswg-drafts] [css-values-4] Specify that calculation trees explicitly work in double precision (#4551)

The CSS Working Group just discussed `Double precision math in calc()`, and agreed to the following:

* `RESOLVED: Math precision in CSS is currently kept undefined`

<details><summary>The full IRC log of that discussion</summary>
&lt;fremy> Topic: Double precision math in calc()<br>
&lt;RossenTheReal> github: https://github.com/w3c/csswg-drafts/issues/4551<br>
&lt;TabAtkins> https://twitter.com/starsandrobots/status/1199757377286754309<br>
&lt;myles> s/-infinity sounds odd/does - have to be followed by a digit in order to be classified as a negation? can we actually do -infinity without a parser change?/<br>
&lt;fremy> TabAtkins: somebody mentioned that you can use int precision in Blink to implement mod()<br>
&lt;tantek_> -1nfinity<br>
&lt;fremy> TabAtkins: this is ridiculous, and I think it shouldn't work<br>
&lt;fremy> dbaron: what is the consistency difference?<br>
&lt;myles> q+<br>
&lt;fremy> emilio: Firefox uses floats for everything, but Blink and Webkit use floats only when parsing and simplifying, but inside the math expression in use-value-time, it's float<br>
&lt;TabAtkins> s/use floats only/use doubles only/<br>
&lt;fremy> TabAtkins: In general, I agree that precision should be kept undefined if we can<br>
&lt;fremy> TabAtkins: but TypedOM will allow input any double, so I guess we already have that requirement<br>
&lt;fremy> emilio: not really, right now we store as float inside the cssom, typedom is truncated<br>
&lt;fremy> myles: also, we could also be able to used fixedpoint<br>
&lt;fremy> TabAtkins: but not inside a calc() right?<br>
&lt;fremy> myles: not right now, but I would like to keep the option<br>
&lt;astearns> ack myles<br>
&lt;fremy> myles: also, order of operations would need to be specified for the double-precision to make sense as a requirement<br>
&lt;fremy> myles: and I'd like not to have to do this<br>
&lt;astearns> ack dbaron<br>
&lt;fremy> TabAtkins: based on the concensus in the room, it seems we want to reject this proposal<br>
&lt;fremy> dbaron: note that we had compat issues in serialization as dbl vs floats<br>
&lt;chris> q+ to mention an upcoming float/double serialization issue<br>
&lt;fremy> dbaron: specified values would be in float, but computed values were doubles, and that caused issues<br>
&lt;fremy> dbaron: maybe these compat issues are not relevant in the current discussion, but it's interesting to note that if we do, we have 7 random digits at the end<br>
&lt;fremy> chris: we also will have similar issues with colors<br>
&lt;fremy> TabAtkins: we could specify that we also serialize in float space<br>
&lt;fremy> TabAtkins: but myles also wanted to keep fixedpoint, so maybe not<br>
&lt;chris> because color() lab() lch() all use float<br>
&lt;fremy> TabAtkins: but it's a tangent<br>
&lt;dbaron> (as I was talking through it I think I realized the issues I was remembering were about the problem that once you truncate something from double to float, you should never use double-based serialization code to serialize it because you'll then get 6 digits or so tacked on to the end)<br>
&lt;fremy> TabAtkins: is there any objection to keep precision undefined for math?<br>
&lt;fremy> RossenTheReal: any objection?<br>
&lt;fremy> (no objection)<br>
&lt;chris> ack c<br>
&lt;Zakim> chris, you wanted to mention an upcoming float/double serialization issue<br>
&lt;fremy> RESOLVED: Math precision in CSS is currently kept undefined<br>
&lt;fremy> iank_: (Chrome could also investigate changing the parser to use floats, but it's not high in our priority list)<br>
&lt;fremy> iank_: (right now, it depends on the class where we store it, sometimes a float, sometimes a double)<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4551#issuecomment-577138376 using your GitHub account

Received on Wednesday, 22 January 2020 11:31:33 UTC