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 13:11:29 -0700
Message-ID: <CAAWBYDB1YkAOtBtS6ea2hWL6WAJzVwdUMZt2xEEfSrFZSZqe8g@mail.gmail.com>
To: François REMY <francois.remy.dev@outlook.com>
Cc: CSS WG <www-style@w3.org>
On Wed, Aug 27, 2014 at 8:17 AM, François REMY
<francois.remy.dev@outlook.com> wrote:
> Dear CSS Grid editors,
>
> I’m trying to understand the reasons behind the choice of the sizing
> algorithm of flexible tracks under no definite size constraint. As a
> reminder, please find quoted here the algorithm in question:
>
> # The used flex fraction is the maximum of:
> #
> # - Each flexible track’s base size divided by its flex factor.
> #
> # - The result of finding the size of an fr for each grid item
> #    that crosses a flexible track, using all the grid tracks
> #    that the item crosses and a space to fill of the item’s
> #    max-content contribution.
> #
> # For each flexible track, if the product of the used flex
> # fraction and the track’s flex factor is greater than the
> # track’s base size, set its base size to that product.
>
> While the reason behind the second set of constraints is obvious to me (we
> want flexible columns to at least encompass elements inside them, if we're
> free to give them any size we want), I'm not sure about the reason why the
> first set of constraints exist.

Because it's a very direct translation of what Flexbox does, and so
seems to make sense?  What confuses you about it?

> Also, if the plan is to make the layout system stable for flex factors
> approaching zero (like flexbox), then this first set of constraints will be
> annoying (as a very small flex factor can create huge track breadths (with a
> smart epsilon/epsilon-squared pair of flex factor; see test case), while a 0
> flex factor is identical to no flex at all which may result in collapsed
> columns).

Nah, factors <1 get handled slightly differently to maintain proper
behavior.  It took me a bit to work it out, but it makes a lot of
sense:

Basically, you're asking each track "what size should we give an fr to
make you maximally happy?".  For elements with >=1fr, they want to
fill the available space, so their answer is just the available space
divided by their fr value, so that when things multiply back out,
they're exactly filling the space, as desired.  For elements with <1
fr, they want to fill a *fraction* of the space, not the whole thing;
thus, they want 1fr to equal the available space, so that when things
multiply back out, they're filling the desired fraction of the space,
as desired.

So, when you're reversing the flex constraints, such as here, you can
basically just treat factors <1 as being equal to 1.  This works all
the way down to 0fr.

> I'm genuinely interested in the reasoning that shaped the design of this
> algorithm, and would already find helpful any answer providing a partial
> answer.

fantasai and I didn't actually write this part; most of the layout
algorithm is straight from the original MS publication of the spec.
That said, I think it makes sense.

~TJ
Received on Tuesday, 16 September 2014 20:12:16 UTC

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