[css-values-4] min/max(%, %) should explicitly evaluate against the % value, not the resolved value

[tabatkins]

When looking at an expression like min(10%, 20%), it seems reasonable at first glance to assume that it always resolves to 10%.

In most properties in CSS, %s always resolve against non-negative values, so this does indeed happen whether you're looking at the raw %s or their resolved values.

However, @dbaron points out that in bg-position, if the bg-image is larger than the bg positioning area, a % resolves to a negative value. Thus it matters which stage you're looking at for the min() and max() functions.

What should we do? Note the more complex example of min(10% + 10px, 20% + 5px); you can't make a judgement based purely by looking at the unresolved %s, but after resolution, due to the BG cases, either one could end up the smaller.

[dbaron]

Some of might be fixable by changing how we describe the resolved value of background-position. (The computed value seems fine since it still includes percentages.)

[xiaochengh]

For reference:
Safari (Version 12.1.2 (14607.3.9)) resolves min(%, %) against the resolved value.
See example at http://jsfiddle.net/t9bk6p0q/1/, where min(0%, 100%) is resolved as 100%

I originally raised this issue as I wasn't aware of background-position. As I'm implementing min/max in Blink, I need to make sure that if we support evaluation of % against negative values, the added code paths are reachable.

Now that it's reachable, it's no longer an issue for me.

[Loirooriol]

https://drafts.csswg.org/css-values/#determine-the-type-of-a-calculation says

If, in the context in which the math function containing this calculation is placed, <percentage>s are resolved relative to another type of value (such as in width, where <percentage> is resolved against a <length>), and that other type is not <number>, the type is determined as the other type.
Otherwise, the type is «[ "percent" → 1 ]».

It doesn't seem unreasonable to me that, if the type of the percentage is e.g. «[ "length" → 1 ]», the percentage is resolved as a <length> in order to calculate min/max. But if the type is «[ "percent" → 1 ]», I would just compare the numeric parts of the percentages.

[tabatkins]

Those are equivalent - that's basically "resolve the % before comparing min/max", it's just that in the cases where the value type is a straight-up <percentage>, it's already resolved as far as it needs to be.

[css-meeting-bot]

The CSS Working Group just discussed [css-values-4] min/max(%, %) should explicitly evaluate against the % value, not the resolved value, and agreed to the following:

• RESOLVED: Close no change

The full IRC log of that discussion

<dael> Topic: [css-values-4] min/max(%, %) should explicitly evaluate against the % value, not the resolved value
<dael> github: https://github.com//issues/4227
<dael> TabAtkins: Curious who added this
<dael> astearns: Gerard
<dael> TabAtkins: I think we have this resolved in spec. Let's confirm
<dael> TabAtkins: Question about what to do with compare functions when you have less then obv value like %. min of 50% and 10%. Depending on context 50% could be the smaller when it's a negative value
<bradk> I wish we could also go the other way, and get the accent color for use in other things, such as with ‘env(accent-color)’
<dael> TabAtkins: Extra confusing when you mix % and no-%. You can't figure out until you resolve to lengths.
<dael> TabAtkins: Want to make sure everyone is cool with spec rules that you resolve as much as you can at each step but % can't be resolved at computed value time unless they are a terminal type for the property. If lengths have to wait.
<bradk> OK. Sorry, I came in late
<dael> TabAtkins: If that's okay, great. I don't think we need a resolution unless ou think we should.
<dael> astearns: I suspect Gerard would like a resolution so he can finish tests
<dael> astearns: Any concerns with the spec text?
<leaverou> florian bradk astearns: I filed the issue: https://github.com//issues/5900
<dael> astearns: Prop: Close no change
<dael> RESOLVED: Close no change

[dholbert]

Quoting this earlier comment that had a jsfiddle testcase:

For reference:
Safari (Version 12.1.2 (14607.3.9)) resolves min(%, %) against the resolved value.
See example at http://jsfiddle.net/t9bk6p0q/1/, where min(0%, 100%) is resolved as 100%

It looks like this is what happens in Chrome as well (the min expression is resolved as 100% here).
In comparison, in Firefox it seems to be resolved as 0% (at least, the rendering stays the same if I replace the min() expression with 0%.

Am I correct in understanding that we've resolved on the behavior that Firefox happens to already have here? (and Chrome/Safari's implementations need to be adjusted so that the jsfiddle resolves the min expression to 0% rather than 100%?)

[Loirooriol]

@dholbert I understood the opposite, instead of picking 0% just because 0 < 100, the resolution was to wait until we can resolve percentages as lengths, 0% = 0px and 100% = -8px in this case, and then pick the smaller length, so 100%.

[tabatkins]

Yes, Oriol is correct. %s cannot (in general) be correctly resolved at computed-value time, so we're sticking with the current spec text that doesn't let them simplify at all (until they're later replaced by a px value or whatever)

[tabatkins]

Notably, if min(0%, 100%) and min(0% + 1px, 100% + 1px) resolved differently, something is very wrong.

[dholbert]

Gotcha - thanks. (And yeah, the +1px scenario is compelling.)