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:
flowIf its outer display type is
inlineorrun-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:
overflow applies and is different than visibleRetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.3