[css-grid-2] Allow minmax where max wins over min

[fantasai]

https://lists.w3.org/Archives/Public/www-style/2016Oct/0076.html

Minmax would be far more useful if the max was always respected. Using grid to have a max-width content area but a full-width background is actually really hard without this feature. For a current use case I need to use

grid-template-columns: 1fr repeat(4, minmax(20%, 250px)) 1fr;

Being able to use viewport units and percentage units as a minimum value while specifying a pixel maximum would make so much sense. Otherwise I'll have to make do with using a pixel minimum, which will means my fr margins will take up no space at smaller viewports, so i'll have to add tedious media queries.
I realize i can set a percentage value and a max-width on the content itself and then set grid-template-columns to 1fr repeat(4, auto) 1fr but this is far from ideal.

I've been trying a lot of different ways to achieve the same layout. Please consider changing this.

This is a perfectly reasonable use case, but since min wins over max in CSS in general, we weren't able to solve it by inverting the priority (see response on www-style). So we need some other, syntactically-different, solution. Suggestions welcome.

[smartcorestudio]

maxmin ?
grid-template-columns: 1fr repeat(4, maxmin(250px, 20%)) 1fr;

[yisibl]

between()?

[Dan503]

I like the idea of maxmin(). It's clear that it is essentially the same functionality as minmax() but the syntax itself suggests that it has different priorities :)

It would have to be max value first, min value second to make sense though.

[FremyCompany]

If I understood this correctly, the feedback is that sizing properties allows both width: 20%; max-width: 250px and min-width: 20%; max-width: 250px, but that grid only allows the latter with minmax. Is that correct?

If that's correct I'd say prefmax(20%, 250px) but I think the notion of preferred width has been retired in specs, and I can't remember what is the new name for this.

[anjia]

How about adding a new parameter? Just like minmax(min-value, max-value, more-prior-item)
The third param more-prior-item specifies which one has the priority.

eg. minmax(20%, 250px, 'min') is equal to minmax(20%, 250px)
eg. minmax(20%, 250px, 'max') makes max wins over min, which could solve the maxwidth situation.

---

Otherwise I'll have to make do with using a pixel minimum,
which will means my fr margins will take up no space at smaller viewports,
so i'll have to add tedious media queries.

I think, no space at smaller viewports, it's an independent situation from minmax().
Maybe it should be solved by grid layout, adding rules to limit the minwidth of the remaining space or something like that?

[css-meeting-bot]

The Working Group just discussed Allow minmax where max wins over min, and agreed to the following:

• RESOLVED: add a feature that allows max to win over min in Grid L2, name tbd

The full IRC log of that discussion

<dael> Topic: Allow minmax where max wins over min
<dael> github: https://github.com//issues/1102
<dael> TabAtkins: Someone brought a use case where they want to set up columns that are like 20% of the grid but no larger then 250px. Obvious way doesn't work the way thtey want because min wins over max. If viewport is large the min will win and it'll be >250. They want priority to min.
<Rossen_> what if we call it maxmin
<dael> TabAtkins: Seems reasonable. We chose min win over match because it matches CSS> Reasonable to want different order. Suggestion is to add some way to achieve that in grid L2.
<Rossen_> meaning max wins vs minmax where min wins?
<dael> TabAtkins: We can decide on the functionality addition and not the syntax. It's a minor change to layout algo. THere will need to be a check to say if it's this type of sizing you cna't go above this value.
<dael> Rossen_: Support adding. Did we resolve on using maxmin?
<dael> TabAtkins: I don't want maxmin because it suggests max comes first in argument. We can figure syntax out later. fantasai and I will recommend something.
<dael> Rossen_: The feature request makes sense.
<dael> Rossen_: Opinions? Reasons not to put this in grid l2?
<dael> Rossen_: Objections to adding a feature that allows max to win over min in Grid L2?
<dael> RESOLVED: add a feature that allows max to win over min in Grid L2, name tbd

[tabatkins]

So my preference is to go with an optional trailing keyword dictating the behavior. clamp() (#2519) probably wants the same thing, and a keyword is definitely the way to go there (particularly since clamp() also wants a third behavior - swapping the min/max when they're in the wrong order; you can't do that with Grid tho, if either of the sizes are content-based).

So maybe something like:

minmax(<min>, <max>, [min-wins | max-wins]?)

Alternate name pairs: prefer-min | prefer-max

[fantasai]

I prefer the first set [min-wins | max-wins], way more straightforward.

[tomhodgins]

I like the keyword idea too, could it be just min or max as keywords?

[tabatkins]

It doesn't seem immediately clear what min-max(20%, 250px, max) means. The *-wins keywords are suggestive - "win" implies it affects how some conflict is resolved, and the only time there can be a conflict is if the min and max are misordered.

[FremyCompany]

I'm fine with the proposal, I'd just note that for non-grid things, we have [min-width, width, max-width].

Adding a min-wins keyboard that toggles the first argument of minmax between min-width and width is nice, but it means you still can't represent a scenario where you want all three of them (min-width, width and max-width).

My preference would be a three-argument minmax where the first argument would be the min-width equivalent, the second the width equivalent, and the third and last the max-width equivalent. This would allow you to size a column as 1fr but not smaller than 200px and not bigger than 500px minmax(200px, 1fr, 500px)

[jonjohnjohnson]

@FremyCompany So making minmax() essentially the same as clamp()? But behaving *slightly different for grid, allowing fr units and the option for only 2 arguments (min/max)? If this is the case, would just replacing clamp() with minmax() across the board make sense?

https://drafts.csswg.org/css-values-4/#funcdef-clamp

[tabatkins]

@FremyCompany That's what we're considering for the "1fr in min position" case (#2611), but that doesn't seem relevant for this issue.

[FremyCompany]

@tabatkins Yes, this is only relevant now that we resolved #2611

But note that the idea is that a minmax with three values like above means that both 200px and 1fr are minimums (whichever is bigger wins) not just 1fr. And that, while retaining a 500px maximum.

[FremyCompany]

@jonjohnjohnson Yes, this is clamp but that allows mixing fr and length-percentage. I wouldn't mind renaming clamp to minmax or vice-versa, since no browser has support for it. I find minmax more intuitive but this is subjective and not all that important.

[SebastianZ]

I wouldn't mind renaming clamp to minmax or vice-versa, since no browser has support for it.

Things have changed since that comment. clamp() is now supported everywhere. So replacing it by minmax isn't an option anymore. So, what about using clamp() in this context?

Sebastian

[zetareticoli]

How about adding a new parameter? Just like minmax(min-value, max-value, more-prior-item) The third param more-prior-item specifies which one has the priority.

eg. minmax(20%, 250px, 'min') is equal to minmax(20%, 250px)
eg. minmax(20%, 250px, 'max') makes max wins over min, which could solve the maxwidth situation.

I like this approach. However, the 'min' case would be redundant because it's the default.
It could work only with specifying max.

What do you think?

[SebastianZ]

A keyword for the case where the minimum value wins is redundant but it also allows to be more explicit.

Sebastian