- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 17 Oct 2011 23:25:05 -0700
- To: Alex Mogilevsky <alexmog@microsoft.com>
- Cc: Ojan Vafai <ojan@chromium.org>, "www-style@w3.org" <www-style@w3.org>
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>. ~TJ
Received on Tuesday, 18 October 2011 06:25:57 UTC