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

hypothetical size of vertical flexbox WAS: [css3-flexbox] Nailing down the layout algorithm

From: Ojan Vafai <ojan@chromium.org>
Date: Fri, 9 Sep 2011 12:12:45 -0700
Message-ID: <CANMdWTtDaGpDPBYRuT4FbLhOxo9-EhbjV0y1EweSZ6Pa9Cu82w@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: "L. David Baron" <dbaron@dbaron.org>, Alex Mogilevsky <alexmog@microsoft.com>, Arron Eicholz <Arron.Eicholz@microsoft.com>, Tony Chang <tc@google.com>, www-style list <www-style@w3.org>
On Fri, Aug 26, 2011 at 6:23 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> 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.
>

Given the following:
<div style="display: flexbox; flex-flow: vertical-ttb;">...</div>

The flexbox does not have a specified height. Is the "real main size" here
the shrinkwrapped height before linebreaking? And the "hypothetical cross
size" is actually it's width based off it's parent element?

Basically, I think this algorithm treats vertical/horizontal flexing as
perfectly symmetrical, but it's not in the cases of determining the
width/height of the flexbox itself, right?

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 Friday, 9 September 2011 19:13:31 GMT

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