Repository navigation
[css-values] Computed value of a negative calc unit that doesn't allow negative lengths. #434
Description
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.
<!doctype html>
<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>
Activity
emilio commentedon Aug 30, 2016
cc @SimonSapin
emilio commentedon Aug 31, 2016
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 commentedon Aug 31, 2016
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 (likepadding-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 commentedon Aug 31, 2016
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
[-][css-values] Computed value of a negative calc unit in that doesn't allow negative lengths.[/-][+][css-values] Computed value of a negative calc unit that doesn't allow negative lengths.[/+]tabatkins commentedon Mar 31, 2017
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 commentedon May 24, 2017
The CSS Working Group just discussed
CSS Values and Units: clamping calc().The full IRC log of that discussion
<fantasai> Topic: CSS Values and Units: clamping calc()<fantasai> github topic: https://github.com//issues/434
<myles> 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
<myles> fantasai: dbaron says that calc() is computed at computed value liek font size
<fantasai> dbaron's comment:
<fantasai> 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).
<fantasai> 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).
<fantasai> https://github.com//issues/434#issuecomment-243933445
<myles> Rossen: to further TabAtkins's latest point, some or most of this is referring to getComputedStyle() which returns used values not computed values
<myles> Rossen: it seems like WebKit and blink don't have a separate notion of computed values, and this is a transient value for them
<myles> 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
<myles> Rossen: but you don't know that 25% gets resolved to something > 25px
<myles> fantasai: but you do know this for some properties
<myles> fantasai: for padding-left you don't know this, but font-size, you do know this
<myles> 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
<myles> Rossen: font-size is the only property which resolves percentages outside of layout
<myles> fantasai: dbaron: no
<myles> Rossen: ....
<myles> Rossen: ok.
<myles> fantasai: dbaron, do you have a proposal?
<myles> dbaron: not off the top of my head
<myles> dbaron: i could write one
<myles> fantasai: yes please
<myles> 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
<myles> fantasai: ok.
<myles> 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
<myles> dbaron: yes
<myles> Rossen: how is this observable?
<myles> dbaron: the difference is observable through inheritance. but also, some fo the combinations of ways of specifying it, it doesn't make any sense
<myles> fantasai: let's resolve
<myles> Rossen: we need a proposal
<myles> fantasai: i can write a proposal
<myles> fantasai: w/ dbaron's review
<myles> Rossen: let's see the prose before we resolve
<myles> fantasai: sounds good
tabatkins commentedon Jun 9, 2017
Current text is:
I propose we change this to:
fantasai commentedon Jun 21, 2017
Okay, so there are two interpretations of what dbaron said:
For example,
font-sizecan 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.widthhowever 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:widthclamps calc() expressions that do not mix lengths and percentages at computed value time, and clamps calc() expressions that do mix them at used value timewidthonly 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.
19 remaining items
[css-values] Clamp calc() values at both computed and used value time…
fantasai commentedon Feb 3, 2018
Ok, I've checked in the following changes:
@emilio @tabatkins Can you let me know if that seems adequate?
tabatkins commentedon Feb 9, 2018
👍
emilio commentedon Feb 10, 2018
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 commentedon Feb 10, 2018
@emilio OK, added parenthetical about specified values.
fantasai commentedon Feb 10, 2018
Closing out per @emilio’s verification over IRC.
[css-values-3] Clarify that clamping is not performed on specified va…