Re: [css-flexbox] intrinsic size algorithm

On Fri, May 15, 2015 at 2:32 PM, Christian Biesinger
<cbiesinger@google.com> wrote:
> Hi fantasai,
>
> On Tue, May 12, 2015 at 1:47 PM, fantasai <fantasai.lists@inkedblade.net> wrote:
>> On 05/11/2015 12:14 AM, Christian Biesinger wrote:
>>> So Ojan and I were looking again at
>>> http://dev.w3.org/csswg/css-flexbox/#intrinsic-sizes
>>>
>>> What is the broader issue that this complex algorithm is trying to
>>> solve? In particular, why is it better than just summing up the flex
>>> bases (if definite) or the max-content contributions (otherwise)?
>>
>>
>> Its goal is to preserve the flex ratios. E.g. if you have (using Ahem)
>>
>> <flexbox>
>>   <item flex:1>A A</item>
>>   <item flex:2>B B</item>
>> </flexbox>
>>
>> and ask it to shrinkwrap, you probably want A to lay out at 3em
>> and B to lay out at 6em.
>
> Actually I would expect A and B both to lay out at 3em. But... I can
> see why that wouldn't happen with the current algorithm.
>
>> Without this rule, the boxes would lay out at 2em and 4em, respectively,
>> causing the text in A to wrap even though there is plenty of space to
>> lay out at its max-content size.
>
> Yeah, true, you'd need flex-basis: auto to get the more reasonable (?)
> result that they're both 3em.
>
> ...wait, hold on, why would that happen? The default flex basis is 0%,
> and since we do not have an explicit width for the flex box, that
> computes to auto. As a result, both A and B have a flex base size of
> 3em and no space is left to distribute. Right?

..right, except that widths are always definite, so 0% is in fact zero
here. OK, you're right.

-christian

Received on Friday, 15 May 2015 04:35:13 UTC