Re: [csswg-drafts] [css-values] Allow division of same types in calc()

The Working Group just discussed `Allow division of same types in calc()      should calc(1 / calc(1/(-1/0))) produce positive infinity or negative infinity?`, and agreed to the following:

* `RESOLVED: Allow calc to handle negative 0s`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: Allow division of same types in calc()      should calc(1 / calc(1/(-1/0))) produce positive infinity or negative infinity?<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/545#issuecomment-394474713<br>
&lt;dael> TabAtkins: In the corse of proting typed OM into calc, typed OM depends on float semantics but in calc CSS values don't theoretically have a float semantic bound. I have to define certain cases. Division by 0 produses postiive or negative infinity and it's clamped. I followed ieee semantics. ieee754 semantics track positive and negative. Css doesn't normally care about it.<br>
&lt;dael> TabAtkins: Depending on what you're doing you can construct something that resolves to postive or negative infinity. So far for simplicity I've ommited them but it's not hard to add them back in. I suspect we would want that because it's simpler for typed OM and calc to match in these cases. Wanted to verify<br>
&lt;TabAtkins> calc(1 / calc(1/(-1/0)))<br>
&lt;dael> TabAtkins: In issue I have an example ^<br>
&lt;dael> TabAtkins: Resolves differently. It double inverts a negative inifity and will be positive or negative depending on if a negative 0 escapes the inner calc.<br>
&lt;dael> TabAtkins: I propose we track 0 signedness to be consistant with general float semantics.<br>
&lt;dael> fremy: No objections. Still wondering why track inifity. We can say it's not a number so it doesn't matter.<br>
&lt;dael> TabAtkins: If you're approaching a 0 in the denominator of something you don't want to suddenly flip. The infinities have to be something. If they're all positive if something is approaching inifnity it'll flip to positive and go from really big to really small.<br>
&lt;dael> TabAtkins: Typed OM is just math over JS numbers and they have infinities.<br>
&lt;dael> TabAtkins: We could expose extra semantics but it doesn't buy us anything.<br>
&lt;dael> fremy: If you animate the denominator from -1 to 0 when you get to 0 it's positive. There isnt' a browser supporting it so it's not a huge use case.<br>
&lt;dael> TabAtkins: I know it's a new feature. There's no compat to worry about.<br>
&lt;dael> TabAtkins: If all infinities go 0 and you have -1/-1 and then bottom goes to 0 -1/0 should be negative.<br>
&lt;dael> fremy: -1/-1 is positive.<br>
&lt;dael> TabAtkins: Sorry, meant the other way.<br>
&lt;dael> fremy: -1/-1 goes to a positive 0. But okay, it's fine. I'm fine with whatever you want.<br>
&lt;dael> TabAtkins: I'm not making up semantics. I'm saying follow ieee as close as possible.<br>
&lt;TabAtkins> \/kick NegativeInfinity<br>
&lt;dael> AmeliaBR: I agree with TabAtkins that it makes sense to be consistent with standard computer math that's already in JS. Also important b/c CSS we are animmting values and once we're allowing people to divide different lengths like font size/viewport width and animate to 0 this could come up. Continuous animations until something turns infinite makes sense.<br>
&lt;dael> astearns: Other impl opinions?<br>
&lt;dael> astearns: dbaron do you have an opinion?<br>
&lt;dael> dbaron: No strong opinion<br>
&lt;dael> astearns: Other opinions?<br>
&lt;dael> astearns: I'm hearing people call for dealing with negative 0. No opinions against.<br>
&lt;dael> astearns: Objections to allowing calc to handle negative 0s?<br>
&lt;dael> RESOLVED: Allow calc to handle negative 0s<br>
</details>


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

Received on Wednesday, 6 June 2018 23:30:48 UTC