[css-display] Blockifications should establish BFC in block containers

[Loirooriol]

Like #2598, but just for block containers. If an element has a flow inner display type after being blockified, the generated block container should automatically establish an independent formatting context.

And therefore the flow-root nature won't be lost (in practice) in this case:

if an inline flow-root box (aka inline-block) is blockified, it becomes a block box (losing its flow-root nature).

[fantasai]

I disagree with this, because blockification isn't what's causing it to establish an independent FC, the fact that its parent FC is an incompatible type of FC (or it is out-of-flow) is what's causing it to establish an independent FC. If we had some property which caused blockification to in-flow elements inside a BFC, then it would not cause the box to establish a new BFC.

[Loirooriol]

@fantasai But converting flow-root to flow when blockifying seemed acceptable to me because all current cases force a new BFC, and I presumed this would also hold for new properties. But in your hypothetical example, a flow-root inner display type is not only lost in the computed value, in practice the block container also stops establishing a BFC. This seems bad to me. If I specify flow-root, I should always get a BFC.

[fantasai]

Sure, that can be debated; but certainly blockification of a 'display: block' element in that case should not result in 'flow-root'. :) Again, my point is that establishing a new FC isn't something I consider intrinsic to blockification, it's a side-effect. It just happens to be a consistently-applied side-effect at the moment, but I don't want to encode it as a key aspect of the concept in its definition.

[Loirooriol]

OK, let's restrict my proposal. I think the spec should say

For legacy reasons, if an inline flow-root element (aka inline-block) is blockified, it becomes a block flow element. For consistency, a run-in flow-root element also blockifies to block flow. However, the generated block container establishes an independent formatting context, so that the flow-root nature is not lost.

So a blockified block flow is not necessarily a BFC root, but blockified inline flow-root and run-in flow-root must be.

[fantasai]

@Loirooriol We key off of computed values, not specified values, and blockification changes computed values, so we can't actually do that.

[Loirooriol]

@fantasai I don't really see why, but if this can't depend of specified values, then one could say that the blockification does not really affect the computed inner display type if it's flow-root, and that it only becomes flow in the resolved value. I believe this would be equivalent, and then specified values wouldn't be needed.

Display transformations would be saner if the WG hadn't resolved against adding a new inner display type...

[fantasai]

@Loirooriol We can't change how a specified value of inline-block computes, we're tied to what was defined in CSS2 and has been implemented for over a decade now.

[tabatkins]

Overall, this seems like a change that somewhat simplifies your mental model of what goes on, but complicates the actual spec model due to its interaction with legacy compat requirements on how things must compute. (The FC-ification isn't reflected in any actual values; it just becomes something additional that's tossed onto the element due to it being blockified.)

As @fantasai says, every place that blockifies currently also establishes an FC anyway, so we have no use-case for making blockification additionally imply FC-ification. Because of this, we also don't know if we would want to force that connection; there very well might be an example in the future where we want to blockify but lose the FC! The FC-ification part of every current spot is also a significant part of the spec that deserves calling out at the location, anyway, so we wouldn't even be saving ourselves any wordiness if we folded the behaviors together.

[tabatkins]

Let us know if this is okay, or if we should raise the issue to the WG for adjudication. ^_^

[Loirooriol]

there very well might be an example in the future where we want to blockify but lose the FC

With inline-block it would be fine. But with inline flow-root seems very bad to me. But it would happen as a consequence of all the following:

• Blockification doesn't necessarily make block containers establish a BFC.
• inline-block and inline flow-root are syntactically equivalent (per WG resolution).
• flow-root inner display type becomes flow when blockified (because inline-block must blockify to block for backwards compatibility).

I would like to drop one of them to avoid the problem. If the third one can't be loosened, and you don't want to prevent some future feature which relies on the first one, then the problem is probably the second one. Not sure if the WG considered this implication when making that resolution, adding an extra inner display type so that inline-block and inline flow-root are not syntactically equivalent would have probably been cleaner.

Then yes, I would like the WG to either ratify that an element with display: inline flow-root may end up not establishing a BFC, or decide if one of the points above should be reconsidered.

