CSSとの付き合い

——今回は、「読みやすいCSS」というテーマで、ピクセルグリッドのエンジニアに話してもらおうと思います。まずは、自分のCSS歴を含め、自己紹介からお願いします。

小山田 晃浩：2006年よりWeb制作会社にいて、その頃からずっとCSSを書いています。前の会社ではあまりJavaScriptはやっていなかったんですけど、ピクセルグリッドに入ってからは、WebアプリケーションでJavaScriptも書いています。それでもCSSもけっこう書いています。ずっとCSSを書いていますね。

高津戸 壮：CSSを一番書いていたのは前の会社ですね。そのときは、大きなコーポレートサイトとか、CMSで大量のページをつくるとか、そのためにテンプレをつくることが多かったので、どうやって書いたらいいのかということを日々思い悩んでいました。

その後、この会社に入ってからも最初はCSSを書いていましたけど、最近は業務的にもWebアプリが多くなったので書いていないです。でも、CSSの設計の話などはずっと興味があって追いかけています。

國仲 義則：ピクセルグリッドに入る前の会社は全部一人でやらなくちゃいけなかったんで、HTMLとCSSもJavaScriptも全部やっていたことが多かったです。その中でもWebサイトをつくることが多かったから、やっぱりCSSを書く比率は高かったですね。コーポレートサイトとかキャンペーンサイトを多くやっていたので。また別の会社では、Webサービスの管理画面などのサービス系も手がけました。たいして複雑なものは書いていなかったですけど、ひたすらテーブルがある、というようなページをつくっていました。

基本的に一人でやっていたから、自分が読みやすければいいみたいなところはありました。

高津戸：つらい（笑）。

國仲：（笑）。今は主にHTML/CSSをやりつつ、ちょっとしたUIのJSを書いているかんじですかね。ピクセルグリッドに入ってからは基本的にすでにあるコードをいじっているので、読みやすい書き方というよりは、すでにあるものに合わせて書くというかんじです。

坂巻 翔大郎：僕はずっとCSSがメインですね。最近は長期で大きいプロジェクトにも関わっていて、運用前提のものが多いです。CSSの読みやすさは……コンポーネントごとなどに分けてあればいいかな、みたいなところはあるかなと。ひとつのスタイルがすごく長いと、僕は読みづらいかな。

CSSとJSで、「読みやすさ」は違う？

——CodeGridでも過去に、コードを読みやすくするにはどうしたらいいか？ という観点からの記事をいくつか掲載しました。

• コードスタイル座談会
• 読みやすいコードのために

これは主にJavaScriptのコードの読みやすさを考えた記事だったのですが、そもそも今回お話するCSSの読みやすさとは、見るところや考え方が違いますか？

小山田：JSはロジックなどが難しくなりがちで、気をつけないとすぐ読みにくくなっちゃうんですよね。でも、CSSというのは基本的にレイアウトの定義のまとまりなので、多少雑になっても、JSほど複雑にはならないっていうのがあるかなと。まあ、もちろんCSSでも読みやすいコードというのはちゃんとあるけれども、CSSはJSほど理解不能にはならない。がんばれば読める。読みにくくても。

読みにくさというのは、たとえば、CSS特有のカスケーディングという部分です。CSSのスタイルが暗黙的に継承されていくとすごく読みづらくなる。そういうことはあるかな。

國仲：でもまあ、コードが読みにくかったとしても、最終的にDevToolsを開いて、「これ何やっているんだろう？」と見れば、どれが最終的に適用されてるのかというのがわかる。

小山田：ああ、そうですよね。

高津戸：CSSの場合だと、HTMLとセットにして考えないといけないということがありますよね。CSSだけ見れば、セレクタがあってプロパティがあって、それぞれが超絶読みづらいというわけじゃないんですよ。それに対応するHTMLとどういうふうに関係しているのかとか、別のところで競合する書き方されているんじゃないかとか、そういうことは読みやすさに関係しているかと思います。

小山田：確かに。JSとは違った、読みづらくなるポイントがありますね。

高津戸：JSはスコープみたいなものがカチッとつくれるんで、そこから外に漏れないようにするというのはある意味難しいことではない。でもCSSの場合は書いたものがどのHTMLに影響するのかがパッとわからないので、そのあたりが難しい。だからCSSの設計思想みたいな話が出てくるわけで。

みんなが言っているように、たいていのコードなら読めないわけじゃない。でも、スケールしたときにどうにかする仕組みがCSSにはないので、そういう場合には本当に読みづらくなっていっちゃうかなと思います。

