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

--------------------------------------------------
From: "Tab Atkins Jr." <jackalmage@gmail.com>
Sent: Saturday, May 29, 2010 9:22 AM
To: "Andrew Fedoniouk" <news@terrainformatica.com>
Cc: <www-style@w3.org>
Subject: Re: [css3-flex] calc(flex) and concept of free space.

> On Fri, May 28, 2010 at 8:34 PM, Andrew Fedoniouk
> <news@terrainformatica.com> wrote:
>> It seems that I am the only person so far who have implemented
>> flex units as a complete system. I mean I have infrastructure already in
>> place to try the calc() in real environment. So here are practical
>> questions.
>>
>> 1) Meaning of "free space".
>>
>> I am assuming that free space gets computed as:
>> container-inner-space - sum-of-min-widths-of-children.
>> So if  sum-of-min-widths-of-children is greater than
>> container-inner-space then
>> 1.a) there is no free space, free space is zero;
>> 1.b) there is a free space but it is negative, if "yes"
>>   then it is not a free space strictly speaking.
>>   Good name for it anyone?
>>
>> Anyway, which one of 1.a) and 1.b) is true?
> 
> 1b.  This is in step 6.5.1 of my proposal.
> 

And what be the name of this entity? If positive
it is "free space" if negative then "over constrained space"
or "overflowed space"? Something like that?

> 
>> 2) Meaning of calc(flex + fixed)
>>
>> Let's imagine that we have container with
>> inner width = 1000px that has single empty child A
>> so it has no intrinsic min/max-widths.
>>
>> -----------------------------------------------------------------
>> If that A element is defined as
>>
>> A { width: calc(100px + 1fx); }
>>
>> I assume that min-widths-of-children in this case is:
>>
>> 2.a) min-width = 100px, free-space = 900px.
>>
>> So its computed width is just 1000px ?
>>
>> So that definition above is exactly (A - single child)
>> A { width: 1fx; min-width: 100px; }
>>
>> Yes/no?
> 
> No.  The calc() expression does not set a minimum size, it sets a
> preferred size.  The flexible length can get smaller than the
> preferred size if necessary.  In particular, if the parent was only
> 50px, then the child would also be 50px.  (If you had set min-width
> like in your last paragraph, the child would still be 100px.)
> 
> Setting a preferred size on the only flexible length in that axis
> basically does nothing (like setting 2fl versus 1fl in that situation
> - there's no difference).
> 

So you say that here

   A {  width: calc(100px + 10%); }

100px participates in min-content-width calculations, and
here 

   B {  width: calc(100px + 10fx); }

it is not?

Final A.width cannot be less than 100px in any circumstances and 
final B.width can be zero, correct?

I shall admit that I've overlooked the fact that you went that 
far with your change of calc() nature. All assumptions
in my original message were based on the fact that

A {  width: calc(100px + 1%); }
is not in principle different from 
B {  width: calc(100px +1fx); }
in terms of free space calculations.

If parent width is declared as having zero width for example then 
A will still be of 100px wide, and B would be zero, correct?
Or even B will be computed to -100px but set to zero?  I am lost here.

In any case this changes basic concepts of the calc() that is already 
implemented and used on the Web. I don't think that web and UA 
developers would like such dichotomy.  

And yet, what exactly triggers this dichotomy of these two modes
of the calc() calculation?  Any existence of 'fx' in expression?

Say here:
B {  width: calc(100px + 0fx); }
100px is that "preferred" width? And so final width 
can take any value either less or over that 100px?

And what should happen with the calc() here:
B {  width: calc(100px + 1fx);  float:left; }
calc(100px + 1fx) will be dropped as whole 
or it will behave as it defined as calc(100px)?

May I again propose to consider using another function for additive 
flexes? flex-calc(), aflex(), whatever. But leave current calc() 
implementations as they are at the moment.

> 
>> -----------------------------------------------------------------
>> If A element is defined as
>>
>> A { width: calc(1100px + 1fx); }
>>
>> 2.b) min-width = 1100px, free-space = -100px so element
>>  will not overflow as total width = 1000px;
>> 2.c) min-width = 1100px, free-space = 0px and element
>>  will overflow;
>>
>> If 2.c is true then it means that free-space as a value
>> cannot be negative.
> 
> Neither, as stated.  The length's minimum size is still 0, since there
> is no min-width set and no max() expression wrapping it.
> 
> The free space is -100px, and so the child will shrink to 1000px wide
> and not overflow.  (This is your 2b, just with correct details.)
> 

So again we are getting the situation when here:

A { width: calc(2000px + 1fx); }
B { width: calc(1000px + 1fx); }

A will be twice *narrower* than B, correct?

Any particular use cases that require such a ...umm... 
non-normative behavior?

In any case when you would need such behavior you go with

A { width: calc(2000px - 50%); }
B { width: *; }

or some such. 

> 
>> -----------------------------------------------------------------
>>
>> So if to assume that free space is always non-negative
>> that leads us to the constatation of the following:
>> any expression with flex units can only increase
>> minimal value and never decrease.
> 
> Free space can obviously be negative, and I have absolutely no idea
> how you are coming to this conclusion.  It doesn't follow from
> anything you or I have said this entire time.  Every time you say
> "free-space can't be negative" in this email it appears to be a
> non-sequitur, unconnected to anything that came before or after.
> 

Sorry, it appears as a cultural difference then.

Can, let's say, a parking space be negative? In Canada - usually no.
It could be free space or none. So we should invent another
term for the entity.

-- 
Andrew Fedoniouk

http://terrainformatica.com

Received on Saturday, 29 May 2010 19:34:00 UTC