- From: Alex Mogilevsky <alexmog@microsoft.com>
- Date: Thu, 20 Oct 2011 05:55:32 +0000
- To: Tab Atkins Jr. <jackalmage@gmail.com>
- CC: Ojan Vafai <ojan@chromium.org>, "www-style@w3.org" <www-style@w3.org>
± ± ± -----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