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

On 24/04/2012 18:16, fantasai wrote:
> 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.

I believe it is specified:

   # The computed value for ‘display’ for elements that are flexbox
   # items must be determined by applying the table in CSS 2.1
   # Chapter 9.7.
(from Section 4).

A similar situation arises for column boxes in css3-multicol, although 
there the width calculation is explicit so it doesn't really matter 
whether we think of them as block-level boxes or not.  In reality, 
column boxes are display-outside:column and flex item boxes are 
display-outside:flex-item; but in practice we are just saying that 
they're display:block or (in the case of css3-flexbox) block-level 
replaced, since those display types don't exist yet and aren't really 
needed at the moment.  If those types were to come into play later, then 
I don't think it would be a big deal to suddenly say "actually, flex 
items and columns now have a new display-outside", because in any case 
those types would have to mimic the behaviour that flex items and 
columns are already specified to rely on.

However, if we /don't/ want to flex items to be block level, then we 
need to decide that right now, and define their auto width appropriately.

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

Indeed.  And I believe that fill-available becomes impossible under your 
proposal.

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

Received on Thursday, 26 April 2012 11:55:22 UTC