In the current WD of Flexbox, there's a (somewhat
incomplete/incorrect) exact layout algorithm for flexbox. I attempted
to eliminate the need for this, and just describe the layout algorithm
property-by-property, but it turns out that things are too
interconnected to make that a sane approach.
So, I need to rewrite the layout algorithm to address the spec changes
and fix the previous mistakes and holes. Here's my first draft of an
outline of the algorithm:
1. Reorder flexbox items according to ‘flex-order’.
2. Find the "hypothetical size" of every flexbox item
by treating them like a normal element of their display
type and the flexbox like a display:block element, and
both the flexbox and the item establish BFCs. Resolve
flexible widths/heights by treating them like their
preferred size. Resolve ‘auto’ widths/heights by
shrinkwrapping them.
3. Based on the hypothetical sizes of the items, find the
real main size of the flexbox and the hypothetical
cross size.
4. Based on both of these, linebreak the flexbox if it's
multiline. (Or does the possibility of linebreaking
affect the main size of the flexbox, in a shrinkwrapping
way?)
5. Resolve any flexible lengths. All items now have a real
main size.
6. Align in the main axis, per ‘flex-pack’.
7. Based on ‘flex-align’, find the real cross size of the
flexbox, its lines, and the items.
8. Align in the cross axis, per ‘flex-align’.
9. Align the lines, per ‘flex-line-pack’.
Note that if any "hypothetical" size is a definite length or
percentage, it's actually a real size immediately and won't change
(well, aside from flexing). The hypothetical calculations are meant
to give intermediate results in the presence of ''auto'' values (and
others?).
Does this look correct? Anything obviously wrong? Can any of this be
simplified? Remember that the algorithm needs to intelligently deal
with arbitrary writing modes on the flexbox and flexbox items,
combined with an arbitrary direction for the flexbox. I'm hoping that
step 2/3 is sufficient to address all the combinations.
~TJ