- From: Christian Biesinger <cbiesinger@google.com>
- Date: Fri, 15 May 2015 14:32:35 +1000
- 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? -christian
Received on Friday, 15 May 2015 04:33:03 UTC