[tabatkins]

inline-block and inline flow-root are just aliases for each other; they're incapable of having different behavior.

[Loirooriol]

@tabatkins Yes, that's my point #2. This could have been different (in fact the WG initially resolved the opposite).

[SelenIT]

establishing a new FC isn't something I consider intrinsic to blockification, it's a side-effect

Can't it be considered the other way round — that the blockification is a side-effect of the establishing new FC for the part of flow content? The primary reason is the incompatibility of the flow inner display type of the element with the environment it needs to be put in, and the only box type that can contain the flow layout was previously the block container, that is why the original outer display is converted to block, or blockified?

[Loirooriol]

@SelenIT But inline-blocks establish a new FC, and they are not blockified.

[SelenIT]

@Loirooriol, now they aren't. But prior the concept of flow-root (and blockification itself!), their behavior could be considered as "partial blockification" (the part of flow as a whole was given the block features like width/height, box model properties etc., and this block-like thing was then contained in an atomic inline box).

With that said, I agree that in current terms blockification and FC-fication are more-or-less orthogonal things. I just tried to expand the scope of the problem a bit, hoping that different view of this behavior could help to find a different, simpler description for it:)

[css-meeting-bot]

The Working Group just discussed Blockifications should establish BFC in block containers, and agreed to the following:

• RESOLVED: keep blockficiation and establishing FC are independent

The full IRC log of that discussion

