- From: Daniel Holbert <dholbert@mozilla.com>
- Date: Tue, 06 May 2014 12:07:41 -0700
- To: www-style list <www-style@w3.org>, "Tab Atkins Jr." <jackalmage@gmail.com>
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