'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.
;Proposal :
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).
;Status : Resolved: one item, blocks nested into inline elements don't break anonymous flexbox items.
**ED updated**
==== Issue 12 ====
;URL : http://lists.w3.org/Archives/Public/www-style/2011Jul/0430.html
;Summary : consider 'stack' as flexbox direction
;Proposal :
flex-flow: stack;
Children replaced one on top another. Intrinsic dimensions of
flex-flow: stack; container are equal to tallest/widest child dimensions.
;Status : 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 ====
;URL : http://dev.w3.org/csswg/css3-flexbox/#flex-function
;Summary : default values in flex() function should be the initial values
Current spec says: "If flex() function has a single value and it is a
, a , 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
;Proposal : Always use initial values as defaults in flex()
;Status : Resolved
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 ====
;URL : //todo//
;Summary : 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 ]
;Proposal : alignment direction is wrap direction in multi-line flexbox and block flow direction in single-line flexbox (option 1)
;Status : Resolved as proposed, ED updated
==== Issue 15 ====
;URL : //todo//
;Summary : 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?
;Proposal : Apply to 'width' and 'height' only
;Status : Resolved: as proposed
==== Issue 16 ====
;URL : //todo//
;Summary : need a solid use case for treating "margin:auto" as "margin:flex(0px 1 0)" along main axis in flexbox
;Proposal : Remove flexible margins.
;Status : Resolved: as proposed
==== Issue 17 ====
;URL : //todo//
;Summary : 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 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(); 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
;Proposal : Option 3; use of min-width vs min-content to be clarified
;Status : 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 ====
;URL : http://lists.w3.org/Archives/Public/www-style/2011Dec/thread.html#msg97
;Summary : combination of margins and item-level flex-align is redundant and is not supporting common case where all items have same alignment.
;Proposal : 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)
;Status : Resolved, accepted proposal
==== Issue 19 ====
;URL : http://lists.w3.org/Archives/Public/www-style/2011Nov/0729.html
;Summary : 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()
;Proposal : separate 'flex' property
flex: ?
or
flex: [ ? ]? || ?
can be defined to have default of 0 and 'auto' value can mean "use value of width or height property"
;Status : Resolved, accepted proposal.