W3C home > Mailing lists > Public > www-style@w3.org > May 2015

Re: [css-flexbox] intrinsic size algorithm

From: Christian Biesinger <cbiesinger@google.com>
Date: Fri, 15 May 2015 14:32:35 +1000
Message-ID: <CAPTJ0XEmm09X4=QfQfk8oui5O7khxZMXwP90XBWYd1uHDuGiKg@mail.gmail.com>
Cc: www-style list <www-style@w3.org>
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?

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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:54 UTC