- From: Andrew Fedoniouk <andrew.fedoniouk@live.com>
- Date: Fri, 26 Aug 2011 20:58:56 -0700
- To: "Tab Atkins Jr." <jackalmage@gmail.com>, "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>
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
Received on Saturday, 27 August 2011 04:00:18 UTC