ハックやSassのわかりにくさ、伝わりにくさ

——それでは、「読みやすいCSS」について、詳しく考えていきたいと思います。まず、自分が書くものから聞かせてください。自分で書いたCSSも、あとから読み返したらどんどんわかりにくくなっていくものでしょうか？ 「一ヶ月前の自分は他人」なんて言葉もありますが（笑）。

小山田：自分の場合は、一ヶ月前の自分は……まあ自分ですね（笑）。自分のCSSの書き方は、長い年月が経ってもあんまり変わらないので。だから、3、4年前から続いているプロジェクトがあるけど、「まあ、ちょっとは古くは感じるけれども自分のコードは読めるかな」という感じがします。そんなに革新的には自分の中のルールは変わっていないかな。

國仲：時間が経っても、読めはしますけどね。ただ、あとから見たら「これ、なんかイケてないんじゃ……」みたいなことがありますね（笑）。もっとナイスなやり方あっただろうみたいな。たぶん、そのときは古いブラウザにも配慮した書き方をしなきゃいけなかったりしたんだろうけど。

坂巻： もうちょっといいアプローチがあったなーとか、思うよね。

國仲：そのときは忙しくて視野が狭まってたから気付かなかったとか、単に思いつかなかったとかそういうことなんですけどね。

小山田：さっき、CSSはJSと比べると複雑にはならないと言ったけれども、Sassが登場してから効率のいいfunctionとか、プログラミング言語っぽい、ちょっと複雑なことが書けるようになってきましたよね。そういった部分では自分が前に書いたものを見ると、もうちょっといい書き方があったなあとか、もうちょっといい関数の定義の仕方があったなぁとか、Mixinはこうすればよかったなというのはあります。

たとえば、CSSの場合はプロパティ群の羅列よりは、意味のある羅列であれば、名前付きの関数にしたほうが、出力結果は同じでも読むときにはわかりやすいですよね。

アイコンを出すときでいうと、プロパティを並べるとこういうふうになる。

.menuItem0{
  content: "\E643";
  font-family: 'icon';
  speak: none;
  font-style: normal;
  font-weight: normal;
  font-variant: normal;
  text-transform: none;
  line-height: 1;
}

でも、こういうふうに、関数にしたほうが読みやすい。

.menuItem0{
  @include icon( "home" );
}

魔法のCSSハックがあった場合でも、自分以外は初見で何かわからない。タイポなのか、意図的なのか。意図があるならその意図は何か？ 関数にして名前を付ければ、それが何を意味するのか想像しやすいですよね。

たとえば、こんなコードです。

@media screen\0 {
  .SomeBlock{
    min-width: 979px; } }

このCSSは知っている人が見ればscreen\0はIE9〜11用のCSSハックとわかる。でも普通はscreen\0なんて書いたら、CSSエラーですよね。本当なら@media screen{ ... }なのにおかしいとしか思えない。でも実はIE用のハックなんです。だったら、次のように書いておけばIE用という意図がわかる。

@include onlyIE{
  .SomeBlock {
    min-width: 979px; } }

國仲：それで言うと、自分で書いたのにあとから読めなくなったやつは、CSSでつくった超複雑なキーフレームアニメーションがありますね。あとでコードを見たとき、何をやっているかわからない（笑）。

小山田：（笑）

國仲：Sassで吐き出したキーフレームだったんで、全体的に難しいキーフレームになっていて。ちゃんと要件どおりに動いているんですけれどもね。書いてから何ヶ月か経ってコード見直したら、「これ、何やっているの？？」ってなりました。

坂巻：ただのCSSじゃないですからね、Sassの機能を使って書いているから。そこにややこしさが出てくるのは、あとで見て思う。

國仲：CSSを見ればどういう動きかというのは想像できるんですけれども、Sassだけ見てもわからないというのがあって。

坂巻：意図がわからなくなっちゃうよね。だから、たとえばクリックしたときにアクティブになるクラスが付くとか、そういうのもコメントを書いてないと「なんでこれ、こうなんだろう？」と、わからなくなる。Sassの複雑なMixinをつくるときも同じで、その意図はなるべく残すようにしていますね。意図を残すというのは、CSSに限らず、JSも一緒だと思うけれど。

意図を残す手段

——意図を残す手段の一つとしては、コード中にコメントを書くということがありますか？

