I see various problems with the Becoming a formatting context section.

In some circumstances (See [CSS-CONTAIN-1] or [CSS3-MULTICOL] for examples), an element may need to become a formatting context.

"See" should be lowercase.

Situations that CSS2.1 said produced a block formatting context when in fact they only needed to become a formatting context should be listed here. This includes out-of-flow boxes, and boxes to which overflow applies and is different than visible. Maybe also mention block containers that are not block boxes.

If the element already establishes a formatting context of any kind, this condition is satisfied.

Except for inline formatting contexts! Inline formatting contexts are not contained at all, they are e.g. affected by floats, so contain: layout is not satisfied by a block container that establishes an inline formatting context, it must establish a block formatting context instead.

And what about ruby formatting contexts? I know very little about them, but I don't think establishing a ruby formatting context is enough neither.

I propose:

• If the inner display type is flow-root, table, flex or grid, the condition is satisfied.
• If the inner display type is flow, it is changed to flow-root.
• An element with a ruby inner display type always (not just if the outer display type is different than inline) generates two boxes: a principal box with the inner display type set to flow and the outer display type set to the outer display type of the element, and an inline-level ruby container. "Becoming a formatting context" only affects the principal box, changing its inner display type to flow-root.
• Not sure about layout internal types.

This note also needs to be fixed:

Exclusions are able to affect content across formatting context boundaries. (At time of writing, they are the only layout feature that can.)

Maybe it would be better to say that inline (and ruby?) are pseudo-formatting contexts or some thing different than "real" formatting contexts.

Wow, I didn't even notice this section being added. The whole thing makes no sense. For example, it's saying that display: ruby element becomes a display: flow-root when contain: paint is set on it, and that this is a used value time transformation of the display value... which makes no sense because box generation depends on computed values. Then it goes on to define a concept of “becoming a formatting context”, but doesn't explain how this is different from “establishing a formatting context” (which is an established term of art that has a specific meaning as defined in the Display glossary and CSS2.1), nor how that works.

Imho, either this needs a proper definition that makes sense, is appropriate to the issues in paint containment, and doesn't conflict with the rest of CSS, or contain needs to limit itself to appropriate display values so that it's not creating nonsensical layout effects out of thin air.

Origin of section: https://github.com/w3c/csswg-drafts/pull/831/files
Move to Display: https://hg.csswg.org/drafts/rev/49ade53b18a2
Current location: https://drafts.csswg.org/css-display-3/#becoming-formatting-context

Then it goes on to define a concept of “becoming a formatting context”, but doesn't explain how this is different from “establishing a formatting context”

As Tab commented in #1581 (comment)

Some elements define that they establish a formatting context; there is no general definition of how to make an arbitrary element establish a formatting context.

If the element already establishes a formatting context of any kind, this condition is satisfied.
Except for inline formatting contexts!

I agree, this exception should be called out.

[...] and that this is a used value time transformation of the display value... which makes no sense because box generation depends on computed values.

Ok, that was the wrong way to go about it. Would there be a problem with simply moving this fix-up to computed value time?

for example, it's saying that display: ruby element becomes a display: flow-root when contain: paint is set on it.

I don't think it is saying that: display: ruby causes the box to be a ruby container, which in turns means it establishes a ruby formatting context. Since it already establishes a formatting context, becoming a formatting content is a no-op:

If the element already establishes a formatting context of any kind, this condition is satisfied.

That said, as @Loirooriol pointed out, this may be insufficient, and we may need to come up with something better.

That said, maybe this should be excluded from css-contain? css-contain already layout and paint containment do not take effect on internal table elements. Maybe ruby elements should be excluded as well? I have a bit of a hard time thinking of legitimate use cases of containment on ruby or ruby parts.

Not sure about layout internal types.

For internal table parts, neither css-contain nor css-multicol invoke "becomes a formatting context". For ruby internal parts, multicol does not, and (as discussed above) maybe contain shouldn't either.

This doesn't mean that we don't need to define what this does, but there is no particular expectation from the current places that invoke this.

