Re: [css3-flexbox] resolving flexible lengths

On Thu, Sep 29, 2011 at 8:39 PM, Ojan Vafai <ojan@chromium.org> wrote:
> There are a couple issues with
> the http://dev.w3.org/csswg/css3-flexbox/#resolving-flexible-lengths step.
> 1. It's not clear that the preferred size ignores min/max constraints. I
> think the spec should explicitly state that it ignores min/max constraints
> unless the preferred size is set to auto, in which case it takes them into
> account.
> The use-case this allows is the following:
> <div style="display: flexbox; width: 200px">
>     <div style="width: flex(1); min-width: 100px;"></div>
>     <div style="width: flex(3);"></div>
> </div>
> Clearly you would expect the first flex item to be 100px wide and the second
> to be 300px. If the preferred width took min-width into account you would
> instead get 125px and 75px.

I assume you mean that we would expect both of them to be 100px wide, right?

1. They both start at 0px (their preferred size).
2. They are set to 50px and 150px, respectively.
3. The first is reset to 100px and is now non-flexible.  Restart the algorithm.
4. The second is the only flexible box, so it gets all of the free
space and is set to 100px.

I do need to be clear about when min/max is taken into account, and
when it's *not*.


> 2. It should be a requirement that flex items with a positive flex fill the
> flexbox if possible given min/max constraints. Specifically, the currently
> specced algorithm does the wrong thing in this case:
> <div style="display: flexbox; width: 200px">
>     <div style="width: flex(1 0 50px); min-width: 100px;"></div>
>     <div style="width: flex(1 0 100px); max-width: 50px;"></div>
> </div>
> The first flex-item should have a width of 150, but instead it currently
> gets a width of 100. Talking to Tab offline he suggested the following
> solution:
> "Looks like the fix is to separate them into different steps, with either
> one having the ability to restart the algorithm.  If there is
> positive free space, resolve max first; if there is negative free space,
> resolve min first."
>
> Seems fine to me.

I've made this change.  It's in a non-normative section right now, but
it'll move to the normative layout algorithm when I flesh that out,
which I will do soon.


> 3. Finally, it's not clear to me whether this algorithm is stable.
> Specifically, I believe it matters what order you iterate through the flex
> items. If it does, then the spec should clearly state the order it uses. The
> options I see are layout order and document order. I think the former is
> probably more intuitive, although I believe layout order would need to take
> direction (and writing-mode?) into account in addition to flex-flow and
> flex-order.

It shouldn't have any ordering constraints - all the elements that are
in violation of one of their constraints should fix themselves at the
same time, before trying to distribute space again.

Even if they were done one-by-one, once the previous fix is made to
split min/max resolution into two steps, it should be
order-independent.  If there's free space, fixing things in violation
of max-size constraints will only mean there's *more* free space to go
around for the rest, which ensures that all other elements which
*were* in violation will continue to be (and you may put more in
violation).  Similarly for an overflow situation and min-size
constraints.

~TJ

Received on Friday, 30 September 2011 16:22:11 UTC