W3C home > Mailing lists > Public > www-style@w3.org > April 2012

Re: [css3-flexbox] Handling 'auto' main sizes.

From: Anton Prowse <prowse@moonhenge.net>
Date: Thu, 26 Apr 2012 14:23:01 +0200
Message-ID: <4F993E25.3010702@moonhenge.net>
To: "www-style@w3.org" <www-style@w3.org>
CC: Alex Mogilevsky <alexmog@microsoft.com>, fantasai <fantasai.lists@inkedblade.net>
On 25/04/2012 15:07, Alex Mogilevsky wrote:
>  From: fantasai [mailto:fantasai.lists@inkedblade.net]  Sent:
> Friday, April 20, 2012 3:24 PM   It's not clear to me from reading
> the algorithms what     width: auto;     flex: auto;  would result
> in, since the 'width' is neither definite nor one of the values
> handled  explicitly in the Flexbox algorithm. (Even if it was clear,
> I'd suggest making a note of it  in the 'flex' section so authors
> would have some chance of noticing.)   My suggestion is that it do
> something smart, like 'fit-content' with an imposed min-size of 
> 'min-content'.
> 'flex:auto' simply means "use the value of width or height as
> preferred-size" (unless we want to add yet another keyword to mean
> that), so the question really is what it means to have preferred size
> of 'auto'.
> It is true that there is no "normal" automatic size, flexbox has to
> define what it wants, and it does in 9.4. "Determine the hypothetical
> main size of each item".
> The current layout algorithm says "treating 'auto' as 'fit-content'",
> which I actually disagree with.
> 'auto' preferred size should be resolved as 'max-content'. That was
> always my assumption, it is what IE10 does and it agrees with at
> least one of old-flexbox implementation.
> 'fit-content' constrains the shrink-to-fit size to available space,
> which makes sense for floats, but for flexbox items it will result in
> their flexibility base being affected by size of flexbox or its
> parent, which has no bearing on either properties of content or
> actual constraints for item size.
> For example:
> <flexbox> <div style="flex:0 1 auto">some amount of plain text</div>
>  <div style="flex:0 1 auto">some different amount of plain
> text</div> </flexbox>
> (there is enough text to be wider than available space if put
> together, so items will have to shrink)
> In this case, should we expect that child with more text will get
> more space? It will, unless both children are wider than the space
> that would have been available if the other child were not there,
> which doesn't seem useful at all... Using 'max-content' for preferred
> size will get a more predictable behavior here.

Assuming a small min-content width, 'max-content' is the same as 
'fit-content' unless the max-content width is larger than the available 
width.  So I'm assuming that in your example, the available width is 
less than the max-content width of both the divs.  But then, 
'fit-content' gives rise to flex basis equal to available width for both 
items, where as 'max-content' gives rise to a different flex basis for 
each flex item... which seems to be the opposite of what you're arguing! 
  Or perhaps I'm misunderstanding you...

> ...... which leads to another problem with negative flexibility ....
> Currently, flexibility is always addition and subtraction, not
> multiplication or division. It makes sense when stretching - when
> items already have the space they wanted, they get equal share of
> additional space (given same flexibility).
> But when shrinking, subtraction isn't really a good way of fair
> distribution. It works OK with minor adjustments, but if space
> shortage is significant and some items are much bigger than others,
> small items quickly shrink to zero (or their min size), while big fat
> items may not even notice. The problem can be mitigated by giving
> bigger items bigger negative flex, but it is only possible if the
> author knows what will be bigger...
> I didn't think about it as a major problem, possibly because negative
> flexibility is rarely called for, but maybe the reason negative
> flexibility is rare is that it doesn't work?
> I think shrinking should be done by *dividing* the flexible lengths
> proportional to flexibility. Something like this:
> shrink-factor = sum(preferred-size / negative-flex) /
> available-space used-main-size = main-size / (shrink-factor *
> negative-flex)
> this way, when shrinking, flex items remain proportional to their
> preferred size, which makes much more sense to me.

I like this idea.

Anton Prowse
Received on Thursday, 26 April 2012 12:23:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:15 UTC