W3C home > Mailing lists > Public > www-style@w3.org > September 2014

Re: [css-grid] Flexible Track Sizing & Indefinite Avail Size

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 16 Sep 2014 15:11:51 -0700
Message-ID: <CAAWBYDD39vBHPC4ms6aLmHaaQ8mUr4-4JU5yjkR1EOU3-pcU1Q@mail.gmail.com>
To: François REMY <francois.remy.dev@outlook.com>
Cc: CSS WG <www-style@w3.org>
On Tue, Sep 16, 2014 at 2:22 PM, François REMY
<francois.remy.dev@outlook.com> wrote:
>>> # The used flex fraction is the maximum of:
>>> # - Each flexible track’s base size divided by its flex factor.
>>> Why?
>> Because it's a very direct translation of what Flexbox
>> does, and so seems to make sense?  What confuses
>> you about it?
> I don't see how this is similar to what is defined about flexboxes, but maybe I'm just too unfamiliar with it. I never played with the basis size very much.
> Just to confirm, let's take an example: If, out of two columns in a grid with no child item, I specify a minimum width for the first column to be 100px, but say that it should take 10% of the free space (i.e. minmax(100px, 1fr)) while the other one gets the remaining 90% (9fr) of the free space.
> Under a size constraint, there are two possible behaviors for this grid: if its size is less than 1000px, it will work like (100px 1fr), in the other cases, it will work like (1fr 9fr).
> When I position this grid absolutely, I don't expect it to reach a width of 1000px (=1*100px+9*100px since 1fr=max(100px/1, 0px/9)), but I would rather see it stay at 100px and let the value of 1fr be 0px (this is the smallest fraction that satisfies all max-content constraints).

Why not?  Assume that the two columns are just 1fr and 9fr, no min
size, and the first column has an item that's 100px wide.  You'd
expect the grid to be 1000px wide then, right?  Fundamentally, Grid
tries to reverse the flex relationships to preserve the intention;
this is a bit different from Flexbox.

(Note also that optimizing for empty grids isn't useful.)

Received on Tuesday, 16 September 2014 22:12:38 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:24 UTC