[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.