Re: Fw: RE: [css-flexbox] Summary of planned changes to Flexbox Module

On Thu, May 13, 2010 at 11:42 PM, Andrew Fedoniouk
<news@terrainformatica.com> wrote:
>> 2) Collapse margins on flexbox children, if that margin is collapsible
>> (dependent on value of margin-collapse):
>>  a) Separate each margin into a flexible segment and an inflexible
>> segment (many margins will have only one or the other - in that case,
>> the missing segment is zero).
>
> I suspect that it is better to use "fixed/flexible part" instead of
> "fixed/flexible segment".

I'll keep that in mind and see which sounds best.


>>  b) The collapsed margin is then composed of 3 segments: an
>> inflexible segment, a flexible segment, and a flexible segment with a
>> minimum-size constraint:
>
> It is not clear what does "margin is then composed of 3 segments"
> mean.  Value of collapsed margin may have fixed part or/and
> flex part. Where the "3" comes from?
>
>>   i) The inflexible segment is the minimum of the two inflexible segments
>>   ii) The flexible segment is the minimum of the two flexible segments
>>   iii) The flexible-with-constraint segment has flex equal to the
>> difference of the two flexible segments, and a minimum-size constraint
>> equal to the difference of the two inflexible segments
>
> This is not clear at all. You have two margins (m1 and m2) that are
> collapsed
> into single space m.
>
> If m1 is flex and m2 is flex then m is a flex of max(m1,m2)
> If m1 is fixed and m2 is fixed then m is a fixed value of max(m1,m2)
> Otherwise you have so called "discriminated flex value" -
> flex with min constraint.

Exactly.  All three of those cases can be combined in a single
situation, though, if each margin is a mixture of fixed and flexible
by itself.

That is, if you're collapsing calc(20px + 1fl) and calc(10px + 2fl),
you're left with a fixed segment of 10px, a flexible segment of 1fl,
and a flexible segment of 1fl with a minimum-size constraint of 10px.


>> 3) You now have a collection of flexible segments, some with
>> minimum-size or maximum-size constraints (min-width and max-width
>> specify constraints on the width's flexibility, if any), and a
>> collection of inflexible segments (any non-flexing widths, paddings,
>> margins, and borders).  The free space in the flexbox is equal to the
>> width of the flexbox minus the length of all the inflexible segments
>> and the minimum width of any flexible segments with a minimum-size
>> constraint.  If the free space is negative, set all flexible segments
>> to 0 length and exit this algorithm; the children will overflow the
>> flexbox in the direction indicated by box-begin.
>>
>> 4) If the flexbox is in a flow that does not allow flex units, but it
>> has flexible padding, distribute the free space among the flexbox's
>> padding in proportion with the flexibility of padding-left/right.
>> Reduce the free space by the amount of flex the padding has assumed.
>>  (If the flexbox is in a flow that allows flex units, then flexible
>> padding or any other flexible unit has already been resolved when
>> doing the flex computations of its parent, and so this step is
>> unnecessary.)
>
> This is not clear. I suspect that this paragraph will ruin floats.
> Could you provide any example of this?

I'm not sure what you mean by "ruin floats".  Can you be more specific?

The basic example is this:
<div style="display: block;">
  <div style="display: flexbox; padding: 0 1fl;">
    <span>foo</span>
    <span>bar</span>
  </div>
</div>

According to step 0, the inner div had its width computed in normal
flow as if it had padding:0;.  So it fills the width of the outer div,
just like block elements normally do.

By step 3, free space is the width of the inner div minus the width of
the child spans.

Step 4, then, distributes that free space among the div's padding,
centering the children inside the div.

(I need to be somewhat more specific in this step about how to
calculate free space, so it doesn't squish children with flexible
width down to nothing...)


>> 5) Distribute flex among flexbox children:
>>  a) Divide the free space up among the flexible segments in
>> proportion to their flexibility.
>>  b) If any minimum-size or maximum-size constraints are not
>> satisfied, set that segment to the minimum size necessary to satisfy a
>> minimum-size constraint, or the maximum size necessary to satisfy a
>> maximum-size constraint, and set that segment's flexibility to 0.
>> Return to step (a).
>>  c) If all constraints are satisfied, the algorithm is finished.
>>
>>
>> This algorithm does involve iterating until the flexibility
>> constraints are satisfied, but this should be acceptable.  The current
>> Flexbox spec requires the exact same iteration, and further, this
>> isn't iterative *layout*, since all the inflexible lengths the
>> algorithm needs can be calculated before this is run, and the layout
>> needs of grandchildren of flexboxes won't affect the variables that
>> this algo cares about.
>>
>> I suspect linear programming may lead to a faster calculation of flex
>> distribution, but I don't know the subject well enough to say anything
>> about that.
>
> Usually linear programming tasks are being solved by various
> iterative algorithms, simplex method as an example.
>
> But this particular way of flex computation that you've defined
> is finite. The loop you have described above is limited by
> a number close to N*ln(N) repetitions with very good
> convergence. In most cases it is just N so nothing to write
> home about.

All right, cool.


>> It's important to note where flex units are allowed here.  Children of
>> flexboxes may use flex units in any of width/height/margin/padding.
>
> I suggest to add there border-width too. Think about border-image's,
> e.g. gradients.

Hmm, maybe.  Fantasai and I discussed border-width and decided against
it, but I'm not quite sure why we did now.  I'll look into this again.


>> Flexboxes themselves, if they are not in a flow that allows flex
>> units, may still use flex units in their padding only.  (If they are
>> in a flow that allows flex units, such as if they are themself the
>> child of another flexbox, then they may of course use flexes for any
>> of the dimensions allowed by that flow.)
>>
>> Does anyone see any problems?  Any places where you think I've missed
>> an important case?  Any particular area you'd like to see in more
>> detail?
>
> It is better to move definition of the algorithm to separate chapter.
> The algorithm takes vector of triplets {min, max, flex} and total length to
> distribute
> and computes final lengths for each element in the vector.
> How is that vector gets filled is irrelevant to the algorithm per se.
> This algorithm is used all over CSS already. In 'auto' calculations in most
> of cases
> and in <table> layout computations.

Possibly.  I'll leave it in for the moment, and split it out later
when it seems useful.

~TJ

Received on Friday, 14 May 2010 16:17:36 UTC