In #1496 there are some ideas about how to treat a ruby that becomes a formatting context. Probably the independent flow-root keyword won't happen, but maybe a new ruby-root inner display type could be added, it would wrap the inline ruby container inside an inline-block or a block BFC-root, depending on the outer display type.

I think it makes sense to exclude contain from applying to layout-internal boxes, because they are internal things with special behaviors, and can be tightly entangled with other boxes in the same FC. But I would not exclude contain from ruby containers, because they are not internal.

Another thing: I initially described this as used value time on the display property, which was wrong because there isn't really such a thing, but the intent behind this attempt was:

• Hook into an existing mechanism (the flow-root logic of the display property) to avoid creating a similar but different thing
• Don't affect the computed value of the display property, because multicol (which uses this) never did, and other cases that turn things into (B)FCs (such as setting overflow to something other than visible, or the position property, or the float property) also don't affect the computed value of the display property

Regardless of what we do, I do not think that we should affect the computed value of the display property, as that would introduce a behavior change through inheritance. I don't expect that the following code is particularly common, but there's no reason to introduce a breaking change if we can avoid it:

.abs { position: absolute; }
.abs > div { display: inherit; }

This should not result in the nested div having a display flow-root.

Maybe we can just change this to "has the same effect as".

I think the approach proposed in #1550 by @Loirooriol is likely to solve this issue as well.

The CSS Working Group just discussed Becoming a formatting context, and agreed to the following resolutions:

• RESOLVED: Move "becoming a formatting context" section back to css-contain, mark ruby/inline as open issues to figure out

I'm confused, if in #1550 you approved that flow never establishes a BFC (but it can be switched to flow-root via "becoming a formatting context"), shouldn't "becoming a formatting context" remain in CSS Display?

possibly, but we haven't figured out what to do with ruby yet, and don't want to block the display spec on something that only matters for css-contain. Once we figure it out, it is possible it will make its way back to the display spec.

But after #1550 I don't think this is only a css-contain problem. Now if flow ends up establishing a BFC that's via becoming a formatting context, and I don't see why it should be different for ruby. So if you float a ruby then it also becomes a formatting context. If you use overflow: hidden on a block-level ruby it also becomes a formatting context. If you make a ruby be a flex or grid item it also becomes a formatting context.

Now I'm more convinced that this should be explained by adding a new inner display type: ruby-root. Becoming a formatting context would switch ruby to ruby-root at used-value time. Exposing this inner display type in <display-inside> syntax is not necessary, for the moment it could be kept as an internal thing of the spec.

This should all be CSS Display things, then in CSS Contain you can decide whether contain applies to ruby or whether the ruby is blockified when contained.

That might end up being how we solve it, yes, but in the meantime we don't need to worry about it, because aside from Contain, every instance of something becoming a formatting context also blockifies it.

The above resolution (moving the definion back to css-contain and noting an issue about ruby) is done. We still need to resolve that issue.

The Working Group just discussed becoming a formatting context root.

My preference here would be to say that layout containment doesn't apply to inlines or ruby, just like it doesn't apply to internal table elements. Turning blocks into BFCs is straightforward, a lot of other CSS properties do it as a side-effect, and it doesn't change layout much. But turning an inline into inline-block or ruby into inline-block-ruby-thing would make a major difference to the layout, and I think that if the author wants that they should be requesting it explicitly. Making it a side effect of a perf tweak doesn't make much sense to me.

OK, but note that contain is not the only reason that makes ruby-root desirable.

For example, flow-root was supposed to kill the overflow: hidden hack, but if people can't use display: block ruby-root I think they will use display: block ruby; overflow: hidden.

Additionally, someone may use block ruby because they want to use height or width. But if the element is inlinified (e.g. it's inside a run-in), then it will become inline ruby and will stop generating a block container. Just like block flow inlinifies to inline flow-root, block ruby should inlinify to inline flow-root (#1700).

I agree wrapper boxes are not much desirable, but since there already is block ruby, I think we should go all the way and cover all cases.