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

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.

Cheers,
Anton Prowse
http://dev.moonhenge.net

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