Margin-Trim Block List

A vertical stack of paragraphs/cards whose first child's top margin and last child's bottom margin collapse to zero automatically against the container's own edge — via the CSS `margin-trim: block` property on the container — instead of the classic `.item:first-child{margin-top:0}` / `.item:last-child{margin-bottom:0}` override every uniform-vertical-rhythm list otherwise needs, which silently breaks the moment an item gets reordered, conditionally rendered, or wrapped in one more div. `margin-trim: block` trims the margin-before of the first in-flow child and margin-after of the last in-flow child of the container it's set on, dynamically, for whatever ends up being first/last at render time — no selector to keep in sync with markup changes. **Real, current, genuinely fresh this run, cross-checked across independent sources, not a single blog's guess:** Chrome's own Chrome 155 Release Notes (chromestatus.com/release-notes/155) lists `margin-trim` under Chrome 155's default-on CSS changes, and Chrome 155 reached stable on **2026-10-06** (independently corroborated by a GIGAZINE report on the same stable rollout, dated 2026-10-07 — the same cross-check this catalog's own 'symbols()' entry already used for the same Chrome 155 milestone); the MDN `browser-compat-data` project's own tracked entry for this property (`css/properties/margin-trim.json` on GitHub) independently agrees, recording `"version_added": "155"` for Chrome. **Cross-engine status, stated precisely, with a real nuance most sources flatten away:** Safari actually shipped `margin-trim` first, years earlier — Safari 16.4 (March 2023, per WebKit's own 'Easier layout with margin-trim' blog post) — but, per a dedicated explainer by CSS Working Group member Rachel Andrew (rachelandrew.co.uk, published 2026-09-15 ahead of the 155 stable rollout) and a corroborating MDN `browser-compat-data` GitHub issue (#30528, 'margin-trim is only partially supported in Safari'), Safari's support is block-containers-only and does **not** extend to multicol containers the way Chrome 155's does — a real, sourced asymmetry, not a simple 'Safari had it first' story. Firefox has not shipped it at all: Mozilla's own tracking bug (bugzilla.mozilla.org #1506241) has been open for **7 years**, is rated P3 (low priority) with no assignee, last updated 4 months ago — genuinely stalled, not merely 'in progress.' So this is 2 of 3 engines, each with a different real scope, correctly NOT Baseline. **Correction to this log's own day-45 entry, stated honestly rather than silently fixed:** that entry listed `margin-trim` as one of 'Chrome 154's own release' follow-up candidates; re-checked today at the primary source, it was actually announced in the **Chrome 155 BETA** post (developer.chrome.com/blog/chrome-155-beta, 2026-09-16), not 154 — a one-release mislabel in a 'noted for completeness, not yet scoped' aside, not a catalog-entry claim, but worth naming precisely now that it's actually been researched and built. Checked for overlap first: no existing entry in this catalog touches `margin-trim` in any form (block/inline, container query, or otherwise) — genuinely new ground; distinct from the existing 'Precision Text Trim' entry, which trims a text line's own leading/trailing *line-box* space via `text-box-trim`, not a flex/block container's child *margins*. **Fit check — DIY $999 tier, real, strong fit:** zero WebGL, zero scroll-jacking, zero JavaScript — a uniform-spacing paragraph block or stacked FAQ-answer list is exactly the small-business-site content most DIY-tier pages ship; not added to `docs/diy-website-style-catalog.md` this run — that file is still missing (see this run's log entry, now day 46 of the same standing gap). **Honest fallback, verified this run, not assumed:** the base rule gives every paragraph a uniform `margin-block` with no first/last override, so an unsupporting browser shows a real (if slightly larger) gap between the box edge and the first/last line — never a broken, overlapping, or blank layout. The trimmed effect is gated behind `@supports (margin-trim: block)`, which a real headless-Chromium check this run confirmed evaluates to `false` on this sandbox's own pinned Chromium (**153.0.8010.12**, unchanged since day 44/45 — two stable versions short of the Chrome 155 threshold this entry needs, an honest, current gap, not a stale one). A `getComputedStyle` check on both demo boxes after render confirmed every paragraph in both columns computes a real, non-zero `margin-block-start`/`margin-block-end` (the fallback box's visible top/bottom gap is real computed spacing, not a rendering fluke) and that the `@supports`-gated caption computes `display: "none"` — correctly hidden rather than silently shown-but-wrong, the same 'never broken, never half-done' bar every entry here is held to. (Vanilla example: live iframe preview + HTML/CSS tabs, no JS tab at all — compare the gap above/below the first and last line in each dashed box.)

<div class="mtb-row">
  <div class="mtb-col">
    <span class="mtb-label">Default (no trim)</span>
    <div class="mtb-box">
      <p class="mtb-p">First line of body copy.</p>
      <p class="mtb-p">Middle paragraph, same rhythm.</p>
      <p class="mtb-p">Last line before the box edge.</p>
    </div>
  </div>
  <div class="mtb-col">
    <span class="mtb-label">margin-trim: block</span>
    <div class="mtb-box mtb-trimmed">
      <p class="mtb-p">First line of body copy.</p>
      <p class="mtb-p">Middle paragraph, same rhythm.</p>
      <p class="mtb-p">Last line before the box edge.</p>
    </div>
    <span class="mtb-note">Needs Chrome/Edge 155+ or Safari 16.4+</span>
  </div>
</div>