Re: [css-flexbox] Fixing a mistake with flex-grow betwen 0 and 1

Hi Tab,

So, I've got a patch that implements the new resolving-flexible-lengths
algorithm pretty much directly from the spec text -- but, in sorting
through edge cases with float accumulation error & very large flex
values that I'd previously accommodated in my impl of the old algorithm,
I'm wondering whether it'd be better for me to just tweak my
implementation of the old algorithm instead of entirely replacing it.

Given that you opted to rewrite the algorithm in the spec completely
(rather than just tweaking it), I'm curious whether you think this is
doable/wise. I suspect it should be, based on this comment:

On 10/09/2013 10:59 AM, Tab Atkins Jr. wrote:
> This [new] algorithm should be identical to the current flexing algorithm
> when all the items have a flex of 1+, or when the non-violating items
> in the final cycle have a sum of flexes 1+.

Assuming that this comment still holds, am I correct in thinking that
the old algorithm could be tweaked to match the new algorithm simply by
making some simple modifications to old-step-5 ("Distribute free space
proportional to the flex factors")[1]? The following modifications in
particular:
 - If we're using flex-grow, and the sum of flex-grow factors is < 1,
then use the flex-grow factor directly.
 - If we're using flex-shrink, and the sum of flex-shrink factors is <
1, then renormalize the scaled flex shrink factors so that their total
is equal to the sum of [unscaled] flex-shrink factors, and use these
renormalized values directly.

(When I say to use a factor "directly", I mean "multiply that factor by
the available free space, and claim that much free space".)

Thanks!
~Daniel

[1] old algorithm is available e.g here:
http://www.w3.org/TR/2012/CR-css3-flexbox-20120918/#resolve-flexible-lengths

Received on Thursday, 17 April 2014 21:34:43 UTC