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. ~TJReceived 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