Re: [css-flexbox] Tweaking the old "resolving flexible lengths" algorithm to produce same behavior as new algorithm

On 04/24/2014 02:12 PM, Daniel Holbert wrote:
> My suggested tweak now is now entirely contained in Step 5 of the old
> algorithm. Here it is, in context:
>    # Step 5:
>    # If the sign of the free space is positive and the
>    # algorithm is using the flex grow factor, or if the
>    # sign of the free space is negative and the
>    # algorithm is using the flex shrink factor:
>    #
>  [BEGIN INSERTION:]
>    #  a) If the "original free space" has not yet been
>    #     initialized, then set it to the free space.
>    #
>    #  b) Compute the sum of the unfrozen flex items'
>    #     flex factors. If this sum is less than 1,
>    #     compute the product of this sum and the
>    #     "original free space". If this product's
>    #     absolute value is less than the free space's
>    #     absolute value, then set the free space to
>    #     this product.

One more tweak to what I've got here -- I think we might need to allow
the "original free space" to be updated, to increase in magnitude, after
we've frozen flex items for violations. Otherwise, we still have
discontinuities.

Specifically, say we have two flex items whose flex-basis values
*nearly* fill the total available space -- so, there's a very small
amount of "original free space". The first item has "flex-grow: 0.99",
and the second has "flex: none; max-width: 0px".

In this case, since the flex sum is < 1, my suggested tweak above would
give the first item a tiny amount of free space (99% of the teensy
'original free space'), even though there's a ton of space that becomes
available after we clamp the other item. And if we bump up the first
item's flex-grow value to 1.00, then all of a sudden, this item will
absorb *all* of the post-clamping free space. (since we don't care about
"original free space" anymore).  That's the discontinuity that I want to
avoid...

If we allow "original free space" to increase after clamping has been
done, then that avoids this discontinuity, at least in this situation...

(I believe this discontinuity affects the entirely-rewritten algorithm
in the current spec, too; if we do keep that version of the algorithm,
we should probably address this there.)

~Daniel

Received on Tuesday, 6 May 2014 19:08:09 UTC