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

--------------------------------------------------
From: "Tab Atkins Jr." <jackalmage@gmail.com>
Sent: Monday, May 17, 2010 2:51 PM
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 Fri, May 14, 2010 at 7:47 PM, Andrew Fedoniouk
> <news@terrainformatica.com> wrote:
>> I've explained the problem here:
>> http://lists.w3.org/Archives/Public/www-style/2010May/0210.html
>>
>> In brief:
>> You cannot use flexes in calc() by its definition:
>> The calc expression is computed at the same time as 'em' lengths
>> and percents are computed.
>> Flexes are getting resolved *after* all other lengths are determined
>> so after calc() of any sort.
>>
>> So "margin is a mixture of fixed and flexible by itself" of yours is not
>> clear - not clear how such mixture can be defined.
>
> If that's a problem, it's equally a problem for %s, since some
> percentages can't be resolved at computed-value time.
>

Interesting. Did I miss some critical changes in box model?
What are these percentages that cannot be resolved at
computed-value time? Any example?

>
>> Do you have examples where calc(20px + 1fl) can be useful?
>
> You need the ability to do min()/max() (which are resolved at the same
> time as calc()) to emulate min/max-width for padding/border/margin.
> Using calc() lets you create additive flexes.
>
> For example, the Firefox urlbar and searchbar are "width:
> calc(fit-content + 3fl)" and "width: calc(fit-content + 1fl)",
> respectively (and then the inputs inside of each are both "width:
> 1fl").

What exactly is this 'fit-content' you use?  For that urlbar in particular?

And how all this is different from:

url-field { width: 3*; min-width: min-intrinsic; }
search-field { width: 1*; min-width: min-intrinsic; }

And I am not sure how that search bar is relevant
to flex discussion at all. URL and search field in FF are
resizable (splitter alike sizer in between) and
I suspect they use some "manual" way of computing widths.
Otherwise I would like to see computation of that additive
flexes from used splitter position (while moving splitter).
It is pretty easy to do with absolute flexes but additivity
makes this task challenging.

>
>
>> And what would be a result of say this:
>>  calc( (20px + 1fl) / 2 + (10px + 2fl) * 3 )?
>
> Exactly what it looks like, after you resolve all the math?  40px + 6.5fl.
>

OK what about this then:

{
   min-width: calc( 10px + 1fl  );
   width: calc( 20px + 2fl  );
}
?

Above is wrong of course.

See:

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.

>
>> consider this:
>>
>> <div style="display: block;">
>>  <div style="display: flexbox; padding-top:1fl;">
>>   <span>foo</span>
>>   <span>bar</span>
>>  </div>
>>  <div style="float:right" >zot</div>
>> </div>
>>
>> "foo,bar" will be drawn on top of "zot". That is at best.
>> Flex computation happen *after* float replacements.
>>
>> That's why your statement  "ruins floats".
>
> I still don't understand why this "ruins" anything.  Yes, the flexbox
> and its children will sit underneath the float, just like any normal
> box (the lineboxes inside the flexbox children don't participate in
> normal layout, and thus aren't shoved out of the way of the float).
>
> If this is a problem, you just make the flexbox a BFC, so it won't
> overlap the float.  Dealing with float-overlaps is already part of any
> experienced webdev's toolkit.
>

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.

-- 
Andrew Fedoniouk

http://terrainformatica.com

Received on Tuesday, 18 May 2010 06:05:57 UTC