- From: Andrew Fedoniouk <news@terrainformatica.com>
- Date: Sun, 30 May 2010 16:18:17 -0700
- 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 UTC