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


> So as I said once at free space calculation phase you
> can just treat all flexes as zeros and run normal calculations on
> calc()s to get min-intrinsic widths (and so to compute free space).
>
> Everything is fine but now consider this document:
>
> <html>
>  <head>
>   <title></title>
>   <style>
>     div { border:1px solid blue; width:100px; display:table-cell; }
>     p { border:1px solid red; width:1000px; }
>   </style>
>  </head>
> <body>
>  <div>
>   <p>.</p>
>  </div>
> </body>
> </html>
>
> Note that display:table-cell; there. Try to remove it and you should see the
> difference. Without display:table-cell; we have "negative free space" - <p>
> overflows inner box of the <div>. But with display:table-cell
> there is no concept of  "negative free space"  as display:table-cell de
> facto
> enforces "min-width: min-intrinsic" or behaves as such.
>
> So in table-cells we have no "negative free space" and all
> calc()s with flexes will always evaluate to numbers greater or equal
> to preferred widths.
>
> 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.

~TJ

Received on Sunday, 30 May 2010 23:33:32 UTC