W3C home > Mailing lists > Public > www-style@w3.org > April 2016

Re: [css-grid] fr units and minmax() mins

From: fantasai <fantasai.lists@inkedblade.net>
Date: Mon, 11 Apr 2016 19:55:09 -0400
To: "Eric A. Meyer" <eric@meyerweb.com>, www-style list <www-style@w3.org>, Peter Salas <psalas@microsoft.com>
Message-ID: <570C395D.4050308@inkedblade.net>
On 03/22/2016 09:19 PM, Eric A. Meyer wrote:
> The behavior of flex items in the 'min' position of a minxmax() is somewhat confusing to me. It's explained quite clearly, but
> what's explained doesn't really gel for me, conceptually speaking.
>
> To quote https://drafts.csswg.org/css-grid/#valdef-grid-template-columns-minmax:
>
> "minmax(min,max)
> Defines a size range greater than or equal to min and less than or equal to max. If max < min, then max is ignored and
> minmax(min,max) is treated as min. As a maximum, a <flex> value sets the track’s flex factor. As a minimum, it is treated as
> zero (or min-content, if the grid container is sized under a min-content constraint)."
>
> So if I declare:
>
> |grid-template-columns: 100px minmax(3fr, 300px) 1fr 100px; |
>
> ..then the third column (1fr) will flex all the way down until it reaches zero width. At that point, the second column, the
> minmaxed one, will start to flex narrower. The two never flex at the same time.
>
> My expectation, before reading that passage closely, was that the above CSS would cause the second column to be given |3fr|
> sizing until it reached 300 pixels in width, at which point it would stop growing. Thus, below that width, the second and
> third columns would flex and be sized at a 3:1 ratio, using whatever space was left over after the first and fourth columns
> were placed. Above that width, the first, second, and fourth columns would all be fixed-width, and the third would get all the
> flex space. Was my expectation.
>
> I have to admit the reasoning behind the current behavior eludes me. Why are flexible mins force-set to zero?

I think what you're expecting totally makes sense, but also
fixing it would mean adding additional steps to the track
sizing algorithm, which I'm a little hesitant to do right
now...

But something that's imho definitely worth investigating,
so perhaps it would make sense to make this syntax invalid
for the moment, so that we can figure out what to do with
it in Level 2.

~fantasai
Received on Monday, 11 April 2016 23:55:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:02 UTC