The flow inner display type is completely overloaded, it can generate 4 (!!!) different kinds of boxes: inline box, block container that establishes inline FC, block container that integrates into the parent BFC, or block container that establishes BFC.
So I propose that flow never establishes a BFC. Instead, all cases which require a BFC are handled by switching the inner display type to flow-root at used value time via becoming a formatting context. This would disentangle flow and flow-root. This change should have no effect in practice.
Something like this:
flow
If its outer display type is inline or run-in, and it is participating in a block or inline formatting context, then it generates an inline box.
Otherwise it generates a block container box and integrates its contents into its parent block formatting context.
Note: certain circumstances, such as if the block container does not participate in a block formatting context, require the element to become a formatting context, and thus its inner display type is changed to flow-root.
And in Becoming a formatting context list these triggers:
- Block containers that are not block boxes
- Out-of-flow
overflow applies and is different than visible
- The root element
The
flowinner display type is completely overloaded, it can generate 4 (!!!) different kinds of boxes: inline box, block container that establishes inline FC, block container that integrates into the parent BFC, or block container that establishes BFC.So I propose that
flownever establishes a BFC. Instead, all cases which require a BFC are handled by switching the inner display type toflow-rootat used value time via becoming a formatting context. This would disentangleflowandflow-root. This change should have no effect in practice.Something like this:
And in Becoming a formatting context list these triggers:
overflowapplies and is different than visible