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

[emilio]

In the CSS values spec, section 8.1.4. Range Checking:

However, the used value resulting from an expression must be clamped to the range allowed in the target context.

Note that the used value is expected to be clamped, but not the computed value. Both Blink and Firefox (at least, probably other engines too) clamp the value at computed value time, as can be seen running the following test, where all the properties that don't accept negative lengths (like font-size, padding-xxx, etc.) report a computed value of 0px instead of the expected -1px.

">

>
<script>
window.onload = function() {
  let style = window.getComputedStyle(document.body);
  for (prop of style) {
    if (prop in document.body.style) {
      document.body.style[prop] = 'calc(-1px)';
      console.log(prop, "reported: ", getComputedStyle(document.body)[prop]);
    }
  }
}
script>

[emilio]

cc @SimonSapin

[emilio]

For the record, Firefox does follow the spec correctly, but clamps the value in GetComputedStyle. I guess that's more of another kind of issue.

[dbaron]

For properties where the computed value is a length (i.e., calc()s are computed at computed value time) like font-size, we clamp to nonnegative values at computed value time. For properties where the calc() expression is part of the computed value space (like padding-left) we have clamping at used value time (both in the GetComputedStyle code and in the code that actually uses the value).

I think the spec is still wrong for properties that accept calc() but where calc() is not part of the computed value space since it can be fully computed by computed value time (e.g., font-size).

[emilio]

Yeah, and WebKit (and Blink) also clamp (edit: lengths, of course) at computed value time, see https://github.com/WebKit/webkit/blob/e999a05729f1c284fd6e734b88e81a2b078ed80f/Source/WebCore/css/CSSCalculationValue.cpp#L195

[tabatkins]

Note that getComputedStyle() returns the used value for a number of length-using properties, so that pollutes the data quite a bit here. WebKit/Blink doesn't actually have a separate notion of "computed value" in the engine.

[css-meeting-bot]

The CSS Working Group just discussed CSS Values and Units: clamping calc().

The full IRC log of that discussion

Topic: CSS Values and Units: clamping calc()
github topic: https://github.com//issues/434
fantasai: this question was about when things get clamped, if you have a property which doesn't accept negative lengths, for example, the spec says that the used value is clamped, but the computed value is not clamped, and there is some disagreement about whether that is waht is implemented
fantasai: dbaron says that calc() is computed at computed value liek font size
dbaron's comment:
For properties where the computed value is a length (i.e., calc()s are computed at computed value time) like font-size, we clamp to nonnegative values at computed value time. For properties where the calc() expression is part of the computed value space (like padding-left) we have clamping at used value time (both in the GetComputedStyle code and in the code that actually uses the value).
I think the spec is still wrong for properties that accept calc() but where calc() is not part of the computed value space since it can be fully computed by computed value time (e.g., font-size).
https://github.com//issues/434#issuecomment-243933445
Rossen: to further TabAtkins's latest point, some or most of this is referring to getComputedStyle() which returns used values not computed values
Rossen: it seems like WebKit and blink don't have a separate notion of computed values, and this is a transient value for them
dbaron: there is some value which gets inherited. If you have "25% - 30px" and you say this is the computed value and it gets inherited to something which clamps differently, it should be clamped differently
Rossen: but you don't know that 25% gets resolved to something > 25px
fantasai: but you do know this for some properties
fantasai: for padding-left you don't know this, but font-size, you do know this
fantasai: you can resolve this at computed value time, and you need to because the value at font-size needs to be computed to a length in order to resolve em
Rossen: font-size is the only property which resolves percentages outside of layout
fantasai: dbaron: no
Rossen: ....
Rossen: ok.
fantasai: dbaron, do you have a proposal?
dbaron: not off the top of my head
dbaron: i could write one
fantasai: yes please
dbaron: we need a distinction where calc() is resolved at computed value time and where calc() is part of a computed value. these needs separate rules
fantasai: ok.
fantasai: in the first case, we would do the clamping at computed value time, and the second case, it would be at used value time
dbaron: yes
Rossen: how is this observable?
dbaron: the difference is observable through inheritance. but also, some fo the combinations of ways of specifying it, it doesn't make any sense
fantasai: let's resolve
Rossen: we need a proposal
fantasai: i can write a proposal
fantasai: w/ dbaron's review
Rossen: let's see the prose before we resolve
fantasai: sounds good

