CSS Flexible Box Layout


Use Cases

Accessibility Order Implications

Implementation Report

TODO: list browser versions and draft versions for partial or complete implementations

Old/New Syntax Property Mapping

Open Issues

Flex Box Construction

  1. [RESOLVED] Is pre whitespace ignored or preserved between elements? http://www.w3.org/mid/4F6ACDF3.1030706@mozilla.com
  2. [OPEN] Magic of replaced 'display: inline' elements: http://www.w3.org/mid/4FA76E7E.60604@inkedblade.net
  3. [CLOSED] What are expected display-inside/display-outside values for flex items, and does currently-defined behavior result in a sensible model when they are defined to exist?
    • Proposal A: Stays in box tree, but has special layout: Do layout once normally, then collapse it to a strut of its line's cross size and lay out again. (This keeps the cross-size stable if the flexbox is single-line or a single line of multi-line.)
    • Proposal B: Stays in box tree, but removes all impact on layout, period. (Just like display:none, but still generates boxes, so animations/counters/etc are unaffected.)
    • Proposal C: ?

Flex Property

  1. [RESOLVED] Split flex as shorthand of flex-grow/flex-shrink/flex-basis
  2. [RESOLVED] Applicability of flex-basis: is it used or ignored for flex == 0?
  3. [RESOLVED] Default flexibility of flex items: flexible or inflexible? http://www.w3.org/mid/4F91E0D6.7040502@inkedblade.net
    • Note: This decision sets the initial values of flex-grow and flex-shrink, which conventionally also implies their default values in the flex shorthand.
  4. [RESOLVED] What is the computed value of 'flex-basis' when it is 'auto'? Is it auto or is it the used flex basis? http://www.w3.org/mid/4FA1C498.2040101@inkedblade.net

Flex/Main Sizing

  1. [RESOLVED] Negative Flex: use Alex's alternate formulation
  2. [RESOLVED] Turn negative flex on by default (now that negative flexing makes sense…)
    • This means that in a single-line flexbox, auto-sized flex items with long text will shrink so that they don't overflow the flexbox; instead, they become narrower and the text wraps. This seems like what we'd want.
    • Multi-line flexbox items still won't shrink unless they're wider than the flexbox.
  3. [RESOLVED] Implied min-content minimum size for flexbox items
    • Now that we have a reasonable negative flex by default, we should have a reasonable minimum main size to go with it.
    • Note: IE10 implies min-content as the minimum.
    • Note: Could introduce an initial value of 'auto' for 'min-content' to have this make more sense. This would compute to '0' wherever needed for back-compat.


  1. [RESOLVED] Propagating break-before/after to flex line instead of allowing items to break lines, but only in fragmenting contexts
  2. Allowing pull-up in addition to push-down in paging.
  3. [RESOLVED] Make paging algorithms informative: define multi-col nature of multi-line column pagination, and otherwise merely advise to minimize distortion.

Alignment and Cross-Sizing

  1. [RESOLVED] Single-line vs. multi-line differences in alignment and sizing?
  2. [CLOSED] Stretch doesn't allow shrinkage, is that what's wanted?
  3. [CLOSED] Get WG approval of 'auto' margin behavior (which is designed to match Grid atm)
  4. [CLOSED] 'distribute' behavior doesn't match use case that prompted it
  5. [CLOSED?] Define/resolve on alignment fallbacks for baseline, stretch, distribute, justify.
  6. [OPEN] True centering vs. safe centering

Terminology and Naming

  1. [RESOLVED] Rename 'display: flexbox' to 'display: flex'
  2. [RESOLVED] Rename “flexbox” to “flex container” and “flexbox item” to “flex item” or “flex box” to be consistent with CSS terminology elsewhere
  3. [OPEN] Rename 'flex-order' to 'box-order' or 'display-order', since it doesn't affect order of flexing, but order of boxes.
  4. [RESOLVED] Resolve nowrap vs. no-wrap for both Flexbox and CSS3 Text