坂巻：僕はコメントを書いておきますね。レガシーな人間だなぁとは思いますけど。GitHubのPull Requestのコメントなどでもいいと思います。実際の案件の背景にややこしいことがあったりすると、そういうのもコメントで残したりしますね。「しょうがないんです！（＝僕のせいじゃないんです）」みたいな（笑）。「IEのバグです」とか。

——そういうのはなるべく残すべき？

坂巻：僕はなるべく残したほうがいいと思いますね。案件特有の事情とか、バグとか、どうしてもしょうがない対応とかあるんで。それがないと「なんでここ、116pxなの？」「……それは、いろいろあって、です」みたいな話になる。それじゃわからない。

高津戸：あるある（笑）。

坂巻：そういうことは、なるべくわかりやすく書いておいたほうがいいと思います。たとえば計算式がプロパティの値で使えるcalc()というのがあって*、それを使うと全体の幅からいくつ引いた幅、なんていう指定ができます。

これを使うと、たとえば、元のフォントサイズから2px引く、みたいな計算ができるんです。calc(14px - 2px)って書いておけば、12pxになるじゃないですか。でも、calc()を使わなくても、そこに、マジックナンバー的に12pxって書くこともできる。

——そうすると、あとから読んだときに「なんで12pxって出てきたの？」ってなっちゃうわけですね。算数の問題と同じで、どうやってこの答えが出たのかを残しておくということか。

坂巻：そう。意図があるなら書くということです。コメントで計算式を書いておくとか、「パディングとこれを足した値です」って書いておくとか。そういうのがないと全然わからなくなっちゃう。

小山田：自分も、Sassの場合は謎の計算式から導き出された、謎の数値みたいのについてはコメントで意図を残しますね（笑）。ただコメントで残さなくても、Sassはプリプロセッサーだから、こういうように書けば事前処理して計算して出力してくれる機能はあるんです。

.selector {
  font-size: 10px * 2;
}

でも、計算式が積み重なったときにビルドが遅くなるのが困っちゃうかなあ、っていうのがある。だから、Sassに計算させるのではなくて「自分で計算してフィックスした値を書いてコメントで計算式を残す」っていうのがあります。

.selector {
  font-size: 20px; // = 10px * 2
}

高津戸：へー、それってけっこう目に見えて遅くなる？

坂巻：量が多くなると、ですかね。Sass functionとかだと露骨に遅くなりますね。フォントサイズをremにするfunctionをつくってそれをたくさん使うと、遅いなあ、って思いますよ。

高津戸：そうなんだ。

坂巻：まあ、でもそれはRuby Sassのころの昔の話なんで、Dart Sass*になった今はたぶん速くなっている。それが便利なら使うけど、素で書いたほうがいいかなというときもあるということですね。

——その場合は意図がわかるようにしましょう、ということですね。

正しい書式はないけど好みはある

——JSでもそうですけど、読みやすい／読みにくいって、好みの問題も多少はありますよね。

國仲：コードスタイルとかは気になるんですけれども、それは個人の好みとか、プロジェクトによって違いますよね。たとえば、HTMLのコードに合わせてインデントする人もいると思いますけど、俺これは好きじゃないんです（笑）。でも、これは読みづらいというか、好みなんで。

よもつさん（小山田）もネストするじゃないですか。だから、「あー、よもつさんもネストするタイプか……」って。

高津戸：「あいつとはウマが合わねー！」とか、読みながら思うわけだ（笑）。

國仲：（笑）単に好みの問題ですけど。

高津戸：CSSのコードスタイルって、Lintツールみたいのって使って揃えている？

國仲：stylelintですね。

小山田：あれでエラーが出るようにして、直したり。

坂巻：今だったらstylelintと、Prettierを使えば、スタイルのフォーマットは統一できると思う。雑に書いてもPrettierが統一してくれたりとか、できないわけじゃないけど。

小山田：でも、あんまり入れていないかなあ。

——1人で書くことが多いからですかね。

坂巻：最低限やっているのはEditorConfigぐらいですね。

高津戸：複数人でやったり、長期間のプロジェクトの場合はツールでやったほうがいいと思いますけどね。特にGitで管理していると、インデントをいじったりしているとすごいdiffが出る。1つのファイルの中で2つのスタイルが混ざっていると気持ち悪くなって直してしまうと、さらにまた変なdiffが出るとか、よくないことしか起こらないので。

——人と一緒にCSSを書く場合に読みやすいということは重要なんですね。そのあたりをもう少し聞かせてもらえますか？

（後編に続く）

進行、構成：編集 丸山