[tabatkins]

Current text is:

Parse-time range-checking of values is not performed within ''calc()'',
and therefore out-of-range values do not cause the declaration to become invalid.
However, the used value resulting from an expression
must be clamped to the range allowed in the target context.

I propose we change this to:

Parse-time range-checking of value is not performed within ''calc()'',
and therefore out-of-range values do not cause the declaration to become invalid.
However, at the point in the value computation process where the ''calc()'' can be resolved to a single term,
it must be clamped to the ranged allowed in the target context.
(For example, 'font-size' can resolve ''calc(10% - 1em)'' to a single term at computed-value time
(to -.9em, as it turns out),
which will then clamp to ''calc(0)''.
''width: calc(10% - 1em)'', on the other hand,
can't resolve into a single term until used-value time.)

[fantasai]

Okay, so there are two interpretations of what dbaron said:

• That clamping happens at each stage (computed and used), if it is possible at that stage.
• That clamping happens at the stage in which it's guaranteed to be possible.

For example, font-size can compute all of its values at computed value time (and indeed, must do so in order for ems to be able to compute elsewhere). It would clamp at computed value time; and clamping at used value time is unnecessary.

width however depends on layout information to resolve percentages, and therefore it cannot clamp values that mix percentages and lengths at computed value time. Therefore two behaviors are possible:

• width clamps calc() expressions that do not mix lengths and percentages at computed value time, and clamps calc() expressions that do mix them at used value time
• width only clamps calc() expressions at used value time.

The latter seems slightly simpler, but since it means that a property only clamps exactly one time, a property that currently only has computed-value units and then later adds used-value units would change behavior in an author-observable way.

The wording for each of these options would be different, so we need the WG to resolve on which one.

[css-meeting-bot]

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

The full IRC log of that discussion

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

[astearns]

Need to see more testing results before this goes on the agenda again.

[astearns]

I've written these tests that check whether an animated negative calc value is clamped at computed value time (and thus a range of negative values aren't present in the animation) or used value time (where a range of negative values will be present in clamped form for a duration in the animation)

astearns/web-platform-tests@da5892f

The results I'm seeing are all over the place. Pass means clamping is happening at used value time (mostly). Fail means it's clamping at computed value time.

width and padding-left have the same results

width-up
FF, Chrome: pass (used-time)
Safari: fail (computed-time)
Edge: no animation

width-down
FF: pass (used-time)
Safari, Chrome: fail (computed-time)
Edge: no animation

opacity-up
Chrome, Edge: pass (used-time)
(though the Chrome animation appears to be incorrect)
Safari, FF: fail (computed-time)

opacity-down
Chrome, Safari, FF, Edge: fail (computed-time)

font-size up
Chrome: pass (used-time)
FF, Safari: fail (computed-time)
Edge: loading problem page (though the animation seems to fail)

font-size down
Chrome, FF, Safari: fail (computed-time)
Edge: no animation

[birtles]

Alan, which version of FF did you test? The results may not differ but our animation code has changed significantly from version 57 onwards.

[astearns]

I'm on Mac nightly, so 58-ish? - I'll edit in the exact version number when I get back to the office tomorrow

[birtles]

That's recent enough--thank you!

[dbaron]

It may also be worth testing Firefox 56, though, since that's the code currently shipping.

[dbaron]

FWIW, I'd note that the Firefox results make sense to me: the properties where calc() can be handled at computed value time "fail", and the properties where it needs to be deferred to used value time "pass".

[fantasai]

