RE: [css3-flexbox] Updates to Resolving Flexible Sizes

From: fantasai [mailto:fantasai.lists@inkedblade.net] 
Sent: Tuesday, April 24, 2012 6:26 PM
± 
± Tab and I have been working through the flexbox algorithm this week.
± We're not quite done double-checking our work on the main algorithm, but the 
± Resolving Flexible Sizes section has gotten an editorial overhaul, and we've fixed 
± some errors in it as well. I'm writing this email to ask Alex, dholbert, Ojan, and 
± anyone else interested for a review.
± 
±    http://dev.w3.org/csswg/css3-flexbox/#resolve-flexible-lengths
± 
± The changes were primarily editorial, except for the the last step:
± 
±    1. Fixed error in freezing of violations: min and max had been swapped.

Agree

±    2. Clarified which items are reset and which remain frozen.
±       Right now if you hit the 'zero' clause, freezing is cumulative
±       across iterations; for 'positive' only min violations are frozen,
±       and for 'negative' only max violations are frozen.

This is only necessary if the algorithm continues after hitting 'zero'. Not sure how it's possible (see next point).

± 
±    3. The zero clause only exits if the free space is also zero.
±       Previously you could exit with undistributed free space.

How could that happen? At step 3 of the algorithm, we've distributed all available space, total item size must be equal to total available space.

Then at step 4 we've fixed min/max and added up deltas from that. If the total change from fixing min/max is zero, it means total size has not changed, which means it is still equal to available space...

What am I not getting here?

I suppose that can happen when there are no flexible items, but the algorithm should just check that in step 1 and exit (which it doesn't).

±    4. Loop begins with determining the sign of the flexibility again.
±       This is necessary if freezing violations flips the sign of the
±       free space.

I think it is a good change, but then the sizes being added up shouldn't get clamped with min/max. With clamping it will always get the same sign, but I don't think it is what you want.

We came up with the first step for flexibility sign because we were not sure that alternating flexibility will always converge. It was easier to see that it will converge if the sign never changes. But I don't think that fear was justified.

You seem to be OK with alternating sign too, then the sign should be calculated based on current iteration.

A way to prove that the algorithm converges, without guessing flex direction up-front:
* Each additional iteration is invoked only after one or more items lose flexibility
* When there is no flexible items left, the algorithm will exit
(for this proof to be true, 'zero' clause has to either always exit or only proceed if it managed to freeze something)

In step 3, the condition "If the sign of the free space matches the sign of the flexibility," also seems unnecessary. It matches the approach of defining flex sign once per algorithm, but then if flex sign can change within the algorithm, it should be ok that it has effect...

Alex

Received on Wednesday, 25 April 2012 14:36:27 UTC