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

Re: [css-flexbox] Point of "Recalculate free space" step in loop?

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 10 Apr 2014 12:11:42 -0700
Message-ID: <CAAWBYDDCWn3zfbKLAm4YNBNVnERUCyC7UsZF_7KBCYOoZFuAWA@mail.gmail.com>
To: Daniel Holbert <dholbert@mozilla.com>
Cc: www-style <www-style@w3.org>
On Thu, Apr 10, 2014 at 12:01 PM, Daniel Holbert <dholbert@mozilla.com> wrote:
> Hi Tab,
> AFAICT, the "Recalculate free space" step in the Resolving Flexible
> Lengths loop isn't useful right now. (and perhaps needs changing to make
> it do something useful?)
> In particular - I don't see how the free space calculated before the
> loop would differ from the free space calculated on each loop iteration
> (and hence, the recalculation seems unnecessary).
> Both before the loop and during the loop, the algorithm calculates the
> free space as follows: are calculated as follows...
>    # Sum the outer flex base sizes of all items on the line,
>    # and subtract this from the flex container’s inner main
>    # size. This is the free space.
> ...and none of the values involved there (flex base sizes,
> margin/border/padding for "outer"-ness, flex container's main size) are
> going to change as we loop. So the calculation should always be the
> same, right?
> (Perhaps for frozen flex items, we want to be summing their outer *main
> sizes*, not their outer *flex base sizes*?)
> http://dev.w3.org/csswg/css-flexbox/#resolve-flexible-lengths

Ah, yes, you're right.  The point of recalculating is that frozen
items now have a different size than they had before.  Try this out:

# Sum the sizes of all items on the line:
# for frozen items (initially none, see later in this algorithm for
how items are frozen),
# use their outer main size;
# for all other items,
# both flexible and inflexible,
# use their outer <a>flex base size</a>.
# Subtract this sum from the flex container's inner main size.
# This is the free space.

Received on Thursday, 10 April 2014 19:12:30 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:39 UTC