Syntactic Alignment of Flex Item Alignment

These issues tie into the Box Alignment proposal. [1]

  1. 'distribute' vs. 'justify': unclear which is which. Also names should not be inconsistent with text / ruby-align, at the very least.
  2. Flex-flow-relative alignment: start/end/start/end vs. start/end/before/after https://www.w3.org/Bugs/Public/show_bug.cgi?id=16007
  3. Alignment property names are confusing to anyone who hasn't been working on Flexbox for months.
  4. [RESOLVED] Proposal for common alignment: if we're going there, how do we integrate with Flexbox without depending on its completion?

Resolved Issues

Issue 1

Multiline flexbox is missing from current draft

2009 spec had a multiline option http://www.w3.org/TR/2009/WD-css3-flexbox-20090723/#multiple which is not supported by current draft.

  flex-wrap: no-wrap | wrap | balance


  flex-lines: single | multiple
Status: Resolved:
  flex-wrap: no-wrap | wrap

('balance') is not included into the spec yet. Can keep it as an issue until there is a strong need for it.

Issue 2

flex-direction property doesn't extend to more values needed for multiline flexbox

Multiline flexbox needs at least 4 bits to choose from directional options (can be more to tie to writing mode, but not less):

  1. horizontal or vertical primary direction
  2. horizontal or vertical transverse direction
  3. single line or multiple lines
  4. horizontal or vertical line progression

Current draft combines orientation and direction in one property http://dev.w3.org/csswg/css3-flexbox/#flex-direction0, it works well for common cases but does not easily extent to multiline situation.

Some options for adding multiline are listed here: http://lists.w3.org/Archives/Public/www-style/2011Jun/0116.html - options 1 to 6
http://lists.w3.org/Archives/Public/www-style/2011Jun/0134.html – best proposal so far (from Fantasai)
Option 7:
  flex-orientation: rows | columns | horizontal | vertical
  flex-wrap: no-wrap | wrap | balance*
  flex-direction: [ forward | backward ] || reverse-stack

