Repository navigation
[css-display] 'flow' inner display type should never establish a BFC #1550
Description
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:
- Block containers that are not block boxes
- Out-of-flow
overflowapplies and is different than visible- The root element
Activity
Loirooriol commentedon Jul 19, 2017
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 commentedon Aug 3, 2017
I don't see the difference between these two.
Yup, inline box vs block box is the result of crossing {block, inline}x{flow}. That's fine.
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 commentedon Aug 3, 2017
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 commentedon Aug 4, 2017
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 commentedon May 7, 2018
Checked in edits to define that “a block container that establishes a new block formatting context is considered to have a used
displayvalue offlow-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 commentedon May 7, 2018
It's acceptable, but in fact I no longer have a strong opinion about this. I wanted the
flowinner display type to never establish a BFC, and explain the cases in which a BFC is needed by saying that the useddisplayvalue of the generating element has been changed toflow-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 newruby-rootinner 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
flowinner display type generates a block container that establishes a BFC, the result looks like if the element had aflow-rootinner display type. But this doesn't seem to simplify things, which is what I initially wanted.Loirooriol commentedon May 8, 2018
Wait, it's not correctly written. It seems to imply that, if you have
display: list-item; float: left,display: list-itemwill behave likedisplay: flow-root, losing the marker.I think it should say "is considered to have a
flow-rootinner display type at used-value time".[css-display-3] Used *inner display type* of flow-root; used 'display…
fantasai commentedon May 22, 2018
@Loirooriol Fixed, thanks. :)
css-meeting-bot commentedon May 23, 2018
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-387160020The 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 commentedon May 23, 2018
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