第23章　DevTools で、見た目の理由をたどる

Web ページを作っていると、「この空白は、どの CSS が作っているのだろう」「同じ位置へ置いたはずなのに、なぜ端がそろわないのだろう」と思うことがあります。

ブラウザには、表示中の HTML や CSS を調べるための DevTools（デベロッパーツール）があります。日本語では「開発者ツール」とも呼ばれます。Chrome、Firefox、Safari などで見た目は少し違いますが、ページの内側をその場で確かめられる点は同じです。

DevTools が教えてくれるのは、ブラウザが使った値や、要素の箱の大きさです。その数字が美しいか、言葉が分かりやすいかまでは教えてくれません。画面で気になった場所と、コードで起きていることを結びつけるために使います。

23.1 同じ空白に見えても、作り方は違う

画面に見える空白は、いつも一つの margin から生まれるわけではありません。CSS には、場所の違う空白がいくつかあります。

まず margin は、要素の輪郭より外側に空間を作ります。

図 23-2A の二つの箱には、どちらにも輪郭があります。輪郭と輪郭の間にあるのが、箱の外側の空間です。背景色はこの空間へ広がりません。

padding は、箱の輪郭と中身の間に空間を作ります。

図 23-2B では、薄い色の部分まで外側の箱に含まれています。ボタンの文字と輪郭の間や、カードの端と内容の間によく使います。

gap は、Flexbox や Grid で並べた項目の間へ、親要素がまとめて空間を配ります。

カードを三枚並べるとき、それぞれへ別々の余白を付ける代わりに、並べる親へ gap を指定できます。項目の数が変わっても、項目と項目の間だけへ同じ空間が入ります。

文字にも、目に見えにくい箱があります。line-height で決まる一行の高さは、文字の輪郭より大きいことがあります。

見出しの上下が広く見えるとき、margin だけでなく、この行の高さが関係していることがあります。だから DevTools では、「空白が何 px か」だけでなく、「どの箱の内側か、外側か、箱と箱の間か」を見ます。

一つの要素には、複数の CSS が当たることがあります。DevTools の Styles 欄には、その候補が並びます。

図 23-3A の gap: 16px には取り消し線があります。これは、その指定が候補にはなったものの、別の指定に上書きされたという印です。

実際に使われているのは gap: var(--space-form) です。--space-form という名前の箱に入った値を調べると、28px だと分かります。CSS 変数は、同じ間隔や色を何か所でも使えるよう、値へ名前を付ける仕組みです。

DevTools の Computed 欄では、さまざまな指定を計算したあと、ブラウザが最終的に使った値を見られます。しかし、そこに 28px と表示されても、28px がデザインの正解だという意味ではありません。分かるのは、今のブラウザが 28px を使っているという事実です。

カードの左端がそろわないとき、目だけでわずかなずれを追うのは大変です。DevTools には、ページの上へレイアウトの補助線を重ねる機能があります。

図 23-4A では、三つのカードの列へ青い線を重ねています。カードがどの列に入り、列と列の間がどれくらい空いているかを一度に見られます。

補助線の色やボタンの場所はブラウザによって違います。青色を覚える必要はありません。大切なのは、画面で見えたそろい方が、どの列や間隔の規則から生まれているかを見つけることです。

三枚のカードの間が、どの指定から生まれたのかを調べます。最初の画面では、親要素の gap: 24px が使われています。

DevTools で、この gap だけを一時的に無効にします。

ほかの CSS を変えていないのに間隔が消えたため、この空白を作っていたのは gap だと分かります。値を 32px へ変えれば、広げた場合の見た目もその場で試せます。

DevTools で行った変更は、普通はページを再読み込みすると消えます。これは原因を調べるための試着です。採用する変更は、制作中の CSS へ書き戻し、ほかの画面幅や状態でも崩れないかを確認します。

キーボードで Web ページを使うと、現在選ばれているリンクやボタンに輪郭が出ます。この状態をフォーカスと呼びます。

DevTools では、フォーカスしたときの見た目だけを強制して表示できます。

図 23-6A から、輪郭の太さや色は分かります。しかし、実際にキーボードだけで確認ボタンへ移動できるか、どの順番で選ばれるかは分かりません。

そこで Tab キーを実際に押します。

図 23-6B では、戻る、確認、送信の順に移動し、送信ボタンへ到達しました。見た目を強制する確認と、実際に操作する確認では、分かることが違います。

同じように、通信エラーの色だけを表示しても、送信中から失敗へ正しく変わるかは分かりません。通信を本当に失敗させると、処理の流れまで見られます。

DevTools は、CSS の値、要素の大きさ、上書きされた指定、並び方を調べるのが得意です。どこから空白が生まれたのか、なぜ要素が重なったのかを、コードまでたどれます。

一方、利用者が「確認」と「送信」の違いを理解できるか、文章を読んでどう感じるか、ブランドの雰囲気に合っているかは、数値の欄には表示されません。

DevTools を使う目的は、数字を集めることではありません。画面で見えたことと、HTML や CSS で起きていることをつなぎ、「なぜこの見た目になったのか」を説明することです。原因が分かったあと、どのように直すかは、ページの目的と画面全体へ戻って考えます。

Chrome for Developers「Inspect and change the page」— DevTools で HTML と CSS を確認する公式案内です。
Firefox Source Docs「Page Inspector」— Firefox の開発者ツールで要素とレイアウトを確認する案内です。
第17章「人間は、反応がないと不安になる」— 操作後の状態を画面へ返す理由を扱います。