(this doesn't include “line-progression”)

Option 7 take II:

    flex-wrap: no-wrap | wrap | balance
    flex-flow: [ rows | columns | horizontal | vertical ] || [ reverse-line || reverse-wrap ]
               [ ltr | rtl | auto ] || [ ttb | btt | auto ]

    flex-flow: rows;                     /* forwards inline row (default) */
    flex-flow: horizontal;               /* forwards horizontal row */
    flex-flow: reverse-line;             /* backwards inline row */
    flex-flow: reverse-wrap;             /* reverse-stacking forwards inline rows */
    flex-flow: reverse-line vertical;    /* backwards vertical column */
    flex-flow: reverse-line columns;     /* backwards block-oriented column */

    flex-flow: ltr;                      /* horizontal ltr row, auto stacking */
    flex-flow: ltr auto;                 /* same thing */
    flex-flow: ttb;                      /* vertical ttb column, auto stacking */
    flex-flow: ltr ttb;                  /* horizontal ltr row, ttb stacking */
    flex-flow: auto ttb;                 /* horizontal auto row, ttb stacking */

Any missing directions are taken from the writing mode. Forwards for a particular dimension is matching the block or inline direction (whichever) is appropriate.


Option 7.3 (one property)

  flex-flow: [ rows | columns | horizontal | vertical ] || 
             [ normal | reverse | ltr | rtl | ttb | btt ] ||
             [ wrap | wrap-reverse | wrap-ltr | wrap-rtl | wrap-ttb | wrap-btt ]

Option 7.4

  flex-flow: [ rows | columns | horizontal | vertical ] || 
             [ normal | reverse | ltr | rtl | ttb | btt ] ||
             [ wrap | wrap-reverse | wrap-left | wrap-right | wrap-down| wrap-up ]

Option 8:

    [ row | row-reverse | column | column-reverse ] || [ wrap | wrap-reverse ] |

    [ horizontal | horizontal-reverse | horizontal-ltr| horizontal-rtl ] && 
    [ wrap| wrap-reverse | wrap-down| wrap-up ]? |

    [ vertical| vertical-reverse| vertical-ttb| vertical-btt ] && 
    [ wrap | wrap-reverse | wrap-left | wrap-right ]?

see spec

Issue 3

flexbox has two ways to align in transverse direction - confusing and still incomplete. Try to make it consistent with Grid and/or Table.

2009 spec had box-align property with values similar to vertical-align in table cells (start/end/center/stretch/baseline). Current spec adds alignment via auto margins and padding, however 'flex-align' property remains, just for baseline alignment. Having two ways to align, both incomplete, is inconsistent and confusing.

It may be OK, if margin-based alignment is more powerful, having two ways to align may be justified. At this point however, margin-based alignment (using “margin:auto”) doesn't provide any new ways of alignment that were not possible with flex-align property.

Historically, it was proposed that margins can have flex values, which

Alignment via margins doesn't really add new ways of alignment that were not possible before the change

Resolved at Seattle F2F to converge both flexbox and grid cell alignment to 2009 spec – auto margins work, if no auto margins before/after/stretch have effect
include text in flex-align definition that explains that auto margins are handled before 'flex-align' value is considered. Details can be in layout algorithm or elaborate description as in 2009 spec (http://www.w3.org/TR/2009/WD-css3-flexbox-20090723/#alignment) Action completed

Issue 4

consider 'true-center' as an align option for flexbox

'true-center' has been proposed many times and has dedicated supporters. Now that flexbox is adding a number of special layout rules and unique behavior, including new kinds of alignment, why not include true-center? There is no need to describe why it can be very useful.

Resolved: not in flexbox spec. consider for css3 box model

Issue 5

page breaking behavior needs to be defined for flexbox

flexbox spec says nothing about what happens when flexbox intersects page boundaries. it is reasonable to expect that flexbox is used at high level of page layout (as to positioning side-by-side content columns or headers/footnotes), then it is critical that pages using flexbox layout print reasonably.

Action Alex: propose

Issue 6

'inline-' display values work around limitations of 'display' property semantics. Separate properties for element placement and element content layout are long overdue.

From flexbox spec draft:

ISSUE: The proliferation of “inline-*” display values is untenable and restrictive. Table cells should be able to use the flexbox layout mode for their contents, for example, rather than being forced to use block layout. It's expected that this will be fixed by splitting the ‘display’ property into sub-properties controlling how the element formats its contents (‘display-inside’) and how it reacts to its surroundings (‘display-outside’). Once that occurs, this section will instead describe a single new ‘display-inside’ value that triggers flexbox layout.

this is a change for CSS3-BOX; need proposal, Tab: ACTION-342: define use cases that require 'display-inline'

Issue 7

Is 'float' property on flex items ignored or honored and wrapped into anonymous block?

Floats are also out-of-flow, but children of flexboxes can't float. Issue:(ISSUE: Should this restriction exist, or should I just wrap floats in the anonymous boxes like other inlines?)

Resolved: 'float' is ignored on flexbox items. ED updated.

Issue 8

would 'flex-order' be more intuitive if named 'flex-index'?

'flex-index' would be more consistent with 'z-index'

keep 'flex-order'.

Flexbox literally reorders its children for all purposes, naming is appropriate http://lists.w3.org/Archives/Public/www-style/2011Aug/0217.html


Issue 9

multiline flexbox needs properties to control line stacking direction and line pack

This applies to both 2009 and current specs: it is not defined in which direction lines are to be added.

It is reasonable to expect that default line progression matches current writing mode, but it should also allow explicit control.

Similarly, there should be a way to control how lines are distributed if there is more available space than needed, similarly to 'flex-pack'.

flex-line-progression: normal | reverse
flex-line-pack: before | after | middle | distribute
Resolved 'flex-line-pack' http://dev.w3.org/csswg/css3-flexbox/#flex-line-pack0

Issue 10

“flex item” definition needs precise rules on handling absolute-positioned children

<html><ins style=“background:yellow”>abspos elements leave behind a placeholder, which is then treated like a 0x0 inline element.</ins></html>

This is important for display types that wrap inappropriately-displayed items, like display:table or display:flexbox.

In other words, doing this:

<div display:flexbox>
  <div position:absolute>bar</div>

…should create a flexbox with three flexbox items - the 'foo' and 'baz' elements, and an anonymous block wrapping the placeholder for 'bar'.

not leave a placeholder, but only use the hypothetical block and hypothetical line to determine auto position.
Proposal 2
ignore position:absolute on flexbox children
Open. consider proposal 2; Alex is Ok with allowing empty anonymous item.
abspos elements leave behind placeholders and all that implies http://lists.w3.org/Archives/Public/www-style/2011Nov/0711.html

Issue 11

need exact definition for how anonymous flex items are created from inline content

Given the following markup:

<div display:flexbox>

…do you get 1 or 3 flexbox items? Whether you're operating on the box-tree or the element-tree changes the answer. In the element-tree, the algorithm sees a single inline child, and creates a single anonymous wrapper block. In the box-tree, the algorithm sees an anonymous block box, the <div>'s block box, then another anonymous block box, for a total of three items.

You can detect the difference again with flex-pack:justify.

Note that all browsers agree that table-fixup either operates on the element-tree (after pseudo-element creation) or on the box-tree before block-in-inline fixup (I can't figure out how to distinguish the two). Flexbox should be consistent.


anonymous flexbox items are created in element tree. A sequence of plain text and inline elements produces one anonymous flexbox item, regardless of what is contained within inline elements (including any anonymous blocks).

Resolved: one item, blocks nested into inline elements don't break anonymous flexbox items.

ED updated

Issue 12

consider 'stack' as flexbox direction
  flex-flow: stack;

Children replaced one on top another. Intrinsic dimensions of flex-flow: stack; container are equal to tallest/widest child dimensions.

Resolved: not appropriate for flexbox, due to alignment only applicable to one direction at a time. Grid layout behaves as stack when items don't specify rows/columns.

Issue 13

default values in flex() function should be the initial values

Current spec says: “If flex() function has a single value and it is a <length>, a <percentage>, or a valid keyword for 'width' or 'height', the preferred size is set to that value, the positive flexibility is set to 1, and the negative flexibility is set to 0.”

Omitted values should devault to initial values, and initial value for flex is zero. That and other rules for flex() should change to use initial values as defaults

Always use initial values as defaults in flex()

Default values in flex() function will be different from initial. It is more useful to have default flex of 1 than 0, and using flex() function makes it clear that flexibility is desired unless specified otherwise.

Issue 14

what is the meaning of 'before' and 'after' in 'flex-align'

2009 spec reversed alignment direction for reverse flexbox. that doesn't make sense.

wrap direction of multiline flexbox can be used as a clue for alignment direction, but there is no way to specify alignment direction without specifying wrap.

Option 1:
  • Multi-line flexbox: alignment direction is the wrap direction (e.g. with 'wrap-up', 'before' is down and 'after' is up
  • Single-line flexbox: alignmend direction is the direction of block flow in writing mode of the flexbox (e.g. in 'lr-tb', 'before' is up and 'after' is down

;Option 2

Option 1 plus a new set value for 'flex-flow' – [ align-up | align-right | align-left | align-down | align-before | align-after ]
alignment direction is wrap direction in multi-line flexbox and block flow direction in single-line flexbox (option 1)
Resolved as proposed, ED updated

Issue 15

Treatment of margins and paddings in flex algorithm (with flex 1 for 'auto') is incomplete: no flex() function, no min/max values. Would it make sense to allow flex() function on margins and paddings? And how about min/max?

I don't have really strong feelings about it, but it seems that flexible margins should either have full support of flexibility or not try to get a poor-man's version at all.

An idea: what if 'auto' margins on main axis were used after flex sizing and before Pack? Would it make sense? Would it help any of use cases?

Apply to 'width' and 'height' only
Resolved: as proposed

Issue 16

need a solid use case for treating “margin:auto” as “margin:flex(0px 1 0)” along main axis in flexbox
Remove flexible margins.
Resolved: as proposed

Issue 17

what is effective min width/height of a flex item with specified widht/height?

Normally there min-width is irrelevant when width is specified. However flex item can be smaller than specified size, due to negative flexing. Then the <length> specified in flex() function is “specified preferred width”, a concept that did exist in CSS2.1 (other than tables, sort of).

What should we do here? Treat content min width/height same as specified? With same priority? Or less priority than specified width/height?

Option 1
use content min-width when sizing to content, specified min-width otherwise; min-height only if spcified

“width:flex(auto); min-width:0” – treat as “min-width:min-content”

"width:flex(1000px); min-width:0" -- treat as "min-width:0"
"height:flex(<anything>); min-height:0" -- nothing special, min-height used only if specified
Option 2
use min-width only if specified

It is always possible to set “min-width:min-content”. However it is not the default, and default of “min-width:0” is actually a pretty bad default when shrinking needs to happen. In Tables, content min-width works as a low limit for column width, but we don't really want to fully recreate tables…

Option 3
min-width/min-height is consulted after flex distribution. if any item is smaller than min, it gets its min size and no flexibilithy, then flex distribution is restarted
Option 3; use of min-width vs min-content to be clarified
Resolved (TPAC2011): minimum width is just min-width: min-content is not an implied minimum http://krijnhoetmer.nl/irc-logs/css/20111031#l-1591 . (that means min-content is never taken into account in flex calculations, unless used explicitly, e.g. as “min-width:min-content”)

Issue 18

combination of margins and item-level flex-align is redundant and is not supporting common case where all items have same alignment.
two properties 'flex-align' and 'flex-item-align' Behavior of auto margins in cross direction is TBD. Options are (1) auto margions are set to zero or (2) auto margins behave as horizontal margins in normal flow (align or center)
Resolved, accepted proposal

Issue 19

flex() has issues that 'flex' property wouldn't have
  • flex() applies to 'width' and 'height' properties always, regardless of whether the element is a flexbox item.
  • because of being applied to broadly used properties, flex() has to have meaning when applied to non-flex-item. It can then be invalid or have a special meaning, neither seem ideal:
    • if flex() is invalid when not in flexbox, “width:100px; width:flex(1 100px)” means “width:auto” (because the last value wins in cascading, then gets ignored)
    • if flex() applies to anything as preferred size, “width:flex(1)” means “width:0”
  • in DOM, specified style has to show as flex(…); any script that read selement.style.width will be broken or will have to parse flex()
  • having to specify flex separately for width and height forces unnecessary duplication. E.g. if a flexbox is sometimes horizontal and sometimes vertical but flexibility is same, stylesheet may have something like “width:flex(1 auto); height:flex(1 auto)”, which will work but is confusing.
  • combining width/height and flexibility in one property makes it impossible to change them independently
  • it is unclear if animations and transitions will work flex()
separate 'flex' property
flex: <pos-flex> <neg-flex>?


flex: [ <pos-flex> <neg-flex>? ]? || <preferred-size>?

<preferred-size> can be defined to have default of 0 and 'auto' value can mean “use value of width or height property”

Resolved, accepted proposal.


Issue NEW



spec/css3-flexbox.txt · Last modified: 2015/01/07 08:32 by bojcampbell
Recent changes RSS feed Valid XHTML 1.0 Valid CSS Driven by DokuWiki