W3C home > Mailing lists > Public > www-style@w3.org > August 2011

[css3-flexbox] Nailing down the layout algorithm

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 26 Aug 2011 18:23:24 -0700
Message-ID: <CAAWBYDB8_XvrYKOrGU+mXB2BW9EpivT86JAPUGmO4hhn6cXBcg@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:43 GMT