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.

@fantasai But then the inlinification of a block ruby is not consistent with the inlinification of block flow. And people will continue using overflow: hidden or clearfix hacks just to have a block ruby with a BFC. And when a block ruby is forced to establish a BFC, this can't be explained in terms of display at used-value time. This is not nice.

I think I'm not opposed to making contain not apply to inline or ruby boxes. This isn't sort of the same layout with optimization-friendly tweaks turned on, but a radically different layout, so if an author wants that, they should ask for it. Maybe somebody has good use cases though, we could try to do some outreach, see if people have good reasons for wanting it to apply, and decide against it if not.

Either way, I still think we should define the whole table. To me it really seems to be an underlying concept that's slowly emerging as various specs expose various aspects of it. Defining the full model would give us a more solid foundation for spec building, avoiding us having to wonder exactly what these different operations mean in different contexts, or to accidentally redefine them incorrectly when we forget to think things through.

Having this table (and the becoming a FC terminology) would have avoided #1071.

It would also have helped steer the discussion about whether contain should apply to inlines/ruby, from "what would that even mean" to "would that be good for authors".

It would allow for more precise wording in the flexbox spec (there's the same thing in grid):

A flex item establishes a new formatting context for its contents. The type of this formatting context is determined by its display value, as usual.

What's "as usual"? → See the table.

Maybe this should also be invoked from the table spec (but then again, tables are weird, so the logic may be different there).

Anyway, that's my reasoning for wanting the table (and the becoming a FC terminology) to exist.

As for exactly what it should say, I am less strongly locked into any particular solution, but I do find @Loirooriol's arguments persuasive.

@frivoal I don't understand what you're confused about. The type of formatting context is defined by the outer display value; this is explained in css-display-3 under the definition of 'display'. The table screenshotted above does nothing to make this clearer. And “becoming a formatting context” is a seriously awful phrase: a box is not a formatting context.

@Loirooriol If you come back to me with significant use cases where we need an element to be a block-level ruby container that establishes a new block formatting context, I will reconsider. Until then I don't see any reason why we need to add such a feature. “For completeness” is not sufficient reason to add a new display type. I'm already skeptical that we even need block ruby at all, other than to explain what happens when you blockify it.

And “becoming a formatting context” is a seriously awful phrase

@fantasai I complained about the name in #1758, now it's "becoming a formatting context root".

I'm already skeptical that we even need block ruby at all, other than to explain what happens when you blockify it.

I want ruby-root just for the same reason: to explain what happens when it becomes a formatting context root (e.g. via float, position, overflow, contain, etc.) in terms of display types.

So, this issue has two problems tangled in:

1. Should layout containment and paint containment apply to non-atomic inline-level boxes (inline ruby, inline flow, run-in flow, and run-in ruby), and if so, how?

2. Should we have an anchor term (so far: becomes a formatting context root, could be something else) that defines which formatting context elements establish when they're told they have to establish one?

   2.1. If yes to 2 does that work by altering the computed value of the display property (in a way that involves flow-root / ruby-root, as suggested in @Loirooriol 's tables)

I believe that fantasai's position is:

1. No: there are no identified use cases
2. No: it's clear enough already by just saying "must establish a formatting context"

My latest position is:

1. No: there are no identified use cases

2. Yes: we're re-defining this in an ad-hoc manner in a number of places, and that this has caused confusion (here) and spec bugs (multicol in [css-multicol] 'column-span' and tables #1071, or an older version of css-overflow, both accidentally turning flex containers, grid containers, or tables into BFCs).

   2.1. No: at least not at computed value time, as that is not compatible with existing uses.

If we take fantasai's approach, I should:

• Drop the becomes a formatting context root
• state that layout and paint containment have no effects on non-atomic inline-level boxes (inline ruby, inline flow and inline run-in)
• state that layout and paint containment cause block containers to establish a BFC (with no effect on the computed value of the display property) (and the other type of things it applies to already establish an FC of some kind, so there's no need to say more)

If we take my approach, I should:

• Rename and rewrite the becomes a FC root section to something like this, to be included in css-display (probably at the end of https://drafts.csswg.org/css-display-3/#formatting-context):

  Specifications may call for an element or box to <dfn export>establish a formatting context</dfn> without further precision as to the type of formatting context or how to do so.
  This operation is not applicable to non-atomic inline-level boxes nor to boxes with a layout-internal display-type. Specifications that invoke this must either exclude such boxes, or to blockify them first.
  If the box is a block container that does not establish a BFC, it is made to establish a BFC. Otherwise, the box already establishes a formatting context, and this operation is a no-op.

  Note: This has no effect on the computed value of the display property.

  Note: If a specification defines a new type of box which are neither non atomic inline level, layout-internal, block containers, or some other display type that establishes a FC, then that specification must define the meaning of this operation for that type of box.

• state that layout and paint containment have no effects on non-atomic inline-level boxes (inline ruby, inline flow and inline run-in)
• Also use and link to that terminology:
  • in css-contain to in state that layout and paint containment cause the box they apply estblish a formatting context
  • in css-multicol for column-span
  • in css-overflow for overflow
  • in grid and flexbox for the definition of grid items and flex items instead of "[...] establishes a new formatting context for its contents. The type of this formatting context is determined by its display value, as usual"

Agenda+F2F to hopefully resolve on either of these two proposals (I prefer mine but won't object to fantasai's).

does that work by altering the computed value of the display property (in a way that involves flow-root / ruby-root, as suggested in @Loirooriol 's tables)

Only blockifications and inlinifications happen at computed value time. Becoming a FC root happens at used value time.

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

• RESOLVED: layout and paint containment does not apply to non-atomic inlines
• RESOLVED: clarify the definition of what and how a FC is created

The Working Group just discussed Establishing independent formatting contexts, and agreed to the following:

• RESOLVED: accept the edits