In CSS, what does container-type: inline-size do to an element besides making it a query container?

## container-type is a containment switch The reason `container-type` exists at all is circularity. If an element's size could depend on its contents while its contents were being styled by a query on that size, the layout would never settle. CSS solves this by requiring the container to **promise** that its size in the queried axis does not come from its contents. That promise is containment, and declaring `container-type` applies it. Specifically, `container-type: inline-size` applies **layout containment**, **style containment**, and **inline-size containment**. `container-type: size` applies layout, style, and full **size containment** (both axes). `container-type: normal` is the default: the element is not a size query container at all — though it can still participate in style queries. Each of those pieces has visible consequences, and they are the source of nearly every "why did my page jump when I added container-type" bug. ## Consequence 1: intrinsic sizing in the contained axis disappears Under inline-size containment, the element's **intrinsic inline sizes** (min-content and max-content) are computed as though the element had no content. For a normal block-level `div` this is harmless: a block box already takes its inline size from its containing block, not from its children, so nothing changes visually. It is not harmless for any box that shrink-wraps: ```css .badge { display: inline-block; /* width normally comes from the text */ container-type: inline-size; } /* result: the badge collapses to padding + border, the text overflows */ ``` The same happens to floats, to `width: fit-content` boxes, to grid items in an `auto` track, and to flex items whose base size is content-derived. If you must make such an element a container, give it a definite inline size — a percentage, an `fr` track, a fixed width — or move the `container-type` onto a wrapper that is already block-level and parent-sized. ## Consequence 2: it is a containing block for positioned descendants Layout containment makes the element the **containing block for absolutely and fixed-positioned descendants**. This is the surprise that bites in real codebases: ```css .card-wrapper { container-type: inline-size; } .card__overlay { position: fixed; inset: 0; } /* no longer viewport-sized */ ``` A full-screen modal or a dropdown that was anchored to the viewport is now anchored to the container. If you need a viewport-anchored layer, keep it out of the container's subtree — render it near the top of the document, or use the top layer so it escapes ancestor containing blocks entirely. ## Consequence 3: it creates a stacking context Layout containment also makes the element a **stacking context**. Descendant `z-index` values are then trapped inside it: a child with `z-index: 9999` can no longer paint above a sibling of the container, no matter how large the number. Overlay layering bugs after adopting container queries are usually this, not a mistaken z-index value. ## Consequence 4: style containment scopes counters and quotes Style containment means CSS counters and `quotes` are scoped to the subtree. This rarely matters, but a document-wide `counter-increment` scheme that crosses a container boundary will renumber unexpectedly. ## Why inline-size is the default choice In a normal horizontal writing mode, `inline-size` is the width. A block-level wrapper gets its width from its parent — which is exactly the promise containment demands — while its height keeps growing with content, so nothing collapses. That combination is why almost all real container-query code uses `inline-size`. `container-type: size` is only correct when the container has a **definite size in both axes**, for example a grid cell in a fixed-height row, a `100vh` panel, or a box with an explicit height. Applied to an ordinary auto-height wrapper it collapses the box to zero height, its contents overflow, and the height query it was added for reports nothing useful: ```css .panel { height: 100vh; container-type: size; } /* fine: height is definite */ .wrapper { container-type: size; } /* collapses to zero height */ ``` ## Practical guidance Declare `container-type` on a dedicated wrapper rather than on the component you are styling — this sidesteps both the shrink-wrap problem and the fact that an element cannot match its own container query. Audit any positioned descendants when you add it. And prefer `inline-size` unless you genuinely need to query height and can guarantee the height is definite. The shorthand `container: card / inline-size` sets `container-name` and `container-type` together and is the form most codebases use.