W3C home > Mailing lists > Public > www-style@w3.org > May 2010

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

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Sun, 30 May 2010 16:18:17 -0700
Message-ID: <D0CAE219095C4C44B1985B9E761FD4A7@terra3>
To: "Zack Weinberg" <zweinberg@mozilla.com>
Cc: "Brad Kemper" <brad.kemper@gmail.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, <www-style@w3.org>


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

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.
Hmm, I need to think these paradoxes further... I have an
impression that something is still wrong within "negative free space"
continuum.

-- 
Andrew Fedoniouk

http://terrainformatica.com
 
Received on Sunday, 30 May 2010 23:18:45 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:27 GMT