[css-display] 'flow' inner display type should never establish a BFC

[Loirooriol]

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

[Loirooriol]

Despite mentioning that a block container can establish an inline formatting context, in the proposed text I forgot about that 😆. Anyways, I think this possibility should also be removed (at least for element-generated block containers), see #1617.

[tabatkins]

block container that establishes inline FC, block container that integrates into the parent BFC

I don't see the difference between these two.

inline box

Yup, inline box vs block box is the result of crossing {block, inline}x{flow}. That's fine.

block container that establishes BFC.

We resolved that this makes sense to set at used value; making things establish a formatting context will now resolve "block flow" to "block flow-root" at used-value time.

We're currently keeping "what happens if you make 'inline flow', 'inline ruby', or 'block ruby' establish formatting contexts?" undefined; we'll figure it out what 'contain' does on these elements separately.

[Loirooriol]

I don't see the difference between these two.

• block container that establishes inline FC

  This box establishes an inline formatting context. Its contents are all inline-level and participate in that inline formatting context.

• block container that integrates into the parent BFC

  This box establishes no formatting context. Its contents are all block-level and participate in the parent block formatting context.

[tabatkins]

We don't make a real distinction between "filled only with inline content" and "filled only with block content". That's all flow layout.

[fantasai]

Checked in edits to define that “a block container that establishes a new block formatting context is considered to have a used display value of flow-root.” This should be a purely editorial change.

@Loirooriol Let me know if that seems acceptable.
Agenda+ to double-check with the WG that this doesn't break anything. :)

[Loirooriol]

It's acceptable, but in fact I no longer have a strong opinion about this. I wanted the flow inner display type to never establish a BFC, and explain the cases in which a BFC is needed by saying that the used display value of the generating element has been changed to flow-root.

But this does not work well for display: block ruby, because the principal box may need a BFC due to e.g. overflow: hidden. I wanted to address this with a new ruby-root inner display type (#1700), which was rejected. This means that the establishment of a BFC can't be explained (not exclusively, at least) in terms of the element's display type.

Then, I don't mind noting that if an element with flow inner display type generates a block container that establishes a BFC, the result looks like if the element had a flow-root inner display type. But this doesn't seem to simplify things, which is what I initially wanted.

[Loirooriol]

Wait, it's not correctly written. It seems to imply that, if you have display: list-item; float: left, display: list-item will behave like display: flow-root, losing the marker.

I think it should say "is considered to have a flow-root inner display type at used-value time".

[fantasai]

@Loirooriol Fixed, thanks. :)

[css-meeting-bot]

The Working Group just discussed 'flow' inner display type should never establish a BFC, and agreed to the following:

• RESOLVED: Accept proposal in https://github.com/w3c/csswg-drafts/issues/1550#issuecomment-387160020

The full IRC log of that discussion

<dael> Topic: 'flow' inner display type should never establish a BFC
<dael> github: https://github.com//issues/1550
<fantasai> https://github.com//issues/1550#issuecomment-387160020
<Rossen> chris, thx :)
<dael> fantasai: Comment ^
<dael> fantasai: We made an edit [reads]
<dael> fantasai: We believe this is editorial and we wanted to flag the WG to confirm it's editorial
<dael> [everyone reads]
<dbaron> I think this may be hard to know until somebody tries implementing this...
<dael> Rossen: You're saying a block container establishing a new fc inner display is flow root
<dael> fantasai: Used inner display of flow root
<dael> Rossen: Unless multicol?
<dael> fantasai: I don't htink we have a display type for multi col. It would presumably have same. We're not changing computed value, jsut used. Currently that's just a concept. Only effect of flow root is it establishes a BFC.
<dael> florian: I think multicol is desc as establishing BFC and I think I filed a bug saying that's weird.
<dael> Rossen: Editorial part seems fine
<dael> Rossen: I'll re-read the spec for multicol.
<dael> Rossen: This particular one seems good
<dael> fantasai: Multicol is difficult because it's a new type of FC. It's not really BFC but there's no display that aligns to it.
<dael> fantasai: I'm wondering what dbaron is concerned about
<dael> dbaron: I just think...I'm not aware of an impl and I think it's complicated and there will be side effects you discover once anybody tries to impl
<dael> fantasai: atm I think no effect on impl. Only time it will start to have an effect is if we start to expose used values through OM
<dael> Rossen: AS it stands...
<dael> fantasai: That's the intent. If there's a different effect on impl it's not editorial
<dael> Rossen: atm it's editorial because there's no impl
<dael> Rossen: Objections to accepting the proposal https://github.com//issues/1550#issuecomment-387160020
<dael> RESOLVED: Accept proposal in https://github.com//issues/1550#issuecomment-387160020

[css-meeting-bot]

The Working Group just discussed Used value of display should convert flow to flow-root for BFC roots.

The full IRC log of that discussion

<dael> Topic: Used value of display should convert flow to flow-root for BFC roots
<dael> github: https://github.com//issues/1550#issuecomment-387160020