Bugzilla – Bug 16483
Clarify why blocks inside of an inline [do|do not] get their own flexbox item
Last modified: 2012-04-17 17:22:14 UTC
(I just mailed the list about this:
but afterwards I realized it might've been better to file a bug, so I'm doing that as well. Apologies if this is overkill. :))
I believe the flexbox spec is currently inconsistent / unclear on handling
of situations with a block inside an inline, like "anonymous item 7.1" in
That example looks like this:
The prose at the bottom of the example say that not-an-item7.3 doesn't
form its own flexbox item, because it's contained inside an inline
element. (technically, the prose says not-an-item6.3 right now, but
that's a typo, which I emailed about separately)
However -- I think that prose disagrees with the normative spec text about
what makes a flexbox item: "boxes that satisfy one of the following
criteria... 1. Immediate block-level children of flexbox").
Note that the normative text refers to _boxes_ there, not _elements_. And
in the example above, the _box_ for "not-an-item7.3" IS an immediate child
of the flexbox, even if its element is not.
This is according to the inline/block interaction rules in CSS 2.1 section
"When an inline box contains an in-flow block-level box, the inline box
...[is] broken around the block-level box... The line boxes before the
break and after the break are enclosed in anonymous block boxes, and the
block-level box becomes a sibling of those anonymous boxes
In other words: if we follow CSS2.1 on how blocks behave inside of an
inline, then the box for "not-an-item7.3" becomes an immediate child of
the flexbox, which means the Flexbox spec says it should get its own
flexbox item, contrary to what the example says.
I think this needs clarification in the flexbox spec. Maybe we need to
use the element hierarchy instead of the box hierarchy for determining
flexbox item eligibility? I'm not sure if that makes sense.