ただいま新デザインバージョンのプレビュー中です。旧バージョンはこちら。不具合等はお問い合わせより報告お願いいたします。

読みやすいCSSってなんだろう 前編 自分にとってのわかりやすさ

Sassを使って便利だけれど複雑になるコード、ブラウザ対応で他人からみたら意図がつかめぬコード、少しでも読みやすくするには? CSSを担当することが多いスタッフ、CSS設計に興味があるスタッフが集まって語り合いました。

発行

読みやすいCSSってなんだろう シリーズの記事一覧

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

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

IE9〜11用のハックとはわからない

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

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

IE用のスタイルですよと明示

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

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

小山田:(笑)

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

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

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

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

意図を残す手段

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

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

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

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

高津戸:あるある(笑)。

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

*注:calc()について

calc()については、「今日から使えるCSS calc()」の記事に詳しく掲載されています。

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

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

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

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

Sassに計算してもらう

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

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

計算させずに結果とコメントを残す

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

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

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

高津戸:そうなんだ。

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

*注:Dart Sass

Ruby SassとDart Sassについては次のリンクなども参照してください。

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

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

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

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

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

高津戸:「あいつとはウマが合わねー!」とか、読みながら思うわけだ(笑)。

國仲:(笑)単に好みの問題ですけど。

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

國仲stylelintですね。

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

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

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

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

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

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

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

(後編に続く)

進行、構成:編集 丸山

高津戸 壮
PixelGrid Inc.
フロントエンド・エンジニア

Web制作会社、フリーランスを経て、株式会社ピクセルグリッドに入社。数多くのWebサイト、WebアプリケーションのHTML、CSS、JavaScript実装に携わってきた。受託案件を中心にフロント周りの実装、設計、テクニカルディレクションを行う。スケーラビリティを考慮したHTMLテンプレート設計・実装、JavaScriptを使った込み入ったUIの設計・実装を得意分野とする。
著書に『改訂版 Webデザイナーのための jQuery入門』(技術評論社、2014年11月14日)がある。
CSS Nite 2011ベストセッションにおいて、全170セッションの中から、ベスト10セッションに、CSS Nite 2013ベストセッションでは、全278セッション中、ベスト20セッションに選出。

小山田 晃浩
PixelGrid Inc.
フロントエンド・エンジニア

2006年よりWeb制作会社にてUI実装や運用業務を経験した後、2010年よりフロントエンド・エンジニアとして株式会社ピクセルグリッドに入社。これまでの経験の大半は大規模Webサイトの壊れにくいHTML/CSS設計、及び実装。また、SVG, Canvas, WebGLの扱いも得意としている。
外部に向けたアウトプットも積極的に行っており、カンファレンスでの講演などを多数こなしている。Tokyo WebGL Meetupの主催者。2011年から2015年まで5連続でMicrosoft MVP for IEを受賞。
著書に『Webデザイナー/コーダーのための HTML5コーディング入門』(共著:エクスナレッジ、2011年3月12日)や『CSS3デザイン プロフェッショナルガイド』(共著:毎日コミュニケーションズ、2011年5月28日)』などがある。

坂巻 翔大郎
PixelGrid Inc.
フロントエンド・エンジニア

大手ソフトウェアダウンロード販売会社、Web制作会社などで、マークアップエンジニア、プログラマ、サービス企画、ディレクターを経験。2013年、株式会社ピクセルグリッドに入社。HTML、CSS、JavaScriptなどをオールラウンドに担当。とりわけ、プログラマブルなCSSの設計、実装を得意とする。
趣味で作成したゲーム「CSS PANIC」は、JavaScriptを一切使わず、HTMLとCSSのみで実装。海外サイトで紹介されるなど話題となった。

國仲 義則
PixelGrid Inc.
フロントエンド・エンジニア

ECサイトで商品登録や電話対応などの傍ら、独学でWebコンテンツ制作を学び、学習で得た知見をブログで公開していた。HTML、CSS、ビュー周りのJavaScriptを主に担当。CSSアニメーション・トランジションを使用した印象的な表現を得意とする。特に、2011年と2013年の2度にわたって作成した「CSSとSVGによる曇りガラス効果」(BlogCodePen)は、似たような表現が使われているiOS 8の発表後に国内外で注目された。2017年にピクセルグリッドに入社。

丸山 陽子
PixelGrid Inc.
編集

Mac雑誌の編集者を経験後、フリーランスのエディター/ライターとして独立。パソコン系雑誌やデジタルカメラ雑誌、iPhone/iPadの初心者向け書籍などの編集や執筆に携わる。2015年にピクセルグリッドへ入社し、「CodeGrid」の編集を担当する。

この記事についてのご意見・ご感想 この記事をTweet