Tab, I suspect that in your #2 you forgot the case when
flexbox children use min-width and max-width together with width:Nfx .
Line breaking algorithm shall compute first min-width and max-width values
of each element and do row break according them. There is also explicit row
break involved. In my case it is clear:left|right|before|after but I forgot
what we decided on explicit breaks. Explicit breaks are the must, IMO.
For the case when 'width' of flex child has flex value its
min/max-width values are calculated as:
min-width:
'auto' -> min_intrinsic_width or 0 (when overflow-x:auto|scroll)
length -> calculated_pixel_value.
max-width:
'auto' -> min-width
length -> max(min-width,calculated_pixel_value).
The max-width value is used for row break calculation (is it your
'main size'?).
When you will find elements in each row then flex distribution
algorithm uses following values:
min-width:
'auto' -> min_intrinsic_width or 0 (when overflow-x:auto|scroll)
length -> calculated_pixel_value.
max-width:
'auto' -> {unlimited}
length -> max(min-width,calculated_pixel_value).
to compute final distribution using flexes with min/max constrains.
(Note: Explicit breaks participate in intrinsic width calculation of
flex box container. In the same way as <br>s in text containers)
--
Andrew Fedoniouk
http://terrainformatica.com
-----Original Message-----
From: Tab Atkins Jr.
Sent: Friday, August 26, 2011 6:23 PM
To: L. David Baron ; Alex Mogilevsky ; Arron Eicholz ; Ojan Vafai ; Tony
Chang ; www-style list
Subject: [css3-flexbox] Nailing down the layout algorithm
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