『web制作者のためのcss設計の教科書』出版記念イベント@大阪に行ってきたので考えをまとめてみました

僕が読んできた技術書のなかで、いちばん影響を受けたのは「Web制作者のためのCSS設計の教科書」というCSSについての最新の手法を解説されている本です。その著者である谷拓樹さん（@hiloki）が大阪で出版記念イベント『Web制作者のためのCSS設計の教科書』出版記念イベント@大阪を開催されると知ったので、参加して話を聞いてきました。
すべては咀嚼できなかったんですが、少し考えをまとめていきたいと思います。（メモはとっていましたが、正確でないところもあると思うので注意してください）

｢メンテナブルであり続けるためのCSS設計｣谷拓樹

今回は3人の登壇者がそれぞれ30分のセッションをされました。まずは谷拓樹さんから。

CSSが生まれてから今年で20周年。はじめはシンプルな装飾やレイアウトだけだったが、CSS3によりアニメーションやフィルタなど機能は広がってきている。
それでも変わらないのはCSSの壊れやすさ。シンタックスがシンプルな分、記述やメンテナンスをおこない、時間が経つにつれてどうしようもないコードは必ず出てきてしまう。

だからこそ、壊れた時に修復ができるように設計をすることが大切。

オブジェクト指向のCSS

例えば、左に画像があり右にそのタイトルやキャプションが付くというレイアウト。プロフィールや書籍のリンクや関連記事など同じようなパターンがあることに気付く。

OOCSSという手法を使用して、スタイルを（レゴのような）部品単位で記述するオブジェクト指向に基づいたCSSを設計することを考えてみる。.mediaというdivのなかに.media__imegeという画像が配置されるブロックと.media__bodyというテキストが配置されるブロックをラップする。ここに共通するスタイルだけを記述する。それ以外のパターンはクラスを追加してスタイリングしていく。

.media {

}

.media__image {

}

.media__body {

}

OOCSS以外にもSMACSS,BEM,SUIT CSS,AMCSS,MCSS,FLOCSSなどの手法がある。

OOCSSで再利用できるクラスを作ってみると、そのスタイルの重要な部分を知ることができるので、それ以外の装飾はあまり考えることなく記述できるような気がします。
プロパティによっては特定のパターンにしか使えない場面もあるので、使い分ける自分なりのルールも考えることができると思います。

CSS設計のポイント

セレクタはできるかぎり少なくして、意図を明確にする。

クラスを最小限に抑える

クラスの命名規則には「BEM」を使用している。.media .imageとマルチクラスにするとクラスが増えていき管理が難しくなってくる。.media__imageとひとつのクラスだけに指定することでそれを解消できる。

略称は極力しない

誰が見ても意図が明確であることが大切。.wdtのような一般的でない略称は.widgetとする。

プレフィックスと汎用クラス

コンポーネントクラスには.c-を汎用クラスには.u-といった具合にプレフィックス（接頭辞）を付けることで意図を明確にする。クラス名が重複することも防ぐことができる。

また汎用クラスは「Emmet」を命名のベースにしている。

1 2	.u-fl { float: left; } .u-mts { nargin-top: 10px; }/* margin-top small */

セレクタの単語を統一する

ヘッダー部分を示すセレクタの単語にはheadやheaderがある。こういった単語の統一をするために「ボキャブラリーガイド」を作っておく。

CSS設計をどの手法にするのか以前に、どういった単語を選ぶのかがまず重要だと最近考えていました。.containerなのか.boxなのか.frameなのか、悩んでいる時間がすごくもったいないし、後々メンテナンスが大変になってくる予感がします。

JavaScript専用のクラスを用意する

CSSとJavaScript（jQuery）は同じひとが管理するとは限らない。.js-というプレフィックスを別に記述してJavaScript専用にしておく。

スタイル属性は使用しない

style属性でHTMLに直接スタイルを記述すると、思わぬところでハマってしまう。詳細度も高くなってしまうのでおすすめしない。

使い回せばいい訳ではない

コードの再利用は大切。でも機能がちがうなら別々に管理した方がいい。

難しそうならデザイナーと相談してみる

カンプ通りにコーディングするのもいいけど、技術的・メンテナンスが大変などの理由があれば、デザイナーに話をしてみる。

CSSプリプロセッサは設計の問題を解決するのか？

Sassは確かに便利でOOCSSも@extendでスマートにシングルクラスで再現することもできる。でも複雑になりすぎたり、CSSのコード量が逆に増えてしまったりする。使用する機能にルールを作っている。

Partialと@importでファイルを分けて管理する
@mixinは簡単なものだけを使用する
ネストする階層は制限をかける
色の管理などに変数を利用する

ファイルを分割して管理する機能は「GRUNT」でもできるし、Sassよりも使いやすい。@extendや複雑な@mixinは使わないようにしている。

Sassは今試しているところなんですが、プログラム的なこともできるので、多機能ですが使いこなしが難しそうな印象です。使用されている機能はどれも基本的なものですが、それだけでもSassを使うメリットが感じられるものばかりです。
特にネストと変数は修正をする時に一括で変更できたりするので、手放せなくなります。

｢CSSI: CSS Investigation / CSSコードレビューの仕方教えます｣斉藤祐也

ふたりめは斉藤祐也さん。Rich MediaのUXエンジニアでサイバーエージェントでは様々なプロジェクトのコードレビューをされたそうです。

コードレビューをする理由

コードは増えれば増えるほどバグが出やすくなる。またCSSは影響する範囲が広いので削ることが難しいことを知っておく。

