- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 24 Apr 2012 09:16:41 -0700
- To: www-style@w3.org
On 04/23/2012 02:34 AM, Anton Prowse wrote: > On 21/04/2012 00:24, fantasai wrote: >> 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'. > > From Section 7, it is already clear what behaviour should result, right? The flexbox items are block-level boxes inside a > flexbox container which establishes their containing block. Hence each non-replaced, non-table item's outer width is the width > of that containing block, and so there will be one such item on each line in the case of a multi-line flexbox, or all such > items will be on the same line but typically with rather a lot of overflow in the case of a single-line flexbox. Flexbox items aren't block-level any more than table cells are. If that's the intended behavior, it needs to be specified. > However, the idea of having the combination of ?flex-preferred-size:auto and width:auto do something cool like you suggest is > interesting, and possibly more useful than having ?flex-preferred-size:auto override 'width' to become width:auto, which was > suggested in a recent thread. Possibly kind of confusing, though, not least because it then becomes *impossible* to just have > normal width:auto behaviour. Also, I'm not sure what the consequences would be for calculating the dimensions of replaced > elements. The "normal" width: auto behavior (I assume by normal you mean that of display: block elements) is either width: fill-available or width: fit-content, depending on the situation. No? ~fantasai
Received on Tuesday, 24 April 2012 18:24:17 UTC