Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-display] Block container containing only inline-level and establishing a BFC #1553

Closed
Loirooriol opened this issue Jun 22, 2017 · 3 comments

Comments

@Loirooriol
Copy link
Contributor

CSS 2.1 says

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.

@fantasai
Copy link
Collaborator

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

@frivoal
Copy link
Collaborator

frivoal commented Mar 22, 2018

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.

@Loirooriol
Copy link
Contributor Author

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants