[css-contain] `contain` should not affect `display`

[fantasai]

Paint Containment is messing with box relationships in ways that don't make 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.

Basically this whole section is messed up. It either needs a proper definition that makes sense 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.

[fantasai]

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

[tabatkins]

You're correct that "used-value time" transformation of boxes doesn't make any sense. This also directly conflicts with our "two types of box-tree fix-up" that we're maintaining in Display (computed-value 'display' fixing, and anonymous box creation).

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.

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. More specifically, some layout types don't have a "formatting context" concept, but we need to be able to generate one for them to make layout and paint containment work.

The current spec's intention is to just bail out easy, by forcing elements that aren't already FCs into becoming either block or inline flow-roots, which are FCs and satisfy the condition. There's probably a smarter way to do it; this is tracked in #1457 already.

(This issue is technically a duplicate of #1457, then.)