- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 10 Apr 2014 12:11:42 -0700
- 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. ~TJ
Received on Thursday, 10 April 2014 19:12:30 UTC