[css-display][css-inline] Block containers should never establish an inline formatting context

[Loirooriol]

It's confusing that a block container may contain non-block-level things. It's easy to forget that a block container may establish an inline formatting context (this caused #1228, is part of #1457, and in #1550 I even forgot about this just after mentioning it XD). The specs also seem somewhat contradictory about a block container containing only inline-level and establishing a BFC (#1553). It's strange that anonymous block boxes don't become a containing block for their descendants. And I think that whether an element establishes a formatting context of some kind or another or none shouldn't depend on the children. That's because the children may be altered by the parent formatting context (e.g. can be blockified or inlinified), so this kind of behavior does not seem much well-defined in general.

So I propose to do something similar to run-in layout for alll inline-level contents: say that each inline-level sequence is wrapped inside an anonymous box that establishes an inline formatting context.

That "inline-level sequence" could be defined as a maximal non-empty sequence of consecutive siblings starting with zero or more run-in boxes (and intervening white space) followed by zero or more text runs or non-run-in inline-level boxes. (By the way, why are different run-in sequences currently wrapped inside different block boxes? Merging them would simplify this "inline-level sequence" definition).

The anonymous box that establishes the IFC could be a block container. This would imply that only anonymous block containers can establish an IFC. Element-generated block containers would either establish a BFC or integrate the children (which would always be block-level, not inline-level) into the parent BFC. I think this change wouldn't break anything, and would address most issues I mentioned at the beginning, but not all.

Therefore, it might also be interesting to give another name to boxes that establish an IFC, e.g. "inline container". Or the box that establishes the IFC could even be the "root inline box" (but then it would become block-level, so it couldn't be used to explain the strut or other things, see #1551). This would be a bigger change, the new box should be defined somewhere (css-inline?) and other specs might need to be edited with the new terminology. But I think it's worth.

[tabatkins]

In 2278ea78bb4d82 we clarified that some boxes can generate two formatting contexts (blocks can generate BFC and IFC, ruby can generate RFC overlaying the IFC it's already participating in).

We don't think anything else actually needs to be done here. Let us know if we missed anything, tho.

[Loirooriol]

I think it would be simpler if IFC were always established by anonymous blocks, and a box could only establish a single FC. But OK, I think this may also work.

[Loirooriol]

I think there may be a problem in the block-inside-inline case. This depends on #1477, but the sane approach seems that the inline element generates a single inline box which is the parent of the block box.

So if you have <main><span>Lorem ipsum<div></div>Lorem ipsum</span></main>, you will get this box tree:

<main>: block box
  └ <span>: inline box
      └ <div>: block box

But in the fragment tree you want the <div> block to be a child of the <main> block. And thus <main> should not establish an IFC, and the <span> should be wrapped in an anonymous box. So it should really be

<main>: block box, BFC or no FC
  └ anonymous: block box, IFC root
     └ <span>: inline box, no FC
         └ <div>: block box, no FC

so that the fragment tree can end up as desired:

first&last fragment of <main>
  └ first fragment of anonymous
     └ first fragment of <span>
  └ first&last fragment of <div>
  └ last fragment of anonymous
     └ last fragment of <span>

To avoid this kinds of problems where you may end up needing an anonymous box, I would always generate it just in case.

[fantasai]

Tab linked to the wrong commit, should be 8bb4d82 I think.

@Loirooriol I think we need to figure out exactly how block-in-inline splits work in the theoretical world in the Flow Layout spec (which hasn't been written). Currently we're working with what's in CSS2.1 Chapter 9, though, and it only generates anonymous blocks when there's a mix of block-level and inline-level content in the same block container. So CSS Display Level 3 needs to be written to that understanding. We can refine the theoretical model later if need be, but for now we need to go with what we have--there's no observable behavioral difference, and given the differences in how implementations handle flow layout internally, there shouldn't be.

[Loirooriol]

@fantasai Yes, I would love a CSS Flow Layout spec because CSS2 is too outdated. But in the F2F it seemed people preferred to avoid this can of worms and only create a less ambitious CSS3 Floats spec.