Re: [css-flexbox] intrinsic size algorithm

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?

-christian

Received on Friday, 15 May 2015 04:33:03 UTC