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 00:50:35 +0000
To: Tab Atkins Jr. <jackalmage@gmail.com>, Ojan Vafai <ojan@chromium.org>
CC: "www-style@w3.org" <www-style@w3.org>
Message-ID: <D51C9E849DDD0D4EA38C2E5398569284122C286D@TK5EX14MBXC218.redmond.corp.microsoft.com>
Your sequence of flex distribution and min/max constraints is different from what is currently interoperable across 3 implementations. I am not sure you realize that, I didn't until I played with your JS and with a css test that works in current browsers (attached).

You want to do first round of space distribution disregarding min/max. It may happen to fit, then min/max don't constrain preferred sizes.

Current implementations apply minmax to preferred size, then again after space distribution. It comes out naturally because

	* first, we calculate shrink-to-fit size using shared code, which takes into account all applicable box properties, including min/max
	* second, we distribute space according to flex. Each item gets its fair share, but not to exceed its min/max. 
	* once an item hits min or max, it loses flexibility.
	* distribute again while there is more to distribute and there are flexible items.

Note that this converges very reliably, because when pre-flex sizes are constrained they can either only grow or only shrink from there.

Now, is there a reason that you want to use unconstrained preferred size? I vaguely recall discussing that, it kinda made sense, but is it desirable enough to be incompatible with what is implemented and seems to work?


-----Original Message-----
From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of Tab Atkins Jr.
Sent: Sunday, October 16, 2011 11:31 PM
To: Ojan Vafai
Cc: www-style@w3.org
Subject: Re: [css3-flexbox] resolving flexible lengths

On Sun, Oct 16, 2011 at 6:07 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> In other words, doing either first is bad.  I'm trying to figure out 
> how to explicitly phrase the "correct" way to do this, so you always 
> find a space-filling and non-overflowing situation when one exists.

Got it, I think.  At least, it works now in my JS impl of the algorithm.

Basically, it goes like this:

1. Set the initial set of max and min violators both to empty sets.
2. Fix any max constraint violations, if they exist.
3. Fix any min constraint violations, if they exist.
4. If the old set of min violators is different from the ones that were just fixed, re-fix the max violations (holding the min violations steady, return the old max violations to flexibility and rerun the
distribution+detection+fixing algorithm).
5. If the old set of max violators is different from the ones that were just fixed, re-fix the min violations (ditto, appropriately altered).
6. Cycle between 3 and 4 until neither of them produce any new fixes.

Attached is the file with my JS impl, if my summarized algorithm above was unclear.  (Note that the JS impl doesn't check for invalid data.
Alter at your own risk.)

This is, unfortunately, a "cycle until a steady state is reached" sort of situation, but the state is very minimal and doesn't require any sort of layout to compute.

~TJ

Received on Tuesday, 18 October 2011 00:51:05 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:45 GMT