<dael> Topic: Blockifications should establish BFC in block containers
<dael> github: https://github.com//issues/2673
<rego> it seems oriol is not listening, despite he's on webex :(
<dael> TabAtkins: Oriol has been asking for if blockification should auto establish btc rather then occiationally explicit. fantasai and I disagreeing because they don't happen every time
<rego> so he should participate here on IRC I guess
<dael> TabAtkins: If anyone disagrees and things blockification should auto be a BFC, great let's talk. If not looking for resolution of support
<dael> Rossen_: You saying tha tblicification doen'st force BFC?
<Oriol> I have problems with the cisco program but I'm in IRC
<dael> TabAtkins: Not intrinisically.
<dael> Rossen_: Example?
<dael> TabAtkins: Have to look
<dael> TabAtkins: Any time we blockify and inline block does not cause it to become a FC it just goes to block
<dael> fantasai: That's true in that it does not change hte display computation. THat's required by backwards compat.
<dael> fantasai: We could change to not change display and also make it a formatting context. We do that for lfoat abspos and others
<dael> fantasai: Right now when we do blockification in cases where new element will establish new FC anyway. If we apply blickificaiton in flow blocks I don't think we'd want new FC. Grid items currently blockify and a subgrid isn't a new FC
<dael> Rossen_: does subgrid blockify?
<dbaron> q+ to comment on flow-root point from the issue
<dael> fantasai: If we did we'd need an exception. It has to blockify because if it's an inline grid it becomes not an inline. When it's a grid item...if you have an item inside a grid that element is blockified. Blockification if it says display inline it becomes block. inline-table become block, inline-grid becomes block. But a subgrid isn't a new FC because it intertwinces with grid outside. Can't say it's a new FC, but it is blockified
<dael> fantasai: I don't htink we can tie these two concepts together. block makes it a block. They almost always coincide but I don't think the concepts are intrinisicaly bound and shouldn't be tied in spec
<dael> florian: Exception of subgrid this is an editorialtwist as to if you describe separately or together. So it's editorial.
<Oriol> But I think a BFC is desired if you have `display: inline flow-root`. CSS DIsplay says it becomes `flock flow`, and a future feature might blockify without forcing BFC. Then the flow-rootness will be lost
<astearns> ack dbaron
<Zakim> dbaron, you wanted to comment on flow-root point from the issue
<dael> dbaron: I think one other point in the issue from Oriol . I think Oriol trying to put in IRC too
<dael> dbaron: Current blockification remove flow-root nature. If blockification always makes things FC it's fine. If it doesn't then maybe blockification rules need to be fixed so if you say flow-root you don't lose that
<dael> fantasai: So far cases where lose flow-root is converting inline flow-root or a run-in flow-root. In case of inline block we can't change how display is computed due to backwards compat.
<dael> fantasai: Every other casing where flow-root is blockified it establishes a new FC anyway.
<dael> fantasai: We're flowing it, we're abspos it, putting it in a grid or flexbox. These are cases where element that is a block container it establishes a new FC
<dael> dbaron: So in subgrid it's not possible to be a new FC?
<dael> fantasai: Matter of termonology, but fundimental idea of a new FC is there's no intertwining between new and old FC. If there's info passed through the bounderies when you do something like whitespace collaposing it's porous. Same is true for display:block, margins collapse through boundary. The contents inside and outside participate
<dael> fantasai: New FC creates a barrier without that bleedthrough. THe justificaiton and alignment doesn't pass through the inline block boundary. Same as a block element with new FC.
<dael> fantasai: For a grid, if you nest a grid inside a grid same thing applies. No interactions between grid tracks inside a nested grid. Subgrid you do have negotiaion between inner subgrid context and outer parents and siblings. THey participate together in sizing algo
<dael> fantasai: The size declarations and names of lines on parent pass to subgrid. There is fundamental bleeding through of the content and the layout calc. To say it's a new FC doesn't make sense.
<dael> dbaron: Makes sense to me. Some point earlier I thought you said that...something about how these were still block formatitng context.
<dael> fantasai: Grid items are considered grid level, not block. They participate in grid FC. But there is blockificaiton process that changes display values to make them block-like. We convert anything with a non-block outer display to a block
<dael> dbaron: And one can be a subgrid?
<dbaron> s/one/one of the blockified things/
<dael> fantasai:You run blockificaiton on every grid item. You run it through blockification IMight be a no-op, but you run through.
<dael> fantasai: Was we decided to do subgrid with a new type the display-type of a subgrid needs to be declared. If you say grid or inline grid doesn't really matter.
<dael> fantasai: Blockificaiton process turns inline on subgrid to grid.
<dael> dbaron: I worried you said display block could be subgrid
<dael> fantasai: No, you can't
<dael> florian: Blockification is really dis-inline-ification
<dael> fantasai: In a sense. WE have outer display type which says how your behavior is when in flow layout. Outside of flow layout distinction between inline and block has no meaning and is ignored. Each display value corresponds to a state.
<dael> fantasai: If I take subgrid and put it in a bfc it will not behave as subgrid, but it'll be the fallback behavior.
<TabAtkins> Core point tho: grid items are blockified, subgrids are grid items (by definition) but aren't FCs (by definition), so blockification *cannot* imply FCification in general.
<dael> fantasai: weither declared inline or block grid it'll make a difference in partiipation once in block container
<dael> astearns: Back to original issue: We have a choice of keeping things as we are where blockification and formatting context are discussed sep. Or we changes that blockification implies a FC but it can be overwritten in places like subgrid
<dael> astearns: Argument that 2 things are sep is compelling to me because having both explicit sounds easier to comprehend. I like that it's explicit
<Rossen_> q+
<florian> since this makes no behavior difference, this is editorial, and I like to leave it up to the editors to describe it the way they want. That helps the whole prose be coherent
<dael> astearns: Argument to tie together is that there may be situations in the future where we might forget about forcing FC in blockificaiton case where we need it to happen. Benefit for the explicit call outweighs danger of forgetting to make that call in the future.
<astearns> ack dbaron
<AmeliaBR> Is there any consequence of blockification that *is* necessary for subgrid? Or can it just be that "grid-items are blockified (and create a formatting context), *except* for those with `display: subgrid`"?
<fantasai> AmeliaBR, inline-grid needs to be converted to grid
<fantasai> ('display' value)
<dael> dbaron: blockficiation without FCification doesn't work in a block context. IN grid it's fine, but in block context it removes the things that are supposed to be FC> I think that's a piece Oriol doesn't like. Maybe it's that we never will use and so it's okay. Might be worth noting.
<astearns> ack Rossen_
<dael> astearns: Make sense to call that out in all current cases you need the 2 in a block context
<Oriol> Yes, the problem is with flow layout
<dael> Rossen_: fwiw, from impl experience we've had this model inside our engine since IE9. During style computation we independently decide inner layout type, outside layout placement (where you will be placed), and 2 aux ones, what is your placement and what is your layout type and that's if you're a BFC
<dael> Rossen_: What I can tell you is they're all independent. But I don't see why we should unless from inline block PoV we have to.
<dael> fantasai: address point from Oriol and dbaron where if you happen to use blockification for block level items question...example is an inline block when blockifies turns into display:block which is pourous. Argument is inline:block should be a Block flow-root and a new FC. Not convinced of that being the expectation.
<dael> fantasai: I think that's part of why it's not in CSS 2.1...distinction between block, block layout, and bfc is not huge. inline block vs a block do form a pair.
<Rossen_> s/what is your placement and what is your layout type and that's if you're a BFC/based on the layout placement and type we compute if you're a BFC and if you require a stacking context/
<Oriol> I think it may be OK if inline-block doesn't become a flow-root, but if you esplicitly specify flow-root, you shouldn't lose it
<dael> fantasai: formatting context establishment is a side effect because they just want this as a block to be a FC, not something they specificially needed.
<dael> fantasai: I'm not sure what you would expect, but becming display:block isn't nec unexpected. If you said inline flow-root it's clear you wanted that but we're getting into fiddly cases and we decided inline-block and flow-root are identical
<astearns> ack dbaron
<dael> dbaron: I think this is a negative side effect of that. Prob fine ofr inline-block, but wierd if flow-root.
<dael> dbaron: I think I'm okay just concluding here
<dael> astearns: And close no change dbaron ?
<dael> dbaron: I think no change and a note pointing out that there is this where if you do blockification without FC and people used flow-root explicitly
<dael> astearns: Need to ask Oriol if he's okay closing with a note.
<dbaron> s/there is this where/it isn't great if/
<Oriol> OK, but note that if a future fewature allows blockification without BFC, then it will be more difficult to change
<dael> astearns: And would anyone else obj to resolve no change except adding a note
<dael> fantasai: 3 ways forward, to be clear.
<dael> fantasai: 1) close no change FC and blockificiation are independant
<dael> fantasai: 2) Blockificiation implies FCificiation so inline block convers to block flow root and we will need an exception for subgrid
<dael> fantasai: 3) revert resolution where we said inline block and inline flow are identicatal and say they're independant and have same behavior except if you blockify.
<dael> fantasai: THat lets you when you blockify inline flow-root it becomes display: flow-root
<dbaron> I'd be fine with (3) based on this discussion but I don't know why we made that resolution to begin with.
<dael> astearns: We're 30 on this issue. My preference would be close no change and raise a new issue on inline block and inline flow-root
<dael> fantasai: We had an issue and resolved on the current. Only reason to re-open is if people want option 3 which gets you independfence for blockificiation and FCification but also clarifies the inline flow-root.
<dael> astearns: Reopening that with this in mind makes sense and doesn't change how we'd resolve here.
<dael> fantasai: fair enough
<dael> astearns: I'd like to close this.
<dael> astearns: Let's resolve that blockficiation and establishing FC are independent and we will add a note on the flow-root issue which can become a github issue to change our previous decision
<dael> fantasai: This is last open issue before CR so we need to open the issue or go to CR
<Oriol> Works for me
<dael> astearns: obj to keep blockficiation and establishing FC are independent
<dael> RESOLVED: keep blockficiation and establishing FC are independent
<dael> astearns: Anyone think we should take up an issue about inline block and inline flow-root?
<dael> florian: Rathe rnot
<dael> dbaron: Don't know context of original decision so hard to know
<dael> astearns: Let's leave at that this week. those in the discussion please decide if open new issue.
<dael> Rossen_: Should we resolve on to CR?
<dael> astearns: Let's give another week and go to CR next week.

[Loirooriol]

I filed #2947 for discussing whether inline-block and inline flow-root being syntactically equivalent should be reconsidered.