なぜ「display: inline-block」でハマるのか？——レイアウトの現場で直面する「隙間」の正体
フロントエンドの現場で、コーディングをしていて一番「イライラ」する瞬間の一つが、意図しない余白の発生ではないでしょうか。「`display: inline-block` にしたはずなのに、なぜか横並びの要素間に数ピクセルの隙間ができる」。
これ、新人から中級レベルのエンジニアまでが必ず一度は通る「洗礼」です。今日は、なぜブラウザがそんなお節介なことをするのか、そして私たちがどうスマートに解決すべきか、プロの視点で深掘りしていきます。
—
「inline」と「inline-block」の決定的な境界線
まず、基本のおさらいです。`display: inline` は、まさにテキストそのものです。文章の流れの中に溶け込むための存在であり、幅（width）や高さ（height）、上下のパディング（padding-top/bottom）を指定しても、「周囲の行の高さ」には影響を与えません。 これが `inline` の制約であり、美学です。
一方で `display: inline-block` は、いわば「二重生活者」です。
外側からは「テキスト（インライン要素）」として振る舞い、周囲のテキストと一緒に自然な流れの中で配置されます。しかし、内側は「ブロック要素」の顔を持っており、幅や高さ、マージンを自由に操ることができる。
このハイブリッドな特性こそが、ボタンやタグ、アイコン付きのテキストを並べる際に最強の武器となるわけです。
—
なぜ隙間（ホワイトスペース）ができるのか？
ブラウザのレンダリングエンジンは、`inline` や `inline-block` 要素を「テキストの一部」として扱います。
つまり、HTMLソースコード上で要素と要素の間に書いた「改行」や「スペース」を、ブラウザは「1つの空白文字」として律儀に解釈するのです。これが、CSSでマージンをゼロにしても消えない「あの隙間」の正体です。
—
実践：隙間を排除する「モダンなアプローチ」
この隙間を消すために、親要素に `font-size: 0` を指定するハックが古くからありますが、あれは子要素でフォントサイズを再定義しなければならず、管理コストが上がります。
現在、私が現場で推奨しているのは「フレックスボックス（Flexbox）」への移行ですが、どうしても `inline-block` が必要なケース（例えば、WYSIWYGエディタ内や特定のレガシーなUIパーツ）では、以下のテクニックを使ってください。
実用的なサンプルコード
—
シニアからのTips：いつ `inline-block` を選ぶべきか
現代のフロントエンド開発において、レイアウトの主役は間違いなく `display: flex` や `display: grid` です。それにもかかわらず、`inline-block` を積極的に採用すべきケースは明確に存在します。
1. 「テキストの一部」として配置したい場合： 文章の中にアイコンやラベルを挿入し、親の行送り（line-height）に合わせて自然に流し込みたい場合、`flex` よりも `inline-block` の方が圧倒的に意図通りに動きます。
2. 要素の幅を「コンテンツのサイズ」に依存させたい場合： `width: auto` で中身の大きさに追従しつつ、ブロックとしてのプロパティ（paddingやmargin）を当てたい時は、未だにこれ以上の選択肢はありません。
まとめ
`inline-block` は、単なる「横並びのための道具」ではありません。インラインの柔軟性とブロックの堅牢性を併せ持つ、高度な表現のためのツールです。
「隙間」という厄介な仕様と向き合うことは、ブラウザがどのようにソースコードを解釈しているかを理解する最高の練習になります。もし行き詰まったら、一度HTMLのソースコードを見て、「ここにある改行は、ブラウザにとって『文字』になっていないか？」と疑ってみてください。
その視点こそが、あなたを一段上のフロントエンドエンジニアへと引き上げてくれるはずです。現場からは以上です。コードの海を楽しんでください。
コメント