W3C home > Mailing lists > Public > www-style@w3.org > April 2014

Re: [css-flexbox] New "Resolving Flexible Lengths" algorithm disagrees w/ old algorithm, when we go from negative free space to positive free space (even with flexibilities >= 1)

From: Daniel Holbert <dholbert@mozilla.com>
Date: Thu, 24 Apr 2014 13:42:33 -0700
Message-ID: <53597739.9030600@mozilla.com>
To: www-style <www-style@w3.org>, "Tab Atkins Jr." <jackalmage@gmail.com>
On 04/22/2014 04:38 PM, Daniel Holbert wrote:
> To handle cases like this, I suspect we'd need to allow the algorithm to
> recompute the items' "originally desired free space" values during the
> loop, under some restricted conditions (including "when the free space
> changes sign").  Or something like that.

I think the best fix for this issue is probably to defer computing any
"originally desired free space" values until the first time that the
sign of our free space matches the flex-factor that we're using. (so, if
we're using flex-grow, we hold off on computing "originally desired free
space" values until we have a positive free space. Or if we're using
flex-shrink, we wait until the free space is negative.)

With a more concrete example -- say we have two flex items, one of which
has a huge flex-basis (larger than the container) but a small
"max-width". We'd:
 - pick "flex-grow" as our flex factor (because the flex items'
hypothetical (clamped) main sizes are smaller than the container)
 - Calculate free space and get a negative value (since one item has a
huge flex-basis.)
 - *PUNT* on computing "originally desired free space" values, since the
sign of our free space doesn't match the type of flexing we're doing.
 - Hand-wave our way through the loop (we know we shouldn't distribute
anything, since the sign of our free space doesn't match our type of
 - Fix our max-violation -- clamp the flex item with the max-width.
 - Restart loop, and when we recalculate free space, discover that it's
now *positive* (after our clamping).

I'd argue that the end of this process (the first time we have positive
free space) is a good time to initialize the "originally desired free
space" value on our remaining unfrozen flex items. At least, it's a
better time than what the spec currently does, since at this point we
actually have a free space value whose sign matches the type of flexing
that we're allowing ourselves to do.

(Note: In the original flex algorithm, this sort of corresponds to
establishing an "original free space" value the first time we actually
attempt to distribute free space, in Step 5. Reference:

Received on Thursday, 24 April 2014 20:43:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:51:23 UTC