私はフロントエンドディベロッパーとしての仕事を、いかに簡単にそして効率よく行うか常々考えてきました。けれど最も身近な存在であるCSSに改めて注目し始めたのは、ほんのここ最近のことです。フロントエンド開発を楽にするためには、まずグリッドシステムとobject-oriented CSS（オブジェクト指向CSS）の考え方から始めまって、さらにCSSプリプロセッサという形で言語自体の拡張が容易になりました。最も知名度の高いのはLESSとSassですね。
今回のアーティクルではコードをモジュール化や再利用可能にすることにより、効率的にオーガナイズするベネフィットを探していきましょう。
この記事は、http://tympanus.net/codrops/の許可を得て、翻訳しています。一部変更して翻訳している部分もある場合があります。オリジナルの記事はここよりご覧いただけます。
CSS開発お助けツール
オブジェクト指向CSSは、ほぼどこでも使用可能かどうか、また将来的なプロジェクトの開発時間短縮に繋がるようなコーディングを自分が行っているかどうか確認する手段にもなります。OOCSS（オブジェクト指向CSS）の基本原則は以下の通りです。
- 構造とスキンの分離：個々の要素がレイアウトに沿うように適切なクラス設定がなされており、また目的に合ったスタイリングがされていること。
- 位置依存的なスタイリングの回避：OOCSS GitHubプロジェクトで完璧に説明されていますが、軽く説明すると、「.container h2」と書くより、セマンティック的に問題なければ何でもいいのですが「h2.tagline」などと記述することを推奨しています。こうすることにより全てのH2要素は必ず同じように表示されると言うような考え方です。
オブジェクト指向CSSで記述する際には、HTMLマークアップの時点から何をどのようにしたいのか注意しておく必要があります。例えばこのようなコードがあったとします。
<div class="blog-post">
<h1>Article title</h1>
<div class="meta">
<p>Date published: <span class="date">12 January 2012</span></p>
</div>
<div class="post-body">
<p>...</p>
</div>
</div>
それよりもこのように記述するべきです。
<article class="blog-post col_8">
<h1 class="headline">Article title</h1>
<p class="meta-information blog-post-meta">Date published: <time class="blog-date" datetime="2012-01-12">12 January 2012</time></p>
<section class="post-body text">
<p>...</p>
</section>
</article>
そしてCSSはこのように使うのです。
h1 { ... }
.headline { ... }
.meta-information { ... }
.blog-post-meta { ... }
time { ... }
.blog-date { ... }
.text { ... }
.post-body { ... }
「.blog-post」の中身それぞれにCSSルールを適用させるのではなく、もっと特定した情報だけ与えて再利用可能にするのです。ただしこのままでは「HTML書き過ぎ」という問題があります。１つのシンプルなブログポストにしては、コードが若干複雑過ぎるのです。ここがLESSの目の付け所で、LESSを使えばもっとプロセスを単純化させることが出来ます。
LESSとはCSSプリプロセッサーのことで、CSS言語をとんでもなく便利な機能満載に拡張してくれます。一度使い始めたらその凄さにビックリすると思いますよ。LESSには非常に多くの便利な機能が備わっているのですが、今回はその中でも３つの機能に注目したいと思います。
- 変数： @color1: #df0290;といった形で変数を定義し、コードの中に埋め込んでいきます。
.container { background: @color1 url('img/bg_gradient.png'); } - Mixin： 便利なファンクション（パラメータ有り無しに関わらず）を定義します。
.box (@w: 500px, @h: 200px) { display: block; width: @w; height: @h; }これもまたコードに埋め込んでいきます。
.modal-dialog ( .box(400px, 700px); }
- 入れ子式ルール： 説明するまでもなさそうですよね。みなさん今まで「CSSでこういうことが出来たらいいな」と思っていたのではないでしょうか。
article { font-family: serif; line-height: 1.4; h1 { font: 2em bold sans-serif; } h2 { font-size: 1.5em; &.category { color: #666; } } }アンパサンドマーク（&）を使用すると、親ルールを参照します。その為LESSコードがコンパイルされると、「&.category」は「article h2.category」に変換されます。
LESSを使用すれば、先ほどのブログポストの例もHTMLはこんなにシンプルになります。
<article class="blog-post">
<h1>Article title</h1>
<p class="meta">Date published: <time datetime="2012-01-12">12 January 2012</time></p>
<section class="post-body">
<p>...</p>
</section>
</article>
CSSはこんな感じです。
/* Reusable global styles */
h1 { ... }
.headline { ... }
p { ... }
.meta-information { ... }
.col (@width) { width: 10% * @width; }
.date-published { ... }
.text { ... }
article {
.col(8);
h1 { .headline; }
p.meta {
.meta-information;
time { .date-published; }
}
.post-body { .text; }
&.blog-post {
// perhaps some blog specific rules here?
}
}
CSSをオーガナイズする必要性
先ほどの例は極めてシンプルなものでしたが、WEB開発プロジェクトが大きくなればなる程、多用なスタイル設定が必要になればなる程、CSSをオーガナイズする必要性は現実味を帯びてくるのではないでしょうか。若干ダイアログは異なって見えるかもしれませんが、全体のルールを書き換えない理由にはなりません。単純にLESSとOOCSSの組み合わせを使って、スタイルコード（すなわちモジュール）を完成させましょう。先ほどの例のように、役割ごと細かくね。
スタイルコードのオーガナイズにこれほど重点を置くベネフィットの１つとして、様々なデザイン機能の分離が可能と言うことが挙げられます。この考え方でいくと、CSS（この場合はLESSですが）のライブラリを作成していくような感じになります。
/project/css/
– reset.css：ブラウザのデフォルト設定をリセット
– grid.less：グリッドシステムにmixinを適用（上記の.col(@width)と言ったmixin）
– type.less：フォント設定にmixinを適用（@font-faceルールなど）
– colorscheme.less：デザインで使用する様々な色用のLESS変数
– interface.less：インターフェース機能用のmixin（ボタン、フォーム、ダイアログなど）
– layout.less：サイトのレイアウトに特定したデザイン
– style.less：メインスタイルシート（上記含め、サイトのデザインに必要なもの）
このレベルでのオーガナイズは、ページ数の少ないものや１ページのアプリにはやり過ぎです。けれど多くの異なるページを所有した大規模なプロジェクトでは話が違ってきます。これが更に大規模になったら、search.lessやprofile_page.lessといったページやファンクションに特定したスタイリングファイルも必要になってくるでしょうね。
しかしながら、運用サーバー上でやみくもに多数のLESSファイルをロードするのも考えものです。以下にガイドラインを記しておきますね。
- いつでもきちんとしたスタイルのCSSを記述するようにしましょう。全てはディベロップメントの為ですから、コードスタイリングで横着をするのは止めましょう。
- LESSではコメントアウトする時、「/* */」ではなく「//」を使いましょう。LESSコンパイラで削除されてしまいます。
- 常にパラメトリック（媒介変数）mixinを使うようにしましょう。もし変数を持たないLESS mixinだとしても、空のカッコを追加して「.border () { border: 1px solid black; }」というふうに記述しましょう。こうすることによりLESS mixinがコンパイルされたコードに紛れることを防ぐことができます。
- LESSコードをコンパイルしてからCSS用のミニファイを使って縮小させます。LESSには「node.js」用に書かれた独自のコンパイラーがあり、またPHPコンパイラーもあります（オンラインデモもあります）。PHPのLESSコンパイラーでエラーが発生したとよく聞きますが、私自身はまだそういうことはありませんね。
スタイルライブラリの構築（フロントエンド開発高速化作戦）
既存コードを活用すれば、開発時間の大幅な短縮に繋がります。もしWEBアプリケーション開発を行っているとして、Bootstrapを活用しない手はありませんよね。Bootstrapなら必要なものは既に用意されているし、最も包括的なCSSのフレームワークだと思いますよ。何よりLESSで書かれてますしね。
その他のLESSフレームワークとしては、PrebootやElementsが挙げられるのではないでしょうか。どちらも便利なmixinが揃っていますよ。
けれど作業内容によっては、自分自身でライブラリを作成する方が手っ取り早かったりもします。可能な限り効率的なものを作るには、LESSコードの１つ１つ全てが多数のコンテキストに適用出来るよう注意しながら保存していく事です。勿論、コンテキスト毎にコードを書いていく事は出来ませんが、LESS mixinでカプセル化されライブラリに保管する限り、作成するコードは可能な限り複数のプロジェクトで活用出来るよう工夫するべきです。
他に考えうるストラテジーとしては、LESSテンプレートを使用することです。WEBサイトをスタイリングする際にフレームワークを使用することは、遥かに時間短縮に繋がるからです。colorscheme.lessをサンプルとして挙げてみましょう。
@background: #ffffff; @textcolor: #252525; @textcolor-strong: #090909; @textcolor-em: #666666; @textcolor-blockquote: #aaaaaa; @accent1: #2d9681; @accent2: #f8a34b; @warning: #d4230f;
と、こんな感じですね。プロジェクトごとにこのようなテンプレートを使用すれば、変数名を内面化させ、具体的にあれこれ考えずにそれぞれの要素の機能を選ぶことで迅速にスタイル文書を作成することが出来ます。タイポグラフィでも同様のことが言えます。例えば「type.less」ファイルで「@font-headline」を定義したとします。そうすればH1タグだろうとH2タグだろうと、どのようなフォントが必要か気にすることなく使用することができます。
また色やフォントやその他のサイトデザイン用の要素の更新がとても容易になり、一貫性をも保障してくれます。
ゲームプラン
今まで説明してきたことを、すぐに全て覚えるのは難しいかと思います。けれど大体の事が２つの原則に当てはまります。
抽象化と一貫性：コードをモジュラー化してください。そうすればどこでも使用可能になります。パターンを使ってください。そうすれば覚えることができます。スタイルとファンクションを切り離してください。そして詳細は全体像から捉えてください。本当に必要でないなら、位置依存のコードは使用しないでください。
全てをオーガナイズ：ただ再利用可能なコードを書けばいいというわけではありません。きちんと保存してください。私のWEBプロジェクトのディレクトリにはライブラリ用のディレクトリがあり、そこに再利用可能なコードは全て保管してあります。自分で書いたコードだけではなく、TwitterやBootstrapやLESS要素で見つけたコードもそこに保存しています。
今書いたことに従っていただければ、WEB開発の大幅な時間短縮に役立つようなLESSコードのライブラリを構築することができるはずです。WEBサイトの全てのファンクションとスタイリングを抽象化したら、あとはエンドユーザーにとって遥かにもっと重要なこと（全体的にどのように見えるか）に焦点を当てることができます。
イメージクレジット：
Abstract Vector Image By Vectorportal.com
Less Logo by Less
