You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A block container box either contains only block-level boxes or establishes an inline formatting context and thus contains only inline-level boxes. [...]
Floats, absolutely positioned elements, block containers [...] that are not block boxes, and block boxes with 'overflow' other than 'visible' [...] establish new block formatting contexts for their contents.
It's not clear what should happen when a block container contains only inline-level boxes and establishes a BFC because of e.g. overflow: hidden. From the quotes it seems like it simultaneously establishes both an inline formatting context and a block formatting context, but this would be weird. I think what should happen is that the block container establishes a BFC, and the inline-level contents are wrapped inside an anonymous block box that establishes an inline formatting context. That is, behave like if the block container contained some block-level box.
In CSS Display this is still not clear, the glossary says
A block container that contains only inline-level content establishes a new inline formatting context. [...]
A block container that contains only block-level boxes establishes a new block formatting context if its parent formatting context is not a block formatting context; otherwise, when participating in a block formatting context itself, it either establishes a new block formatting context for its contents or continues the one in which it participates
This would imply that a block container which contains only inline-level content never establishes a block formatting context. This would be bad.
The text was updated successfully, but these errors were encountered:
We've updated the spec to talk about how a block container that establishes an inline formatting context also continues (or establishes, if necessary) the block formatting context. (This is similar to how a ruby container both continues the inline formatting context and also establishes a new ruby context.) See changes at 8bb4d82
Is this observably different from the suggestion that the block container establishes a BFC, and the inline-level contents are wrapped inside an anonymous block box that establishes an inline formatting context? That way of describing it seem much more intuitive to me, assuming it actually does the same thing.
@frivoal I think an anonymous block may be necessary for #1477. Even if the block container seems to only contain inline boxes, some of these may contain a block-level. And then an anonymous box will be needed in the fragment tree where the inline box will be split by the block-level. In fact, I think element-generated block containers should never establish an inline formatting context, these should only be established by anonymous block containers automatically generated around each inline-level sequence.
CSS 2.1 says
It's not clear what should happen when a block container contains only inline-level boxes and establishes a BFC because of e.g.
overflow: hidden
. From the quotes it seems like it simultaneously establishes both an inline formatting context and a block formatting context, but this would be weird. I think what should happen is that the block container establishes a BFC, and the inline-level contents are wrapped inside an anonymous block box that establishes an inline formatting context. That is, behave like if the block container contained some block-level box.In CSS Display this is still not clear, the glossary says
This would imply that a block container which contains only inline-level content never establishes a block formatting context. This would be bad.
The text was updated successfully, but these errors were encountered: