Chrome 155 beta gives block layouts a margin-trim option

Spacing systems often end with an awkward pair of selectors: remove the top margin from the first child, then remove the bottom margin from the last. Chrome 155 beta adds another option. The new CSS margin-trim property lets a container omit margins before or after its first or last child, keeping the content’s internal rhythm while removing the outer overhang. Chrome announced the feature for regular block containers and multicol containers. This is beta-channel news, not a claim that it is already a cross-browser or stable-default primitive.

The container decides which outside margins disappear

The useful mental model is that child margins still belong to the children, but the container can decline to honor the margins that touch its start and end edges. In a prose section, stacked cards, or a generated content block, that can make the component’s padding the single source of exterior whitespace. The gaps between siblings remain part of the normal composition; margin-trim is not a request to collapse every gap in a stack.

That distinction helps separate two jobs that are commonly mixed together. A component owner can set the boundary around a group, while the content inside keeps its own vertical rhythm. It can be easier to reuse a rich-text or card stack when it no longer needs special first- and last-child exceptions every time it is placed in a new shell.

Chrome 155 beta has a deliberate layout boundary

Chrome’s release note describes support on regular block containers and multicol containers. It also calls out an important change in direction: an earlier version of the specification applied the behavior to flex and grid containers, but that part has been removed. A layout that happens to look like a stack is therefore not enough reason to assume it qualifies. Check the actual formatting context before treating margin-trim as an option.

That limitation matters in design systems. Many modern stacks are flex or grid components even when they read as a simple vertical list. For those, retain the existing spacing approach until the platform and your supported browsers offer a suitable alternative. Treat margin-trim as a focused enhancement for the block and multicol cases Chrome documents, rather than a universal reset for all component layouts.

Use progressive enhancement, not a spacing rewrite

The safest migration begins by keeping the established rule that produces the correct layout today. Then add margin-trim inside a feature query so a supporting browser can take over the outer-edge cleanup. The fallback should remain visually correct if the query is ignored. That lets teams simplify selectors where the feature is available without forcing every browser or every layout mode into the same implementation.

@supports (margin-trim: block) {
  .article-stack {
    margin-trim: block;
  }
}

Before applying it, inspect a real component with varied child content: headings, paragraphs, elements that already use margins, and empty or conditional sections. Confirm which edge is responsible for the space you want to remove, then compare the result in a supported Chrome 155 beta environment and in the fallback. The property is most valuable when it replaces a narrow exception with an explicit container decision—not when it hides an unclear spacing contract.

A small primitive with a clearer ownership model

The appeal of margin-trim is not merely fewer selectors. It gives block-oriented components a vocabulary for saying that exterior spacing belongs to the container and interior spacing belongs to its contents. For teams building text-heavy modules or multicol layouts, that can make a familiar pattern easier to compose. For now, keep the scope in view: Chrome 155 beta, regular block and multicol containers, and a fallback for the rest.

Primary source

Chrome for Developers, “Chrome 155 beta,” published September 16, 2026: https://developer.chrome.com/blog/chrome-155-beta