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

On Sat, May 29, 2010 at 12:33 PM, Andrew Fedoniouk
<news@terrainformatica.com> wrote:
> --------------------------------------------------
> 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?

It's just called "free space".  That may not be a perfect name, but
it's only used in explanations, so shrug.  I could certainly use a
different word if necessary.


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

I have no idea what you are talking about here.


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

It's... not?  In the first case the preflex length (used for free
space calculations) is 100px+1%.  In the second case it's 100px.


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

Correct.  A is inflexible, so it won't change.  B is flexible with no
minimum size, so it can flex all the way down to 0px if necessary.


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

Again, I have no idea what sort of "change" you are referring to.


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

That length is not flexible.


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

If B is a child of a flexbox, float is ignored (it computes to
'none'), and B then acts like any normal flexbox child would.  If B is
not a child of a flexbox, then either the flex is ignored (treating it
as calc(100px)) or the expression is invalid; I haven't decided which
seems the most reasonable.


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

No.  Could you explain what part of the spec or my words led you to
believe that?  I'd like to make sure I'm not unintentionally saying
something completely wrong.  It would be really helpful if you could
point to specific lines in my proposed algorithm leading you to that
conclusion.

~TJ

Received on Sunday, 30 May 2010 00:52:52 UTC