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: Wed, 19 May 2010 08:41:24 -0700
Message-ID: <AANLkTilc-Wti4X8IsyWOZU7H5Q93mykzeNewLgsuzPW_@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 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.

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

> Doubled computation is not that bad but this:
>  width: calc( 10px - 1fl );

Ah, good catch.  I forgot to define that negative flexes are invalid.

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

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

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

I'm not going to respond to you if you refuse to read what I write.

Received on Wednesday, 19 May 2010 16:48:32 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:35 UTC