Re: Fw: RE: [css-flexbox] Summary of planned changes to Flexbox Module

--------------------------------------------------
From: "Tab Atkins Jr." <jackalmage@gmail.com>
Sent: Wednesday, May 19, 2010 8:41 AM
To: "Andrew Fedoniouk" <news@terrainformatica.com>
Cc: <robert@ocallahan.org>; "Alex Mogilevsky" <alexmog@microsoft.com>; "Adam 
Del Vecchio" <adam.delvecchio@go-techo.com>; <www-style@w3.org>
Subject: Re: Fw: RE: [css-flexbox] Summary of planned changes to Flexbox 
Module

> On Tue, May 18, 2010 at 10:48 PM, Andrew Fedoniouk
> <news@terrainformatica.com> wrote:
>>>> 1) you can use calc() in min-width by definition.
>>>> 2) and you cannot use flexes in min/max-widths as they are
>>>>  precondition for flex computation. Also by definition.
>>>>
>>>> Deducing this simple system of logic statements we are
>>>> getting the fact that calc() cannot use flexes.
>>>>
>>>> Quod erat demonstrandum.
>>>
>>> Honestly?  Come on now, that's just silly.  Don't try to dress
>>> something up as a logical proof unless you actually want to bring
>>> rigor to the table.  There are a ton of hidden assumptions you're
>>> bringing along that aren't necessarily valid.  For example, you're
>>> assuming that if a particular calc() expression is allowed anywhere,
>>> it must be allowed everywhere.
>>
>> Word "silly" has many meanings. What in particular does it mean here?
>> That proof is logically correct one if to use current specs as a base.
>
> I explained why it was silly.  You are assuming things that are not
> necessarily reasonable.  If you change some of those assumptions, you
> get a different result.
>
> Formal logic should be left to the mathematicians.  They're the only
> ones who can agree on their axioms enough to get useful work done.
>

That is refreshing. So formal logic cannot be used in CSS discussions.
Is it sort of new CSS-WG spirit or just your personal opinion on the 
subject?

That is rhetoric question as I am considering all this prose above
as consequences of "flex fever".

>
>> I am looking on the problem from practical implementation
>> point of view.
>>
>> This expression:
>>  width: calc( 10px + 1fl );
>>
>> has to be computed twice:
>> 1) At the same time as min/max-widths are computed
>>   to determine free space. Note: at this point you have
>>  nothing to compute 1fl with.
>> and 2) after you will get free space to compute final
>> value.
>
> Actually that can be calculated once.  It yields a flexible length
> with a flexibility of 1, a preferred size of 10px, a minimum size of
> 0px, and a maximum size of infinity.
>
> When determining free space, this length is treated as a 10px length.
> This is defined as a "preflex length" in my new draft.
>

If you want it to compute once then you will need mechanism
that will do kind of AST (abstract syntax tree) (algebraic )analysis
to split your expression on fixed and flexible parts.

The easiest way to deal with such mixed calc()s
will be to evaluate it twice, fist time with free space equal
to zero (so 1 flex will become just zero) and second evaluation
with zero dpi (so 1px & friends will become zeroes).
So you will have fixed and flex portions separately.

But problem below too.

>
>> Doubled computation is not that bad but this:
>>

>>  width: calc( 10px - 1fl );
>
> Ah, good catch.  I forgot to define that negative flexes are invalid.
>

Not just negative.  Consider this:
  width: calc( 10px + (2-3) * 1fl );

or this expression :

  width: calc( ((50% - 30px)/60px) * 1fl );

that may or may not lead to negative flexes.

>> or even this:
>>  width: calc( 1fl - 10px );
>
> That's perfectly fine.  It's a flexible length with a preferred size
> of -10px.  There's nothing inherently wrong with a preferred size
> being less than the minimum size.

I am not getting this: "width:-10px". What does it mean?
Consider that you will get no free space?

>
>
>> How would you compute free space in such cases?
>
> The preflex length is the greater of the preferred size and minimum
> size, so it would count as 0px when computing free space.
>

Not clear. Does it mean that
  width: calc( 1fl - 10px );
will be evaluated to zero?

If additiveness is really needed I would introduce new function,
something like:

  flex( weight[, addition:length [, min:length [, max:length ]]])

rather than marrying calc() and flexes.

>
>>>> Floats participate in computation of free space so
>>>> their replacement happens before any flexes.
>>>>
>>>> At the moment of replacing any float element  you must know
>>>> positions and dimensions of elements above it. When
>>>> you have replaced float element you are not allowed to change
>>>> positions of static and float elements above it. That are rules
>>>> floats rely on at the moment. And we'd better don't touch this.
>>>>
>>>> Your attempt to enable padding-top:1fl on the element above
>>>> that float means that you are going to change position
>>>> of element that was used for computation of position of that
>>>> float. So you will have mismatch of "float anchor point" and
>>>> its real position.  I don't think all this will fly.
>>>
>>> No, that's not at all what will happen.  I said precisely what would
>>> happen in this case in the algorithm.  While doing normal-flow
>>> computation of the outer div, the padding-top:1fl is treated as
>>> padding-top:0.  You then compute the height of the flexbox exactly as
>>> normal for a normal-flow element.  Then you can do flex computation
>>> inside the element and position the float alongside the element, and
>>> the two won't affect each other.
>>>
>>> This does mean that, in this case, the padding-top:1fl will have no
>>> effect, because the element will already have shrunk as much as
>>> possible to conform to what normal-flow expects.  But it *could* have
>>> an effect, for example in this code:
>>>
>>> <div display:block>
>>>  <div display:flexbox; padding-top:1fl; box-sizing:border-box; height:
>>> 300px;>
>>>   <span>foo</span>
>>>   <span>bar</span>
>>>  </div>
>>>  <div float:right>baz</div>
>>> </div>
>>>
>>> The flexbox would have a 250px high border-box, and then the
>>> padding-top would get to flex and push the children down to the
>>> bottom.  Still, though, the padding-top flex would not interact in any
>>> way with the layout of the flexbox in the normal-flow of its parent,
>>> or the position of the float following it.
>>>
>>
>> Yes float will not interact with the layout of the flexbox.
>> They will be just drawn on top of each other. If your
>> mental model of static flow allows this then fine.
>> Usually such rendering are considered as bugs. And
>> they are bugs as they make information on the page
>> non-accessible.
>
> Once again, I described exactly what would happen, *directly above
> what you said right here*.  Seriously, just look one paragraph up and
> you'll see my section of the quote, where I explain this.  It's very
> simple, and it does not result in anything getting drawn over anything
> else.
>
> I'm not going to respond to you if you refuse to read what I write.
>

Hmm, missed box-sizing:border-box for some reasons, terribly sorry.
Without box-sizing:border-box all this will not work obviously.

Usually it is enough to say:
div.box > :first-child { margin-top: 1flex; }
to get exactly the same result.

And so the spec will be simpler to define and to implement.
That box-sizing is to easy to miss. And its change in one place
will lead to "dramatic " jumps that would be very hard to
understand.

-- 
Andrew Fedoniouk

http://terrainformatica.com

Received on Thursday, 20 May 2010 04:38:56 UTC