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

--------------------------------------------------
From: "Tab Atkins Jr." <jackalmage@gmail.com>
Sent: Friday, May 14, 2010 9:16 AM
To: "Andrew Fedoniouk" <news@terrainformatica.com>
Cc: <robert@ocallahan.org>; "Alex Mogilevsky" <alexmog@microsoft.com>; "Adam 
Del Vecchio" <adam.delvecchio@go-techo.com>; <www-style@w3.org>
Subject: 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.
>

Segments stands for "one of several parts or pieces that fit with others
to constitute a whole object"

So if to speak about Additive Flexes then "segments"are appropriate.
Additive flex consist of base segment and flex segment that can be added
or subtracted from the base.

Absolute flex by itself defines single flexible segment with min/max 
constraint.
So "flexible segment and an inflexible segment" sounds like a non-sense for
absolute flexes.

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

I've explained the problem here:
http://lists.w3.org/Archives/Public/www-style/2010May/0210.html

In brief:
You cannot use flexes in calc() by its definition:
The calc expression is computed at the same time as 'em' lengths
and percents are computed.
Flexes are getting resolved *after* all other lengths are determined
so after calc() of any sort.

So "margin is a mixture of fixed and flexible by itself" of yours is not
clear - not clear how such mixture can be defined.

Do you have examples where calc(20px + 1fl) can be useful?

And what would be a result of say this:
   calc( (20px + 1fl) / 2 + (10px + 2fl) * 3 )?

>
>
>>> 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>

consider this:

<div style="display: block;">
  <div style="display: flexbox; padding-top:1fl;">
    <span>foo</span>
    <span>bar</span>
  </div>
  <div style="float:right" >zot</div>
</div>

"foo,bar" will be drawn on top of "zot". That is at best.
Flex computation happen *after* float replacements.

That's why your statement  "ruins floats".

>
> 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...)
>
>
>>> 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.
>
>

-- 
Andrew Fedoniouk

http://terrainformatica.com

Received on Saturday, 15 May 2010 03:14:22 UTC