最近のCSSは、本当にできることが増えましたよね。少し前までならJavaScriptを書いていたようなUIや振る舞いも、今ではCSSだけで実現できるケースが珍しくありません。「JSを書かなくていい」「CSSだけで完結する」という言葉を目にするたびにCSSの進化を実感しますし、「アレもコレもCSSだけで実装できるのでは」と考えるだけで楽しくなってしまう人もいらっしゃるのでは。
ただ、その一方で、最近あらためて意識するようになったことがあります。CSSは「書ける」ようになるよりも、「壊さない」ほうがずっと難しい、ということです。そして厄介なことに、CSSが壊れてもエラーは出ません。
壊れたCSSはエラーを出さない
プログラミングをしていると、エラーが出てくれるのって実はかなり親切だと感じることがあります。例外が投げられ、スタックトレースが表示され、「ここが間違っている」と教えてくれる。少なくとも、何かがおかしいという事実には気づくことができますよね。
でも残念なことに、CSSはそうではありません。プロパティ名を間違えても、値が不正でも、ブラウザは基本的に何も言いません。ただ黙ってその指定を無視するだけ。画面は表示され、レイアウトもそれなりに整っている。ぱっと見では問題なさそうに見えるけれど、実際には意図したスタイルは当たっていない。
壊れているのに、何も起きない。
この「沈黙」が、CSSのいちばん面倒なところだと思っています。
エラーが出ないということは、一見すると優しさのようにも見えますが、実際には、壊れていることに誰も気づかない状態を生みやすくします。気づいたときには、なぜそうなっているのか分からない “謎のCSS” が積み重なっていて、触るのが怖い存在になっている。そんな経験がある人も、きっと少なくないはずです。
壊れ方を想像できるのって、実はすごく大切
CSSを書くときに本当に問われるのは、「その記述が正しいかどうか」ではないかもしれません。むしろ重要なのは、そのCSSが壊れたときに、どんな壊れ方をするのかを想像できているかどうか。
影響範囲を十分に考えないまま、便利なプロパティや新機能を振り回すのは、正直かなり怖い行為だな……と思っています。CSSは失敗しても教えてくれませんし、アプリが止まることもありません。そうして不具合はひっそりと広がっていく。レイアウトが一部だけ崩れたり、特定の条件でだけ表示がおかしくなったりする。その状態に気づいたときには、「なぜこうなったのか」を説明できる人が誰もいなくなっていることもあります。
壊れ方を想像できていないCSSは、たまたま動いているだけ、不具合が目立たないだけの可能性があると思っています。こうしたスタイリング、今は問題なく見えていても、構造が少し変わったりブラウザの挙動が変わったりした瞬間に簡単に破綻しがちです。そういう不安定さを抱えたままのCSSは、チームや将来の自分を確実に疲弊させます。
CSSでできる＝CSSでやるべき、ではない
CSSの進化によって、「CSSだけでできること」は確実に増えました。状態に応じたスタイル制御や、構造に依存した装飾、ちょっとしたインタラクションなど、以前ならJavaScriptが必要だった処理もCSSで書けるようになっています。
ただ、ここで一度立ち止まって考えたいのが「CSSでできるから、CSSでやる」という判断になっていないか、本当に「CSSだけで実装すること」に意味があるかという点です。
CSSは本来、「表現」のための言語です。そこに制御やロジックを無理やり詰め込むと、途端に可読性が低下します。なぜこのスタイルが当たっているのか分からない、状態の変化を追うためにDevToolsを開かないと理解できない、少し触るだけで別の場所が壊れそうで怖い。そんなCSSは、たとえJavaScriptを書かずに済んでいたとしても、健全とは言いづらいでしょう。
大切なのは、CSSで書くか、JavaScriptで書くかという二択ではありません。壊れたときに、誰が、どうやって直すのか。その未来まで含めて設計できているかどうかだと思っています。「JSを書かなくていい」ことよりも、「安心して触れる」ことのほうが、長い目で見ればずっと重要だと感じます。よく耳にしませんか？ 「保守性が高いコードってステキ」みたいな。
DevToolsの警告は、どこまで信用していいのか
CSSがエラーを出さない以上、頼りになるのはブラウザのDevToolsです。無効なプロパティやサポートされていない値が警告として表示されるのって、ありがたい機能ですよね。ただし、ひとつ注意しておきたいのは、DevToolsの警告は「答え」ではない、ということです。
警告が出ているからといって、必ずしも実害があるとは限りません。逆に、警告は一切出ていないのに、特定の条件下でだけレイアウトが壊れるケースも普通にあります。DevToolsはあくまで「気づくためのヒント」をくれる存在であって、安全性を保証してくれるわけではありません。
だからこそ、警告を見たときには「直すか、無視するか」ではなく、「これは何を意味しているのか」「無視した場合、どんな壊れ方をするのか」を考える必要があります。「警告が出ていないからOK」と判断したCSSほど、後から問題になるケースを何度も見てきました。警告がないから安心、という判断が一番危険なのかもしれません。
壊さないCSSを書くために意識したいこと
ここまで少し怖い話が続きましたが、では実際にどうしたらいいのか。少しだけ意識しておきたいポイントについて触れてみたいと思います。
新しいCSS機能は、まず単体で試す
いきなり本番のスタイルに混ぜるのは避けたいところです。そのプロパティがどこに効いて、どこには効かないのか、影響範囲をできるだけ言語化してみましょう。
言語化できると、「これは危ないな」や「これは取り入れても良さそう」が見えてきます。
「便利だから」という理由だけでは採用しない
CSSだけで実装できるなんて聞くと、さっそく取り入れてみたくなりますよね。でもその前に、今後のメンテナンスに想いを馳せてみましょう。自分ひとりで運用しているなら問題ないかもしれませんが、グループで、チームでだったらどうでしょうか。
あとから見た人が意図を理解できるかどうか。これを重視すると、ぶっ壊れCSS回避の近道になります。そして、DevToolsの警告は必ず一度疑います。その警告が、何を示しているのかを考えるところまで含めて確認するのがおすすめです。
どれも特別なことではありません。ただ、CSSを書く前に「壊れたときの姿」を一度想像する。それだけでも、書き方はかなり変わるはずです。
書けるCSSより、壊れないCSSを
CSSは、昔よりずっと「書ける」ようになりました。新しいプロパティや関数のおかげで、表現の幅も大きく広がっています。その一方で、壊れたことに気づきにくく、壊れ方も分かりにくく、影響が静かに広がる、という性質も強くなってきたと感じています。
壊れ方を想像する習慣をもつことで、より安心して触れるCSSに。そのほうが、結果的に長く生きるコードになる気がしています。
