はじめに
谷拓樹さんのWEB制作者のためのCSS設計の教科書を読み、自分なりにまとめたものです。
自分のメモとして残しておきたいので、詳細を多少端折っていますので、気になる方は購入してみてください。
数回に分けて投稿する予定です。
コンポーネントの運用
CSSのコメント
CSSのコードだけでは、そのコンポーネントをどのように使うのかどのようなマークアップでそのスタイルが成立するのかは読み取れない。それらを共有するためのシンプルな方法は、コード内にコメントを残すことである。
/*ボタン
概要:
<button>または<a>などのインタラクション要素をボタンUIにする。
……………………….
マークアップ例:
<a class”btn”>ボタン</a>
*/
.btn {
……….
}
使用しているプロパティがどのような目的で使われているか、といったこともコメントとして残しておくのもオススメ。
例えば、overflow:hidden のようなプロパティは、本来期待する、要素から溢れた場合のスタイルを決めるのか、それともfloatのクリアのために使われているのかを見た目だけでは判断できないので。コメントを残し、不用意に削除されて問題を起こすリスクを減らすことができる。
.media {
overflow: hidden; #簡易的なclaerfixのため
}
ドキュメンテーション
コード上のコメントだけではなく、全体の設計や、その他のガイドラインまたはルールがまとめられたドキュメントがある方がいいことも多い。
デザインに関わるものでいえば、トーン&マナー、ブランドガイドライン
開発も関わるものであれば、UIガイドライン、UXガイドライン
などが挙げられる。
Appleの提供する「iOSヒューマンインターフェースガイドライン」がある。
https://developer.apple.com/jp/documentation/MobileHIG.pdf
https://developer.apple.com/jp/documentation/UserExperience/Conceptual/MobileHIG/BasicsPart/BasicsPart.html
英国BBCが公開している「GEL」は先に挙げたデザインに関わるガイドライン以外にも、広く包括してまとめられた有名なガイドラインである。
http://www.bbc.co.uk/gel
もっと開発寄りのドキュメントでいえば、コーディングガイドラインがある。
HTML/CSSに関するものでいえば、Googleが公開している「Google HTML/CSS style Guide」
https://google.github.io/styleguide/htmlcssguide.xml
日本語訳
http://buchineko.website/google_styleguide_html/
http://buchineko.website/google_styleguide_css/
やニコラスギャラガーによる「Idiomatic CSS」などがある。
https://github.com/necolas/idiomatic-css
日本語訳
https://github.com/necolas/idiomatic-css/tree/master/translations/ja-JP
こうしたガイドラインを持つことによって、一貫性、品質の担保ができ、運用の中で生まれる新しい機能やUIがどうあるべきか、という判断材料になる。
スタイルガイド、パターンライブラリ
パターンライブラリと呼ばれるものは、コンポーネント化されたUIを一覧したドキュメントで、そのUIを構成するマークアップやCSSのコードが明示されているものを指すことが多い。
それらは、ブラウザ上で閲覧可能。CSSの擬似クラスやJavascriptによるインタラクション、動きを確認できる。
ドイツの家具メーカー「homify」のスタイルガイド。
FoursquareやEvernoteとかに地図デザインを提供している「Mapbox」のスタイルガイド。
「Starbucks Coffee」のスタイルガイド。
フロントエンド開発者のポートレイトサイト「Max Quattromani」のスタイルガイド。
セールスフォースのスタイルガイド
githubスタイルガイド
bootstrap
a pattern apart code
http://patterns.alistapart.com/
http://alistapart.com/
スタイルガイドメリットは、各UIコンポーネントをどのようなマークアップで使うのか、といったドキュメントでもあるが、CSSに修正が入ったときにその修正が別のコンポーネントに影響を与え、壊れたりしないかどうかテストできるツールでもある。
スタイルガイドの作成方法
スタイルガイドのテンプレート
スタイルガイドを一から制作しなくても、テンプレートや仕組みが多く存在する。
http://patternprimer.adactio.com/
https://github.com/adactio/Pattern-primer
http://brettjankord.com/projects/style-guide-boilerplate/
https://github.com/bjankord
https://github.com/bjankord/Style-Guide-Boilerplate
PHPで作られているツールである。
Pattern Primerについては、有志によってRubyやNode.jsで動くようにしたものも配布されている。
https://github.com/micdijkstra/Pattern-Primer-Ruby
https://github.com/asciidisco/Pattern-Primer-on-Node
スタイルガイドジェネレータ
スタイルガイドに限らず、開発ドキュメント全体における最も大きな問題は、そのドキュメントがプロジェクトの最新バージョンと同期しているかどうかということ。
これがうまくできていないと、ドキュメントが存在しないこと以上に現場に混乱を招いてしまうなど、悪い状況を生み出すことがある。
そこで、CSSののコードをパース(解析)して、それをHTMLのドキュメントにするツール、スタイルガイドジェネレータを使うと、完全に手動でドキュメントを更新していくよりも少ない手順で、運用することができる。
KSS
Githubのカイル・ニース氏によって作られたKSS(Knyle style sheets)である。
http://warpspire.com/kss/
https://github.com/kneath/kss/tree/master/example
解説用
http://text.ykhs.org/2013/01/06/kss.html
KSSはRubyで実装されていて、Sassなどと同様にGemを経由してインストールすることができる。
基本的に、Ruby on RailsやSinataといったフレームワークに組み込んで使われる。
Node.jsで実装されたKSS-nodeなどもある。
Ruby実装のKSSは動的にスタイルガイドのHTMLページを生成するため、静的なHTML第るを生成しない。
KSS-nodeの場合は、静的はHTMLファイルを生成する。
上の写真のようにスタイルの上にコメントを挟むことができる。
<% styleguide_block '1.1' do %>
<button class="$modifier_class">Example Button</button>
<% end %>
最後のセクションで割り当てるナンバーが、マークアップのブロックと対応させられる。
StyleDocco
解説用
http://toybox-design.net/?p=640
Node.js製でnpmからインストールできる。インストール後は、Styledoccoコマンドを入力するときに、オプションでパース先のCSSファイルの指定などを行うだけ。
npm install -g styledocco
KSSと異なる点の1つは、CSSのコメント形式にマークダウンが採用されていること。
その他のスタイルガイドジェネレータ
Kalei
解説用
http://qiita.com/matsui-a/items/bf01090699b87f048c56
http://bashalog.c-brains.jp/13/11/12-230641.php
コンパイルを必要とせず、スタイルガイドを作成できる。
ソースコードをダウンロードし、そのディレクトリのルートでサーバを起動させれば、スタイルガイドを自動的に生成してくれる。
対象となるCSSのファイルは/js/config.jsの中に記述されているCSS_path:で指定されているので、必要に応じて変更が可能。
他のスタイルガイドジェネレータよりも比較的導入も容易なので、初めて試したいという人は、オススメ。
Hologram
比較的新しいスタイルガイドジェネレータでRubyで実装されている。HYML/CSSのカスタマイズやYAMLと呼ばれる記述フォーマットのファイルによる柔軟なドキュメント構成を作れるなど、高性能。
ワークフローを見直す
スタイルガイドを導入するフェーズについて、ワークフローの視点で考えてみる。
コンポーネント設計が、開発の効率を上げることは説明されているが、デザイナーが作ったラフやモックアップとにらめっこしながらパターンを見つけてコンポーネント化すると言うのは本質的ではない。
理想は、頑張ってパターンの抽出をするのではなく、はじめからコンポーネントを意識した設計をデザイナーと共に進められるような環境があること。
そのときには、コンポーネントを一覧できるドキュメントツール、スタイルガイドの初期の段階から存在することによって、開発効率は高くなる。
ニコールサリバン氏 「スタイルガイド駆動開発」
http://www.stubbornella.org/content/2014/04/09/
CSS開発に役立つツール
CSS Lint
ニコールサリバン氏、ニコラスザッカス氏によって作られた、CSSをのベスト・プラクティスを集約したCSSをのチェックツールである。
CSSのコードを入力すると、チェック項目を通した結果を教えてくれる。
コマンドラインで実行できる環境も用意されており、npmからインストール可能。
sudo npm install -g csslint
csslint file1.css file2.css
Javascriptの実装に自信があれば、CSS Lintが用意していないチェック項目を独自で実装することも可能。
StyleStats
解説用
https://html5experts.jp/t32k/5743/
http://qiita.com/t32k/items/7d898ec82ed0091e8fe1
IDセレクタや!importantがどれくらい使用されているか、宣言の多いプロパティがどのくらいの数か、というようなCSSの解析結果を出してくれる。
このようなツールを利用して、適切なリファクタリングをすることをおすすめする。
例えば、使用されている色を抽出できるのだが、あまりに種類が多い場合僅かな色のコードを統合して、コードの最適化を行うことができる。
sudo npm install -g stylestats
stylestats file.css
Autoprefixer
解説用
http://kojika17.com/2014/01/autoprefixer.html
http://qiita.com/tonkotsuboy_com/items/377913c51b1ac00deffe
box-sizingやFlexboxプロパティは柔軟なレイアウト機能を持ったコンポーネントを創る上で重要だが、ブラウザの対応状況に応じてベンダープレフィックスの付与や、対応バージョンごとにプロパティ名の違いなどに対応してそれら全て記述するのは骨が折れる。
Autoprefixerはそうした手動での管理を必要とせず、自動で任意のブラウザバージョンに合わせたプレフィックスの付与やプロパティの記述を行ってくれる。
それだけではなく、対象ブラウザに不必要な記述も削除してくれる。
sudo npm install -g autoprefixer
autopredfixer file.css
CSSComb
CSSプロパティを指定のルールに並べ替えや、記述フォーマットの整理をしてくれるツール。
sudo npm install -g csscomb
csscomb -c path/to/config file.css
プロパティが決まったルールで並べられることで、複数人がコードを触る環境でもコードを触りやすくなる、それに加え、gzip圧縮効率が上がるという点で、パフォーマンス面でのメリットがある。
gzip圧縮の仕組み上、対象のテキストデータに似たような文字列、繰り返す文字列を見つけ、それらを一時的に置換することでファイルサイズを抑える仕組みがある。
CSSO
CSSの最適化ツールで、minify化といった圧縮を行うときにオススメ。
CSSOは単純な圧縮だけでなく、構造の最適化など幾つかのオプションがあり、そのオプション次第で最適化によるファイルサイズの違いが出てくる。
構造の最適化とは、セレクタは別れているけど、ルールセットとして一緒のものをまとめたり、記述をショートハンド(短縮形)化したりすることなど。
Grunt.js
今やフロントエンド開発に欠かせないツールの一つ。タスクランナーとして、作業の自動化や、開発環境を整えるなどを行ってくれる。
参考ページ
http://qiita.com/svartalfheim/items/3968fd94da05f565d18f
http://kojika17.com/2013/03/grunt.js-memo.html