Re: [csswg-drafts] [css-values] Computed value of a negative calc unit that doesn't allow negative lengths.

The CSS Working Group just discussed `[css-values] Computed value of a negative calc unit that doesn't allow negative lengths.`.

<details><summary>The full IRC log of that discussion</summary>
&lt;astearns> topic: [css-values] Computed value of a negative calc unit that doesn't allow negative lengths.<br>
&lt;astearns> github topic: https://github.com/w3c/csswg-drafts/issues/434#issuecomment-310183908<br>
&lt;fantasai> TabAtkins: Spec text previously said that you can put negative numbers into calc(), it's fine, because we can't in general tell if it's negative or not<br>
&lt;fantasai> TabAtkins: we do a clamping at some point if it needs to clamp to a particular range<br>
&lt;fantasai> TabAtkins: Spec previously said that clamping happens at computed value time, but you can't always tell, e.g. width has to happen at used value time<br>
&lt;fantasai> (and font-size has to happen at computed value time)<br>
&lt;fantasai> TabAtkins: fantasai and I discussed and realized there are two possible interpretations of this conclusion<br>
&lt;fantasai> TabAtkins: for properties that clamp at computed value time<br>
&lt;fantasai> TabAtkins: can clamp through at computed value time<br>
&lt;fantasai> TabAtkins: For properties that clamp at used value time, some things can clamp at computed value time<br>
&lt;fantasai> TabAtkins: So do those properties clamp both at used and computed value time, or just at used value time?<br>
&lt;fantasai> Florian: So for multi-stage examples if you can't clamp, you keep a calc() expression, right?<br>
&lt;fantasai> TabAtkins: If you're width is calc(5px-5%) it'll stay as that at computed value, clamps at used value<br>
&lt;birtles> I think we want to clamp as late as possible -- since animation operates on computed values (more or less)<br>
&lt;fantasai> Florian: But if you clamp at calc(5px-5em) can clamp at computed value<br>
&lt;fantasai> TabAtkins: If we clamp only at used value time, we need a definition of which property is which kind of computation<br>
&lt;fantasai> TabAtkins: And then, if we ever add a unit that does used value time computation to a property that currently clamps at computed value time, it would change behavior<br>
&lt;fantasai> TabAtkins: So I prefer clamp at all times behavior<br>
&lt;fantasai> dbaron: I was going to say I prefer the other one<br>
&lt;fantasai> dbaron: birtles said same thing on IRC, but was thinking about animations<br>
&lt;fantasai> dbaron: I was thinking essentially of things like width: calc(-5px) vs width: (0%-5px) vs width: (0-5px) vs width: (10%-5px)<br>
&lt;fantasai> TabAtkins: You can't add 0% to 1s, so while we technically can resolve zero immediately, we would treat it like any other percentage<br>
&lt;fantasai> dbaron: Still worth thinking about animations<br>
&lt;dbaron> s/vs width: (0-5px) //<br>
&lt;fantasai> Florian: If we go that way, pretty important to go the way Tab says for 0%, otherwise discontinuity between 0% and 0.00001%<br>
&lt;birtles> specifically my concern is you want to interpolate using the unclamped values and then clamp<br>
&lt;fantasai> TabAtkins: Don't understand animations issue<br>
&lt;fantasai> TabAtkins: font-size resolves everything at computed time already<br>
&lt;fantasai> TabAtkins: So animations should see value of 0 for 0px, don't see why width should be different<br>
&lt;fantasai> dbaron: You can have a calc() that's a result of interpolation<br>
&lt;fantasai> dbaron: If one of the end points does different things than the intervening value..<br>
&lt;fantasai> TabAtkins: If the values are different, then the middle value will always be a valid value anyway<br>
&lt;fantasai> ... bouncing ...<br>
&lt;fantasai> TabAtkins: If it's a used value time unit involved, then it'll always stay as a calc()<br>
&lt;dbaron> (bouncing meaning timing functions that go outside 0-1)<br>
&lt;fantasai> Florian: None of these allow us to have results earlier, to get fully resolved value at computed value time ..?<br>
&lt;birtles> e.g. if you support calc() for opacity and interpolate between calc(-1) to calc(3) you'll get different results if you clamp the endpoints before interpolating<br>
&lt;fantasai> TabAtkins: Just feels nasty and weird if font-size can clamp its values at computed value time, but width can't even if it uses the exact same value<br>
&lt;fantasai> TabAtkins: And also, as I said before, if we add a used-value time unit to a computed-value-time-only property, it would change behavior<br>
&lt;fantasai> TabAtkins: observable in animations as well as OM<br>
&lt;fantasai> TabAtkins: If we say that a property only has computed value time units, then it can never gain a used-value time unit<br>
&lt;fantasai> Florian: Why?<br>
&lt;fantasai> TabAtkins: Because it will change from clamping at computed value time to clamping at used value time, seeing raw calc() value in the animation<br>
&lt;fantasai> TabAtkins: Difference is e.g. animated from -1000px to 1000px, would stay at 0 for first half if doing used value time, and would animate from 0 to 1000px over full range if doing computed value clamping<br>
&lt;fantasai> dbaron: What do implementations currently do?<br>
&lt;fantasai> TabAtkins writes some tests<br>
&lt;fantasai> TabAtkins: Looks like in Chrome at least, appears to delay width clamping to used value time right now<br>
&lt;TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5256<br>
&lt;fantasai> TabAtkins: Spends half of the animation sitting at zero<br>
&lt;fantasai> TabAtkins: wait, this is inconsistent<br>
&lt;TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5257<br>
&lt;fantasai> ?: Does the other behavior. never sticks at zero.<br>
&lt;fantasai> TabAtkins: Sounds like no interop<br>
&lt;gsnedders> s/?/Myles:/<br>
&lt;RachelNabors> BAHAHAHAHA... Tab.<br>
&lt;myles> s/?: Does/Myles: Safari does/<br>
&lt;fantasai> astearns: Think we should kick this back to github for testing, come back with animation data<br>
&lt;fantasai> astearns: Anything else to bring up on this topic?<br>
</details>


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

Received on Wednesday, 5 July 2017 23:44:50 UTC