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

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

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

Alex

Received on Wednesday, 25 April 2012 13:08:32 UTC