Re: [css3-flexbox] resolving flexible lengths

On Mon, Oct 17, 2011 at 5:50 PM, Alex Mogilevsky <alexmog@microsoft.com> wrote:
> 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?

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.

~TJ

Received on Tuesday, 18 October 2011 04:16:40 UTC