RE: [css3-flexbox] resolving flexible lengths

± 
± 
± -----Original Message-----
± From: Tab Atkins Jr. [mailto:jackalmage@gmail.com] 
± Sent: Monday, October 17, 2011 11:25 PM
± To: Alex Mogilevsky
± Cc: Ojan Vafai; www-style@w3.org
± Subject: Re: [css3-flexbox] resolving flexible lengths
± 
± On Mon, Oct 17, 2011 at 10:33 PM, Alex Mogilevsky <alexmog@microsoft.com> wrote:
± > 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.
± 
± Ah, whoops.  My implementation does indeed adjust back downwards in that situation.  
± I didn't set up a complex enough test-case to realize that, because it would 
± definitely have been problematic.  The algorithm I wrote for the spec doesn't do 
± this, though.  It may be somewhat unclear in the algorithm sketch I gave above, but 
± it should unfold something like this:
± 
± a    b    c    (remainder)
± 0    0    0    240
± 60   120  60   0   // min(c) kicks in
± 0    0    120  120 // reset the algorithm, with c fixed
± 40   80   120  0
± 
± I've adjusted my js implementation to work properly here, and it does indeed give the 
± same results, and does the proper thing in your example (that is, it does what I just 
± said it should do):
± <http://xanthir.com/etc/flexplay/test.html>.

I like this much better. This way positive and negative flex will never mix in one result, and you achieve the goal of min-width to limit the final outcome, not distribution.

You only need to reset the algorithm when one or more items fail to satisfy minwidth, right? I don't think max-width has a similar problem, does it? 

In worst case this can require as many restarts as there are items (making the distribution N**2), but that kind of case would be really artificial...

alex

Received on Thursday, 20 October 2011 05:56:03 UTC