Day: February 27, 2012

私はフロントエンドディベロッパーとしての仕事を、いかに簡単にそして効率よく行うか常々考えてきました。けれど最も身近な存在である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マークアップの時点から何をどのようにしたいのか注意しておく必要があります。例えばこのようなコードがあったとします。 それよりもこのように記述するべきです。 そしてCSSはこのように使うのです。 「.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はこんなにシンプルになります。 CSSはこんな感じです。 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コンパイラーでエラーが発生したとよく聞きますが、私自身はまだそういうことはありませんね。