Agenda+ because we have test results (above) and a proposal (#434 (comment)) and this is blocking CR update of Values and Units for months now so it would be really nice to resolve and republish.

[tabatkins]

@dbaron That has the forward-compatibility problems noted by @fantasai in #434 (comment) - if a property initially accepts only computed-value-time units, it would be clamped at computed-value time, but if it later starts accepting used-value-time units, we'd have to move it to clamping at used-value time, which is observably different.

Thus the proposal to clamp at both spots - computed value clamping if possible, used-value clamping otherwise. That way a width: calc(-50px) would clamp "early", at computed-value time, but a width: calc(10px - 10%) would clamp "late", at used-value time.

[css-meeting-bot]

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

The full IRC log of that discussion

Topic: [css-values] Computed value of a negative calc unit that doesn't allow negative lengths
github: https://github.com//issues/434
astearns: I added some tests with idea we would want to be picking either use or computed time. Sound proposal is to clamp as soon as possible. Correct?
present +
fantasai: Not quite. To clamp them both...twice effectively.
fantasai: Some values you can calc through at the beginning and others you can't.
Summary of the issue / proposal : https://github.com//issues/434#issuecomment-310183908
dbaron: I think what I suggested is that when the value...when all values of prop can be computed through at computed value you clamp t computed value time. If not you clamp at used value time
TabAtkins: That is what we're saying
fantasai: No it's not.
fantasai: There's two proposals. One is you clamp at each stage if it's possible at thtat stage for values under consideration at that moment.
TabAtkins: The answer is the forward compat one. A prop is used value clamping if any property needs used value time to tell. It will have an observable effect if we later add an item that is used to a clamp. The clamp as early as you can has no observable effect when we add new things to value space.
florian: So is there an argument against that?
s/at that moment/; other is you clamp when it's guaranteed to be possible for that property in general./
astearns: My question is since clamping at used value appears to be slightly useful for animmations could we only clamp at used value time?
TabAtkins: That might be possible
fantasai: I'ts not because font size prop needs to compute through to ems can be computed.
TabAtkins: Is that true though...
??: I think so
TabAtkins: What's wrong with ems computing to a calc.
fantasai: ems are a length, they resolve to px
TabAtkins: THat's current. What's wrong with the other way around.
TabAtkins: It eentually falls through to layout. Only differencec is what things you can observe at computed value time.
fantasai: It means you'll carry a calc around that's 50px+100%+2em you have to carry that and insert it into a margin that's a descendant of a descenent .... are you crazy?
TabAtkins: Yeah, that would be the technical consiquencce. Every situation here is bad.
dbaron: That's bad for impl complexity and performance if you say you can never simplify.
s/..../but still have it resolve on the parent on the original element on which it was declared/
TabAtkins: Sure.
florian: What's wrong with clamp as soon as you can. It sounded good to me. It's fine with animations.
TabAtkins: Someone advocating for that would have to argue for it because I don't know.
"as soon as you can..."
astearns: I'm still unclear.
TabAtkins: florian means what we're suggesting.
florian: As soon as you can based on alues, not based on which property it's in
A) Clamp as early as possible based on values.
dbaron: % will behave differently depending on how they behave for prop
B) Clamps as early as possible based on the property.
TabAtkins: We're saying as early in the context of a property. Since in the property you can tell if you can know at computed and clamp them or you wait until used.
dbaron: Are there cases...where we distinguish between calc 10% and 10% doing something different.
TabAtkins: I don't think so. In position % don't resolve to a simple pixel value, but still a bare % goes to same in or out of call
fantasai: If it's negative. We throw those out at parse time
dbaron: If we want to throw out neg it also makes sense to simplify away the calc.
dbaron: If you're at a point where you can fix the negative you should comput calc to a single value
TabAtkins: That's against our general consesus to maintain calc structures somewhat so that authors get to look at a regular thing. I've argued against that, but that was what the group wanted.
florian: [missed]
s/[missed]/editor concerns/
dbaron: I don'ts ee how you maintain a calc structure while clamping. If you have 50px+2em and you know an em is large, do you change the em or do you turn it into 0px?
a/[missed]/channelling glazou: when possible, keeping what the author wrote helps with authoring tools/
TabAtkins: For animation it's 0px
dbaron: But we're talking what the computed value is
TabAtkins: Well, what the animated value is. It's mostly the cocmputed, but sometimes diverges.
TabAtkins: Big obserable thing is in your animated behavior
dbaron: I guess...you could compute it to calc 0px rather then 0px. But it seems weird to deal with clamping but not simply expressions.
astearns: Seemes weird to me to have a clamp happen but then give the non-clamped expression and the person using it doens't know if it's eval as expression or clamped value.
TabAtkins: I don't have a strong opition but people have obj to removing calc before.
fantasai: Removing calc should be a sep/ issue
dbaron: It would also be useful to have links to the other decisions.
TabAtkins: I recall glazou being a proponent of maintaining calc
astearns: fantasai in IRC had 2 comments [reads]
astearns: My understanding is we're going with option A
astearns: Is that correct?
florian: Yes, I think so
astearns: What if we resolve on option A: Clamp as early as possible based on values. and I'll open a new issue as to what to do with calc when they're clamped
dbaron: I'm uncomfortable agreeing to clampa t a time when we're not agreeing to simplify calc at the same time
florian: Would you obj to not simplifying or is there another option
TabAtkins: I'm fine with simplifying. There were arguements against it before.
dbaron: I think we should table and go back to look at those arguments.
astearns: I'll add a comment that we need to look at why we had been decising to preserve calcs. This being a new situation where we're clamping the value I suspect the previous arguments about preserving calc-ness will go out the window.
florian: astearns when you make that it's good to mention glazou.
astearns: I will tag him on it.
TabAtkins: This is the only thing blocking CR and V&U is quite out of date. Can we do a new CR with this unfinished and get it up to date?
astearns: How many other changes are in the changes section?
https://drafts.csswg.org/css-values-3/issues-cr-2016
TabAtkins: I'll look. A decent amount. A number of new units
astearns: And we're in CR?
fantasai: The new units are in 4.
TabAtkins: Let me linkt he changes.
astearns: Given we're in CR I don't htink we can ask for updated before we republish.
TabAtkins: Then let's close it no change and re-open it because this is preventing us from publishing.
fantasai: I think we can ask for republish and explain this is a minor issue and still open and we'll deal with it.
astearns: Republishing and knowing we have to do it again is also dumb. I'd rahter wait.
florian: Does spec have the thing we're likely to resolve to?
TabAtkins: let me look
TabAtkins: Current spec says always clamped at used value which is the thing we agreed to not do
[laughs]
florian: So resolve unless glazou objects?
s/the thing/the one thing/
astearns: I don't want to rush this through.
astearns: I'm sorry.
TabAtkins: I'm jsut frustrated that we cna't publish because proccess. I'd rather publish and publish again in a montht hen have a month of buggy TR draft.
astearns: I agree on regular WD but CRs are extra work.

