Re: [css3-flex] calc(flex) and concept of free space.

--------------------------------------------------
From: "Tab Atkins Jr." <jackalmage@gmail.com>
Sent: Sunday, May 30, 2010 4:32 PM
To: "Andrew Fedoniouk" <news@terrainformatica.com>
Cc: "Zack Weinberg" <zweinberg@mozilla.com>; "Brad Kemper" 
<brad.kemper@gmail.com>; <www-style@w3.org>
Subject: Re: [css3-flex] calc(flex) and concept of free space.

> On Sun, May 30, 2010 at 4:18 PM, Andrew Fedoniouk
> <news@terrainformatica.com> wrote:
>> --------------------------------------------------
>> From: "Zack Weinberg" <zweinberg@mozilla.com>
>> Sent: Sunday, May 30, 2010 2:49 PM
>> To: "Andrew Fedoniouk" <news@terrainformatica.com>
>> Cc: "Brad Kemper" <brad.kemper@gmail.com>; "Tab Atkins Jr."
>> <jackalmage@gmail.com>; <www-style@w3.org>
>> Subject: Re: [css3-flex] calc(flex) and concept of free space.
>>
>>> "Andrew Fedoniouk" <news@terrainformatica.com> wrote:
>>>
>>>> Expressions like
>>>>  width: calc(100px + 1fx)
>>>> participate in flex calculations twice:
>>>> First time to determine free space and second time when
>>>> free space is known and so we can do that final widths calculations
>>>> with respect of flexes and that preferred width.
>>>
>>> Sure.  All I'm saying is that the problem here could be resolved if the
>>> width used for the first pass was a rigid 100px.  Which I guess is what
>>> you are also saying, but it's hard to tell.
>>
>> Yes, you get this right.
>>
>> So in 1000px container this
>> width: calc(100px + 1fx)
>> 1fx will be calculated to 1000px - 100px and
>> so final width will be calculated to full
>> 1000px.
>>
>> We agreed on that.
>>
>> Now let's assume that container is of 50px wide.
>> and we have
>> width: calc(100px + 1fx).
>> There is no room to replace that width so we have
>> two options:
>> 1) to assume free-space = 0 (no free space).
>> 2) to assume free-space = -50px ("negative" free space).
>>
>> In case #1 we have width calculated to 100px.
>> In case #2 we have width calculated to 50px.
>>
>> I understand case #2 and it may work.
>>
>> So width: calc(100px + 0fx) not anyhow
>> different from calc(100px + 1fx) for free space
>> calculation purposes.  Both produce the same
>> 100px values. This is different  from Tab was saying.
>
> No, for free space calculation the two are the same.  When calculating
> free space, you subtract any inflexible lengths (which calc(100px+0fl)
> is) and the preflex length of any flexible lengths (which, for
> calc(100px + 1fl), is 100px).
>
> You were previous asking about scrollbars, not free space.  Scrollbars
> won't appear until all flexible lengths have shrunk as far down as
> possible.  That's where the two lengths you describe are different.
> The first length is inflexible and can't shrink.  The second length
> *can* shrink, all the way down to 0, so a scrollbar will appear at
> different times for the two.
>
> (I'm getting a niggling thought that there may be a contradiction, or
> at least a difficulty, lying in this space, but I'm not sure.  I'll
> need to think on it.)
>

Scrollbars just show that negative free space of yours :)

Anyway, tell me better what would be the width of inner div here:

<div width:1000px padding-left:1fx>
    <div width:calc(500px + 1fx) />
</div>

Something tells me it will get zero, correct?

>>
>> I suspect that such "positive or none free space" is related
>> to the fact that display:table-cell element establishes block
>> formatting context (BFC). But the problem is that elements with
>> flex dimensions are also BFC blocks so conceptually they also
>> follow "positive or none free space" idiom.
>
> That's not at all necessary.  The table-cell behavior is not
> intrinsically related to BFC behavior.  It just happens to be how
> tables work.
>

At least I see comments in my code that it is a must for flex calculations.
But they are not telling me why and I've forgot what I meant at that
moment :) , investigating.

-- 
Andrew Fedoniouk

http://terrainformatica.com

Received on Monday, 31 May 2010 03:01:23 UTC