W3C home > Mailing lists > Public > www-style@w3.org > October 2011

RE: [css3-flexbox] resolving flexible lengths

From: Alex Mogilevsky <alexmog@microsoft.com>
Date: Tue, 18 Oct 2011 05:33:18 +0000
To: Tab Atkins Jr. <jackalmage@gmail.com>
CC: Ojan Vafai <ojan@chromium.org>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <D51C9E849DDD0D4EA38C2E5398569284122C2B82@TK5EX14MBXC218.redmond.corp.microsoft.com>
± From: Tab Atkins Jr. [mailto:jackalmage@gmail.com] 
± Sent: Monday, October 17, 2011 9:16 PM
± The main reason I was interested in separating min/max from preferred size 
± was to allow for effects like:
± <style>
± .navbar { display: flexbox; }
± .navbar > * {
±   width: flex(1);
±   min-width: min-content;
± }
± </style>
± <ul class=navbar>
±   <li>Our Store</li>
±   <li>Ask For Help</li>
±   <li>Accomodations</li>
± </ul>
± ...where the items are all the same size, unless they run out of space, but 
± they'll overflow the flexbox rather than shrink too small to be seen.  If 
± you adjust the preferred width based on min-width, then the last item will 
± be roughly 4em larger than the other two, because of its larger min-width.
± You can hack around this, of course, though it's somewhat unintuitive:
± .navbar > * {
±   width: flex(0 1 100%);
±   min-width: min-content;
± }
± Here, you force the items to start from the same very large width, and then 
± they all shrink evenly to fit the available space.  You get the effect I 
± wanted, but with some side-effects.  The shrinkwrap calculations are now 
± somewhat screwed up, for example - they make the flexbox think that its 
± contents want to be 300% of its width in total.
± Basically, paying attention to min-width early makes it somewhat difficult 
± to get the standard "make everything equal" effect while maintaining some 
± degree of safety, which was one of the problems with Firefox's original 
± Flexbox impl (when it defaulted to taking the shrinkwrap width as the 
± preferred width).
± I recognize, though, that adjusting the preferred width based on min/max-
± width does make the resolution algorithm stabilize faster in degenerate 
± cases.  In free space situations, it means you *only* have to pay attention 
± to max-width when allocating free space, and in overflow situations you 
± only have to pay attention to min-width.

I agree with the idea, it's a good use case. The way you describe it however actually matches your second solution -- "all the same size unless they run out of space" implies that they divide space equally, then if needed shrink, but no more than to minwidth. Using negative flex seems appropriate.

I think there is another inconsistency in applying minwidth in the middle of calculations. 

When one round of calculations ignores minwidth, then subsequent rounds take some of them into account, you get calculations with different bases, or in other words some items get absolute flex while others get relative, and result is difficult to predict.

Consider this:

    #fbox { width:200px; }
    #a    { width:flex(1 1); }
    #b    { width:flex(2 1); }
    #c    { width:flex(1 1); 
            min-width:120px; }

you would expect that B will be at most twice as big as A, won't you? But distribution will go like this:

    a   b   c   (remainder)
    0   0   0   240
    60  120 60  0    -- min(c) kicks in
    60  120 120 -60  -- now negative flex is used
    30  90  120 0

In the end B gets to be 3 times bigger than A, which it never asked for.

I think an algorithm where both positive and negative flex have effect in same layout is asking for trouble. I prefer the situation where everybody gets a starting point, whatever it might be, then either grows or shrinks. 


Received on Tuesday, 18 October 2011 05:33:48 UTC

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