コードは書く時間より、読む時間の方が多い。それだけにルールを設けて一貫性を保つ必要がある。そのうえでMinifyなどのビルドプロセスからパフォーマンスを考える。

コードレビューの方法

書き込むのはコメントだけ。修正とコードレビューは一緒にしないこと。コミュニケーションをしっかりとりながらコードレビューをすること。
コードレビューの手順としては以下の通り。

ディレクトリとファイル構造を整理して、変更するにはどのファイルに記述すればいいのか明確にしておく
記述する場所はコメントを使って分割しておく。Minifyでコメントは消えるので、パフォーマンスに影響は与えない
StyleStatsやCSS Digを使用してページ全体のファイルサイズや使用している（していない）セレクタなどを調べる
CSS Lintで全体的な妥当性を調べる
Type-o-maticでフォントの重複とパターンを、CSS Colorguardで近い色を抽出する
Autoprefixerでプレフィックスの見直し（Can I Useのデータを元にしている）
uCSSで未使用と重複するCSSを調べる

コードレビューの原則

OOCSSやSMACSSの考え方を取り入れる。

構造と見た目を分離する
HTMLの構造に依存しないCSS
スタイルは継承のみでリセットはしない
可能な限りセレクタは最小限にする
マジックナンバー（特に理由のない値）を使用しない
ドキュメントはコードレビューの前に書く

マジックナンバーはvertical-alignを使用する時に、大体何pxで真ん中ぐらいになるといった使い方をしてしまいがちですよね。ちがうプロパティで再現ができないかとか、なるべく相対値を使うなどをした方がいいのかなと思いました。

｢CSSオジサン、この先生き残るためには｣石本光司

さいごは石本光司さん。大学ではデザインを、卒業後はWebデザイナーとして、現在はデベロッパーやフロントエンドをされているようです。

誰が給料を決めるのか？

デザインは抽象的で評価が難しい。評価には数字に表すことが必要だと感じ、Googleアナリティクスを活用することにした。
例えばコンバージョンを向上させた時にはパーセンテージから金額に数字を置き換えた。評価されたいなら、評価基準になる何かを提示できるようにしないといけない。

製造業では改善した効果を示すために時間やお金に換算することがあります。デザインでは数値化が難しいことも多いと思うんですが、自分を評価してもらうためには何が必要なのか考えることは必要なことなのかと思いました。

効率化

SassやGruntが出始めた当初、効率化できる反面使いこなせているひとが少ないと感じた。自分だけが効率的になっても、会社の規模が大きければ大きいほど効果は小さくなる。それなら教育をして効果を高めて、その成果が自分の実績になると考えた。

MapleというCSSフレームワークをGitHubで公開した。オープンソースな場に公開することでノウハウを共有して、更に効率化することができる。

StyleStatsも公開。良いCSSと悪いCSSを目で見て分かるようにした。node.jsを使用して自動化しているので大規模なサイトでもすぐに評価することができるのがメリット。

英語はどこまで必要か？

Webデザイナーも英語ができないといけないと最近よく言われている。どこまでできればいいのか？

読むことができれば、海外の記事をすぐに読むことができる
聞くことができれば、動画やPodcastなど幅が広がる
書くことができれば、自分で作ったフレームワークなどを紹介することができる
話すことができれば、海外でおこなわれるカンファレンスに登壇することもできる

CSSConf.Asiaは日本ではなくシンガポールで開催される。それ以外のカンファレンスも日本では開催されない。それは単純に日本人は英語ができないからだと考えている。優秀なひとも多いのにもったいない。

身につけるためには

目標を宣言して
考えるだけでなく、環境を変えて動いてみる

まとめ

数値化して伝える努力をする
プラスαの技術を身につける
変化できる環境に自分を置く

漠然と疑問を持つことは多分誰でもしていると思います。でもそこから何か行動をおこして、実際に結果を出しているのは純粋にすごいことだと思います。
このセッションを聞いて、感じるものがあったひとは多かったはずです。僕もそうです。

パネルディスカッション＆質疑応答タイム

意識を高く持たせるためにはどうすればいいのか？

谷さん：自分の実績を見せる。

石本さん：CSSを実際に書かせてみる。過去のコードを見せてみる。数年前でもずいぶんと変化しているのが分かると思う。

斉藤さん：数字を見せること。経営判断には数字が必要になる。

予算がない案件では充分な時間がとれない

谷さん：数字でデメリットが示せるのであれば、それを提示する。

コードの品質を数値化する方法

石本さん：StyleStatsを使う。かたちとして見えるので数字ではないけど、良い悪いの判断はできる。

谷さん：メンテナンスにかかる追加の時間などは数字として提示できる。

コードレビューを楽しくするための手段

斉藤さん：他人が書いたものだし、楽しいものではない（笑）。プロジェクトの成果やメンバーの声を聞くとやりがいを感じる。
手段ではなく目標（目的）を先に考えることが大事。時間はかかるものなので。

サイバーエージェントでは新入社員などは最初から技術力があるのか？どういう教育をしているのか？

谷さん：地道に教育はしている。コードレビューもその都度している。

Web制作者のためのCSS設計の教科書モダンWeb開発に欠かせない「修正しやすいCSS」の設計手法

posted with ヨメレバ

谷拓樹インプレス 2014-07-24

Amazon

Kindle

楽天ブックス

フロントエンドエンジニア養成読本 [HTML、CSS、JavaScriptの基本から現場で役立つ技術まで満載! ] (Software Design plus)