[astearns]

In the discussion above we talked about (but did not resolve) on what happens to calc() expressions when the value is clamped. I believe there was consensus on the call to simplify the calc() expression in that case, as the clamping changes the value significantly from what the expression might appear to be.

We've had discussions in the past about preserving calc() expressions for tooling. It might be weird to have a "calc(50px)" value maintain the expression for a computed value, but a "calc(-50px)" value get simplified to "0px" upon clamping at computed value time. But it might be useful to represent the clamping in this edge case. Do you have an opinion, @therealglazou?

[therealglazou]

I am fine with the resolution from confcall 20171213.

[css-meeting-bot]

The Working Group just discussed [css-values] Computed value of a negative calc unit that doesn't allow negative lengths., and agreed to the following resolutions:

• RESOLVED: resolve to clamp negative calc unit values in context as early as possible and then return the clamped calc as a result of the computed style.
• RESOLVED: resolve to clamp negative calc unit values in context and simplify as early as possible and then return the clamped calc as a result of the computed style.

The full IRC log of that discussion

Topic: [css-values] Computed value of a negative calc unit that doesn't allow negative lengths.
github: https://github.com//issues/434
Rossen_: This was intro last week. We resolved to clamp as early as possible, but not how to return computed values based on thsi clamping. We wanted to hear about it from a few people, one of them was glazou.
Rossen_: That's the first topic.
Rossen_: Is TabAtkins or fantasai on>
fantasai: I'm on, but no computer.
TabAtkins: glazou didn't respond and I haven't had time to go through and dig up previous issues. I'm fine resolving now and waiting for compalints later if there are any.
Rossen_: Let me get us on the resolve. Previously we said clamp negative clamp as soon as possible.
plinss: We didn't actually resolve.
s/plinss/astearns/
Rossen_: Ah, thank you. So we didn't resolve. But there was consensus on clamping as early as possible, right?
TabAtkins: I believe so.
Rossen_: Proposal is negative calc units are clampped as early as possible
??: per value or per prop?
Rossen_: I believe per value
s/??/fantasai/
fantasai: That was key question, per property or per value
Rossen_: I assumed it was per value and if it was given to the property it inherits
astearns: Yes, it was def. per value.
TabAtkins: mmhmm
Rossen_: right
Rossen_: So the consensus was to try and clamp those as early as possible. There was not consensus on how to return computed values. As calc with negative value inside or return the clampped value.
Rossen_: So we could resolve on clamping and leave serialization out. TabAtkins or fantasai preference?
TabAtkins: Tha'ts fine with me. The q was if you have a calc that's 50px-2em and that's negative at calc time do we simplify to calc0px rather then keepign the original. I'm fine simplifying the internal of the calc to the clampped value. I think that's what dbaron wanted.
dbaron: I think clamping and simplificiation should go together. If we're clamp we should also simplify.
TabAtkins: That happens already, we collapse units together. But if we have units that we know will be clampped is the topic.
dbaron: When you can resolve between px and em and know it's negative I think you also simplify to px.
TabAtkins: I'm fine with that.
Rossen_: And the serialized value is whatever the clampped value?
TabAtkins: With a calc around it.
Rossen_: Other opinions?
Rossen_: Objections on resolving to clamp negative calc unit values in context as early as possible and then return the clampped calc as a resolut of the computed style.
RESOLVED: resolve to clamp negative calc unit values in context as early as possible and then return the clamped calc as a result of the computed style.
dbaron: We're saying clamp and simplify.
TabAtkins: Some simplification is specced. This is collapse all units together that can be figured out. So we'd collapse em with px etc.
fantasai: You have to do that for inheritence to work.
TabAtkins: Yeah.
Right now we already simplify calc(1px + 2px). Reoslution is to also simplify calc(1px + 1in) at computed/used value, and things like calc(1px + 1em) at the point where that's possible.
RESOLVED: resolve to clamp negative calc unit values in context and simplify as early as possible and then return the clamped calc as a result of the computed style.

[fantasai]

Ok, I've checked in the following changes:

However, the used value resulting from an expression must be clamped to the range allowed in the target context. Clamping is performed on computed values to the extent possible, and also on used values if computation was unable to sufficiently simplify the expression to allow range-checking.

@emilio @tabatkins Can you let me know if that seems adequate?

[tabatkins]

👍

[emilio]

Looks good to me, thanks! Maybe noting explicitly that clamping should not be done at specified value time is worth it? WebKit / Blink are buggy here wrt numbers / integers IIRC.

Haven't checked if it's something mentioned in other places of the spec.

[fantasai]

@emilio OK, added parenthetical about specified values.

Clamping is performed on computed values to the extent possible, and also on used values if computation was unable to sufficiently simplify the expression to allow range-checking. (Clamping is not performed on specified values.)

[fantasai]

Closing out per @emilio’s verification over IRC.