Re: [css-flexbox] Algorithm Update

On 05/06/2014 06:52 PM, fantasai wrote:
> Tab and I, at dholbert's request, put both variants of the flexbox
> algorithm

Thanks!

>   3. If you have a preference for one algorithm or one wording over the
>      other, tell us!

I prefer the CR version (the one focused on flex factors instead of
desired free space values), for several reasons.


1) The CR version had more time for bugs to be discovered & reported, so
it's more likely to be correct.


2) In the spirit of "don't fix what's not broken", it seems undesirable
to replace the long-standing algorithm with a new formulation, unless
there were a compelling reason to do so. (And indeed, it did originally
seem like there was a compelling reason -- to get the "percentage"
behavior for flex factors when their sum is less than 1 -- but that
behavior has now been ported to work properly in the long-standing CR
version, so it's not a compelling reason anymore.)


3) The CR version is likely closer to what browsers actually have
implemented, since their implementations were coded before the "LC
version" was conceptualized. As a result, a rewritten algorithm will:
 - invalidate comments & concepts in code that reference spec-language.
 - make it harder to audit existing code & verify that it matches the spec.
 - make it (a bit) harder to identify what's precisely wrong in the case
of a disagreements between an implementation-coded-to-the-CR-algorithm &
the spec.
(If there were a compelling reason for the change, then these annoyances
would of course be overwhelmed by that compelling reason. However, I
don't see such a reason currently.)


4) The LC version feels more complex.  In particular, it requires 2
groups of variables to be normalized (flex-shrink values and
desired-free-space values), and it requires 2 additional variables to be
maintained for each flex item (a "desired free space" and a "normalized
free space").


5) I have a few issues with the concept of "desired free space" in the
LC version:

 a) It's a part-weight, part-length chimera. It's primarily a length,
based on its name and on how it's eventually used. However, it's got the
flex factor directly multiplied in, which makes it more weight-flavored
& which can put it on an absurdly different order of magnitude from any
length that *actually* is in play on the page, particularly if the
author chooses to use large flex values like "flex-grow:1000" (which
they're totally free to do). For UAs with fixed-point (integer-backed)
lengths (like Gecko and Blink and I think WebKit), this makes it very
easy for a direct implementation of the algorithm to produce values that
overflow to the maximum representable length, even when in actual fact
there are no large lengths being rendered on the page. This problem can
be worked around, e.g. by using a non-fixed-point type to store this
particular length, but it's an unfortunate annoyance (and can introduce
type-conversion error) which isn't a problem in the CR formulation of
the algorithm.

 b) Its name, "desired free space", is wrong most of the time. If you
have 100px of free space and an item with "flex: 2", then that item's
"desired free space" will be 200px; but the item doesn't *actually* want
200px, it just wants 2 "shares of free space", however large we
determine a share to be.  The "desired free space" name is only really
accurate when the flex factors sum to less than 1; and that's a case
that we've explicitly assumed to be rare (which is why we were able to
change the behavior for that case recently).

So: I have a fairly-strong preference for the CR formulation.

Thanks,
~Daniel

Received on Wednesday, 7 May 2014 19:28:15 UTC