- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 26 Aug 2011 18:23:24 -0700
- To: "L. David Baron" <dbaron@dbaron.org>, Alex Mogilevsky <alexmog@microsoft.com>, Arron Eicholz <Arron.Eicholz@microsoft.com>, Ojan Vafai <ojan@google.com>, Tony Chang <tc@google.com>, www-style list <www-style@w3.org>
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
Received on Saturday, 27 August 2011 01:24:56 UTC