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

On 04/18/2014 02:54 PM, Daniel Holbert wrote:
> After some thought, I *think* the old algorithm can be changed to
> produce the same results as the new one if we simply insert a "step
> 4.5", as follows:
> 
>  # Step 4.5: Adjust Free Space
>  #   Compute the sum of the unfrozen flex items' flex factors.
>  #   If this sum is less than 1, then multiply the free space
>  #   by this sum (reducing the magnitude of the free space).
> 
> In other words: if our flex items have flex-grow values that sum up to
> 0.5, then this makes us only distribute 50% of the free space.

Ah, it's of course not quite as simple as I thought.

I've realized that my suggested old-algorithm-tweak doesn't quite match
the New Algorithm in cases with max-violations. (but I think it's fixable)

e.g. if we have 100px of free space, and two flex items with
  item1: "flex: 0.2"
  item2: "flex: 0.5; max-width: 10px"
(triggering max-violation clamping for item2), then Tab's new
Algorithm would give 20px to the first item (which makes sense),
whereas the tweaked Old Algorithm (with step 4.5, quoted above) would
only give 18px to the first item. This happens because we recompute the
free space as being smaller (90px instead of 100px) on the second time
through the loop, and then multiply 0.2 * 90px = 18px as being the space
that we have for distribution when we determine the final size for that
first item.

HOWEVER, I suspect I can fix my "Step 4.5" spec-text to avoid this issue
-- something like the following:

   # Step 4.5: Adjust Free Space
   #   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 sign matches
   #   the free space's sign, and product's absolute value is less
   #   than the free space's absolute value, then set the free space
   #   to this product.

(where "original free space" is the free space that's computed on the
first time through the loop.)

(The product that's computed here is basically the unfrozen items' total
desired portion of the *original* free space. The idea is just to make
sure we don't let them flex any more than that amount. The new algorithm
does something similar.)

I'm not 100% sure that this is complete, and I'm not suggesting making
any spec modifications at this point. Mostly just posting to amend my
earlier post.

~Daniel

Received on Tuesday, 22 April 2014 02:58:31 UTC