CSSを書いていると、ときどき「これはさすがにバグでは？」と思う場面があります。指定したはずのスタイルが効かない。z-index を上げても前に出てこない。余白を足したつもりなのに、なぜか見た目はほとんど変わらないなどなど……。
もちろん、本当にブラウザ側の不具合だった事だってあります。ただ、少なくとも日々の実装で出会うおかしな挙動のいくつかは、ブラウザが素直に仕様通り動いているだけだったりします。
CSSって自由度が高いように見えるかもしれませんが、実は思っている以上にルールベースです。そして、そのルールが見た目の直感と少しずれているとき、私たちはそれを「バグっぽい」と感じるのかもしれません。今回は、そんな「仕様通りなのにバグっぽく見えるCSS」について、いくつかよくある例を見ながら考えてみたいと思います。
CSSは、ときどき壊れているように見える
CSSの厄介なところは、「効いているかどうか」が直感と一致しないことがある点だと思います。JavaScriptであれば、エラーが出れば止まりますし、値がおかしければそれなりに分かりやすく壊れます。一方CSSは、多少おかしな指定をしても、それっぽく動いてくれちゃう。
そしてその「それっぽさ」が、ときどき誤解を生んでいるように感じるんですよね。実際にはルール通り処理されているのに、ビジュアルとしては壊れているように見える。このズレが「バグっぽさ」の正体なのかもしれません。
余白をつけたのに、余白が増えないように見える
よくある例のひとつが、いわゆる margin の挙動です。
上下に margin を指定したはずなのに、思ったほど余白が増えていないように見える。あるいは、親要素との間に余白をつけたつもりが、どこかに吸収されたように見える。このあたりは margin の相殺（margin collapse） の影響を受けていることが多いです。
複数の余白が単純に足し算されるわけではなく、条件によってはひとつにまとめられてしまうんですよね。仕様としては一貫しているのですが、見た目の期待とは少しズレます。だから「マージン足したのに開かないんです」と言って慌て、時間を溶かしてしまう悲劇が生まれたり生まれなかったりしているわけです。
「余白を足したのに効いていない」というよりは、「余白は計算されているが、思っている形では現れていない」状態です。知っている者にとっては “上手くやればいいだけの事” でも、知らない者にとっては怪奇現象ですよね。
z-index を上げたのに、前に出てこない
もうひとつ分かりやすいのが、z-index の挙動です。
要素を前面に出したくて z-index: 9999; のように大きな値を指定したのに、なぜか背面のまま動かない。これも「バグでは？」と思いやすいポイントです。
ただ、ここで関係しているのは スタッキングコンテキスト です。z-index は単純な “数の勝負” ではなく、どのコンテキストの中にいるかで比較の土俵が変わります。別のスタッキングコンテキストに属している要素同士は、そもそも直接比較されません。
つまり、次のようなことが言えます。
- 数字を大きくすれば必ず前に出るわけではない
- そもそも別のレイヤーで並べられている可能性がある
これも「効いていない」のではなく、「そのルールの中では正しく処理されている」状態です。
スタイルは当たっているのに、思った見た目にならない
DevToolsで確認すると確かにCSSは適用されているのに、それでも見た目が意図と違う、といったケースもあります。このとき疑うべきなのは、詳細度（specificity）や継承、あるいは初期スタイルです。
たとえば、次のような状況。
- より詳細度の高いセレクタに上書きされている
- 親要素からの継承が影響している
- ブラウザのデフォルトスタイル（いわゆる UA stylesheet）が効いている
この場合、「スタイルが当たっていない」のではなく、「複数のスタイルの結果として、その見た目になっている」と考える方が近いかもしれません。CSSは常に最終結果しか画面に出てこないので、その裏で何が競合しているかを意識しないと、原因が見えにくくなります。
CSSは見た目ではなくルールで動いている
ここまでの例に共通しているのは、CSSがあくまでルールベースで処理されている、という点です。
私たちはつい、
- 余白を足したから広がるはず
- 数字を大きくしたから前に出るはず
- 指定したからその見た目になるはず
といった、見た目の期待で判断してしまいがちです。
でもブラウザは次のような規則に従って、淡々と計算をしています。
- ボックスモデル
- レイアウトアルゴリズム
- 優先順位とカスケード
その結果がたまたま直感とズレたときに、それが「バグっぽい」と感じられるのだと思います。
バグを疑う前に、ルールを疑ってみる
もちろん、本当にバグであるケースもゼロではありません。ただ、日常的に遭遇する現象の多くは、仕様の範囲内に収まっていることがほとんどです。
そう考えると、「これは壊れているのか、それとも、そういうルールなのか」と、一度立ち止まるだけで見え方が少し変わります。
DevToolsで適用されているスタイルを辿ったり、どのプロパティがレイアウトに影響しているかを確認したりすることで、“結果” ではなく “理由” に近づけるようになります。CSSは書く技術でもありますが、同じくらい「読み解く技術」でもあるのかもしれません。
最近はAIがCSSを書いてくれる場面も増えてきましたが、こういった「仕様通りの挙動」は当然そのまま出力されます。一見して違和感のあるコードでも、ルールとしては正しく成立していることも多く、結果として「動いてはいるけれど、どこか扱いづらいCSS」になってしまうこともあります。
だからこそ、出てきたコードをそのまま受け入れるのではなく、「なぜそうなっているのか」を一度立ち止まって考えてみることは、これまで以上に大事になっているのかもしれません。
CSSは、ときどき不親切に見える
思った通りに動いてくれないとき、それはバグのようにも感じられます。
ただ、その多くは気まぐれではなく、きちんとしたルールの上に成り立っています。そのルールが直感と少しズレていることがある点は確かですが、挙動そのものは一貫しています。
「バグっぽい」と感じたとき、すぐに切り捨てるのではなく、なぜそうなっているのかを少しだけ追いかけてみる。その積み重ねが、CSSとの距離を少し縮めてくれるのかもしれません。
