Containment

Containment is a promise an element makes about its contents so that the rest of the document may stop consulting them. CSS Containment 2 spells it contain, and <xref:Vixen.Ui.Layout.Containment> is how it reaches the layout store.

⚠ It is five independent effects behind one property, not one switch with five settings, and the useful spellings are combinations:

contain: content is layout paint style and contain: strict is that plus size. Both are accepted as whole values; CSS forbids either beside another keyword and so does this reader.

⚠ Size containment is not "skip the children", and reading it that way is how it gets built wrong. § 3.2 says the box is sized as if it were empty. It goes on laying its contents out, painting them, hit-testing them and scrolling them — it only refuses to let them decide its own box. The difference is invisible in any fixture where the children happen to fit, which is most of them.

Stopping a subtree's size from escaping. A panel whose contents change every frame makes its whole ancestor chain re-measure. contain: size with a stated width and height cuts that chain: the box is what its own style says, whatever is inside it.

Getting a containing block without position: relative. contain: layout makes the box the containing block of every absolutely positioned descendant. That is what position: relative is usually written for, and this says it without also changing how the box paints or how z-index resolves around it.

Clipping without claiming to scroll. contain: paint cuts descendants at the box exactly as overflow: hidden does, and says why: it is a promise about painting rather than a scroll container with its scrolling turned off.

⚠ What it is not for here is performance. In a browser, containment is a hint that lets an engine skip work. This engine takes it as a correctness declaration — the box really does size and clip differently — and does not yet use it to prune any pass. A stylesheet that writes contain: strict on a hundred panels gets the specified geometry, not a faster frame.

From the layout store, one setter taking the flags:

In a .vcss it is the declaration CSS uses, and the reader takes a list of keywords:

The eight contain-* utility classes spell the same thing — contain-none, contain-content, contain-strict, contain-size, contain-inline-size, contain-layout, contain-paint and contain-style, each emitting its own keyword.

The only arrangement in which size containment can be seen. A box with a stated width and height is the same box either way, so a fixture that states them proves nothing at all.

Add padding and the collapsed box is the padding, not zero — § 3.2 removes the contents from the sizing, and a box's own padding and border are not contents.

An implementation that treated this as size gets the height wrong; one that ignored it gets the width wrong. Both halves have to be asserted or the keyword is indistinguishable from its neighbour.

Without the declaration, right: 0 resolves against whatever ancestor is positioned — the root, in a document where nothing else is. With it, the box itself is the containing block. ⚠ Neither element is position: relative, and a fixture where either one is cannot fail.

⛔ style containment is refused, and the refusal is measured rather than pending. § 3.4 scopes counters and quotes to the subtree, and this engine has neither — so every value of it would parse, compute and move nothing. The keyword is therefore understood and inert rather than rejected: that distinction is the difference between contain: layout style still containing layout and the whole declaration being dropped. An unrecognised word does drop the declaration, which is what CSS does with a value it cannot parse.

⚠ Paint containment clips at the border box, where CSS says the padding box. That is the rectangle overflow already cuts at in this engine, and painting, hit testing and sticky positioning all read it from one place — <xref:Vixen.Ui.Layout.Containment> is folded into that single answer rather than given a clip of its own. Correcting one of the two without the other would produce exactly the disagreement that arrangement exists to prevent.

⚠ Containment prunes no work. Nothing skips a measurement, a layout pass or a draw-list walk because of a promise made here; the property changes what the answer is, not how long it takes to get. contain: size still lays its subtree out.

⚠ contain-style is a real class for a keyword that moves nothing, and that is deliberate rather than an oversight. ContainmentReader drops a declaration it cannot parse whole, as CSS does — so a style it had never heard of would make contain: layout style contain nothing at all, and both aggregate keywords expand through it. Understood-and-inert is a different state from unparseable.

• Floats and clear — the other property whose main effect is establishing a formatting context, and the one whose flow-root keyword does half of what contain: layout does.
• Inline layout — what an independent formatting context means for the boxes inside it.
• <xref:Vixen.Ui.Layout.Containment> — the flags, one remark per value.