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

--------------------------------------------------
From: "Tab Atkins Jr." <jackalmage@gmail.com>
Sent: Tuesday, May 18, 2010 10:43 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 Mon, May 17, 2010 at 10:58 PM, Andrew Fedoniouk
> <news@terrainformatica.com> wrote:
>>> 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?
>
> <div id=a>
>  <div id=b float:left>foo</div>
>  <div id=c overflow:hidden>
>    <div id=d width=50%>bar</div>
>  </div>
> </div>
>
> In this case, #c's width can't be calculated until after #b has been
> laid out.  Thus, #d's percentage can't be resolved until then either.
> I believe this all happens at used value time.

I see no problems with this as "computed-value time" for the
#c and #d elements is exactly after the moment when the
float was laid out.

Yes, you can use flexes here but only in horizontal direction.

So this works:

<div id=a>
  <div id=b float:left>foo</div>
  <div id=c overflow:hidden>
    <div id=d width="0.5*" >bar</div>
  </div>
 </div>

But vertical flexes will not work if that container
has floats. My initial implementation allowed
vertical flexes even with floats around. Got too many
bug reports.

>
>
>>>> 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?
>
> 'fit-content' is the new name given to 'intrinsic'.
>

Is it 'min-intrinsic' or 'max-intrinsic' ? That's the question.

In other words what is the value of 'fit-content' for
the element:
<p>1111 22222222</p>
longest word or sum of all words?

>
>> And how all this is different from:
>>
>> url-field { width: 3*; min-width: min-intrinsic; }
>> search-field { width: 1*; min-width: min-intrinsic; }
>
> Assume that both of them have a min-intrinsic width of 50px.  Now,
> assume that they have 160px of space total.  The initial flex
> distribution would make url-field 120px wide and search-field 40px
> wide.  But then we are violating the min-width on search-field, so we
> adjust it to 50px and just distribute the rest of the space to
> url-field.  This leaves us with url-field being 110px wide and
> search-field being 50px wide.  In other words, this leaves the
> url-input (the input inside the field, which is the only flexible part
> of it) being 60px wide, and the search-input still being 0px wide,
> since it doesn't get any space.  This is suboptimal - we'd prefer the
> extra space to be distributed proportionately, so you can at least
> type *something* into both.  So we'd like the url-input to be 45px and
> the search-input to be 15px.  With additive flex, this happens
> automatically.

I understand how all this is laid out.
My question is about different thing.

Let me put it this way:

What if you define it as:

url-field { width: 1*; }
search-field { width: calc(10% + 40px);  }

wouldn't it be sufficient for you?

With absolute flex units you can do pretty simple mental arithmetic
to predict the result. Additive flexes are adding needless level
of complexity to the already complex thing.

>
>
>> 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.
>
> It appears that they do something funky if you adjust the urlbar to be
> very wide, but otherwise it appears to flex exactly as you'd expect
> with additive flexes.
>

I really would expect that if I will make the window wider
to see all these fields increased proportionally.
Current Mozilla behavior creates discomfort - I cannot
predict that width. Usually if you want some flexible
element to be twice wider you would expect that
increasing width of the view twice will do the magic.
But here they have some secret (for the user) formula.

Additive flexes is just a nightmare of usability guys.

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

Doubled computation is not that bad but this:

  width: calc( 10px - 1fl );
or even this:
  width: calc( 1fl - 10px );

seems like source of troubles, no?

How would you compute free space in such cases?

>
> The much simpler conclusion one could draw is that you can't use
> flexes in min/max-width, *even inside of a calc() expression*.  That
> cleanly satisfies both restraints while still allowing authors the
> full range of options that calc() brings.

I know for sure that flexes greatly reduce need of the calc().
If you have any pages with the calc() already take a look on them
and you will realize that with flexes you can get rid of the
calc() in probably 100% of cases.

I've got an impression that the calc() is just a hack - pretty
ugly attempt to overcome despair of non-flexible box model.
But this is kind of aesthetic issue of my own -
probably is not too much related to the discussion.

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

-- 
Andrew Fedoniouk

http://terrainformatica.com

Received on Wednesday, 19 May 2010 05:55:46 UTC