W3C home > Mailing lists > Public > www-style@w3.org > May 2010

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 18 May 2010 10:43:38 -0700
Message-ID: <AANLkTimY3Sl0GGylnJQDxsdG4sXrOY9EVjh9xIECfgZB@mail.gmail.com>
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
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>

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.

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

> 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

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

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

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.

Already, you can't use flexes in calc() expressions for anything in
normal flow.  A plain <div style=display:block><div
style="width:calc(10px+1fl);"></div></div> is invalid as well, because
flexes aren't allowed in normal flow.

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

(Actually, I just realized that I misinterpreted the example.  In my
head the float came first, and so sat alongside the flexbox.  But the
situation the example actually describes is similarly

> 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;>
  <div float:right>baz</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.

Received on Tuesday, 18 May 2010 17:44:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:46 UTC