margin-trimがChrome 155に到達──「端の余白」の例外CSSを消す

カードUIを作っていると、「最後の段落の下だけ余白が残る」「タグ列の右端だけ余白が空く」「最初の見出しだけ上に余計な空間ができる」という問題に必ず当たります。そのたびに:last-child { margin-block-end: 0 }のような例外ルールを足して回るのは、地味ですが確実に保守コストを上げる作業です。

margin-trimは、この「端の余白」をコンテナ側の1行で解決するCSSプロパティです。Safari 16.4が先行して実装し、2026年10月6日にstableとなったChrome 155が追いつきました。一方でFirefoxは未対応で、Baselineには入っていません。この記事では、何が変わるのか、どこまで置き換えられるのか、導入時に何を残すべきかを整理します。

30秒でわかる結論

• Chrome 155（2026年10月6日 stable）でmargin-trimが利用可能になった。Safari 16.4以降は対応済み、Firefoxは未対応。
• コンテナの端に接している子要素のマージンだけを0として扱う。子要素のマージン指定そのものを書き換えるわけではない。
• :last-childや:first-childで行っていた例外ルールを減らせる。
• 対象はブロックコンテナとマルチカラムコンテナ。flex / gridコンテナには効かない（仕様から外れた）。
• 未対応ブラウザでも崩れない。既存のフォールバックを残したまま段階的に導入できる。

何が起きたのか：Chrome 155の対応

Chrome 155のリリースノートにmargin-trimが記載されました。仕様はCSS Box Model Module Level 4で、コンテナの端に接する子要素のマージンをトリムする、と定義されています。

実はSafariが先です。Safari 16.4のWebKitブログでは、カードの中の見出しと段落を例に、p:last-child { margin-block-end: 0 }のような個別対応が不要になる利点が説明されていました。当時はSafari単独実装だったため実務では使いにくい機能でしたが、Chromeが加わったことでChromium系のシェアも含めて現実的な選択肢になりました。

もう1つ見落とせないのが仕様の変更です。Chromeのリリースノートには、以前の版ではflex / gridコンテナにも適用されていたが、その部分は仕様から削除されたと明記されています。つまり「カードの並びでgapの代わりに使う」ような用途は想定されていません。

マージンの相殺（margin collapsing）を止めるプロパティではありません。あくまで「コンテナの端に接するマージンを0として扱う」だけで、隣り合う兄弟要素どうしのマージンには影響しません。

何が変わるのか：例外ルールとの比較

これまでは「親の内側の端に余白を作らない」という意図を、子要素側のセレクタで表現していました。意図と実装がねじれているため、コンテンツの先頭要素が変わると壊れます。

表の右列が示すのは、判断の置き場所が「子」から「親」に移るということです。「この箱の内側では端の余白を作らない」というレイアウトの意図を、レイアウトを持っている側に書けるようになります。

使い方・最小実装

基本はコンテナにmargin-trim: blockを指定するだけです。ブロック方向（日本語の縦書きなら行の方向）の両端が対象になります。

.card {
  padding: 24px;
  margin-trim: block;
}

.card > h2 {
  margin-block: 0 16px;
}

.card > p {
  margin-block: 0 16px;
}

子要素のマージンはそのまま残っている点に注意してください。最後の段落にmargin-block-end: 16pxが指定されていても、コンテナの下端に接しているためトリムされます。子のスタイルを書き換える必要はありません。

横並びのタグ列のように、インライン方向だけを処理したい場合はinline-endを使います。

.tags {
  display: flex;
  flex-wrap: wrap;
  gap: 8px;
  margin-trim: inline-end;
}

.tags > .tag {
  margin-inline-end: 8px;
}

ただし前述のとおりflexコンテナはmargin-trimの対象外です。この例は「flexではgapを使う」という前提の比較用で、実際にmargin-trimが効くのはブロックコンテナやマルチカラムコンテナです。インライン要素を並べる用途では、display: blockのコンテナにインライン要素を流し込む構成で使います。

/* フォールバック: 未対応ブラウザでも見た目を保つ */
.card > :last-child {
  margin-block-end: 0;
}

.card > :first-child {
  margin-block-start: 0;
}

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

フォールバックは残したままで問題ありません。margin-trimが効くブラウザでは、:last-childの指定がすでに0なので結果は同じです。二重に打ち消す必要はなく、@supportsの中は「あれば嬉しい」追加として扱えます。

flexやgridで使える？→ 使えません。仕様から外れているため、子要素の間隔はgapで制御してください。margin-trimは「ブロックコンテナの端」のためのプロパティと割り切ると安全です。

実務への影響

効果が大きいのは、記事本文のようなCMS由来のHTMLです。編集者が先頭にh3を追加したり、末尾に画像を入れたりすると、p:first-child前提のCSSは簡単に崩れます。コンテナ側でmargin-trim: blockを指定しておけば、どんな要素が来ても端の余白は揃います。

カード、注意書き、引用ブロック、フッターのリンクリストなど、「箱の内側に余白を持たせたいが端は詰めたい」場面は繰り返し出てきます。デザイントークンで--space-4のような余白を管理している場合も、端の例外をトークン外の0で上書きする必要がなくなるため、意図が読みやすくなります。

• 記事本文・カード・注意書きなど、中身が可変のコンテナ
• タグ列やパンくずなど、インライン方向の端を詰めたい箇所（ブロックコンテナで構成している場合）
• マルチカラムレイアウトの段の端

注意点

• flex / gridでは効かない。並びの間隔はgapで設計する。
• Firefoxが未対応。MDNはLimited availabilityとしており、Baselineではない。フォールバック必須。
• ロングハンドの対応差。MDNの正式な構文はnone、block、block-startとblock-endの組み合わせまでで、インライン方向のロングハンドは仕様の整理が続いている。実務ではblockとinlineから使い、細かい指定は動作確認してから採用する。
• 意図しないトリム。コンテナにpaddingがある場合、トリムされるのは境界のマージンであり、パディングは残る。デザイン上の「余白」がどちらで作られているかを確認する。
• 印刷・マルチカラム。マルチカラムでは段ごとに端が判定されるため、意図どおりか実機で確認する。

対応状況と使う判断

自分なら使うか：今すぐ使う。 ただしblockとinlineに限定し、@supportsと既存の:first-child / :last-childフォールバックを残すのが条件です。新規コンポーネントでは最初からコンテナ側に書いておき、既存コンポーネントは触ったついでに移行するくらいの温度感がちょうどよいと感じています。

まとめ

• Chrome 155でmargin-trimが使えるようになり、Safari 16.4との2エンジン体制になった。
• コンテナの端に接する子要素のマージンをトリムし、例外セレクタを減らせる。
• flex / gridは対象外。並びの間隔はgapで設計する。
• Firefoxは未対応のため、既存フォールバックを残した段階導入にする。
• CMS本文やカードなど、中身が可変のコンテナから適用する。

参考リンク

• Chrome 155 Release Notes
• MDN: margin-trim
• WebKit Features in Safari 16.4
• CSS Box Model Module Level 4: margin-trim
• Can I use: margin-trim