scriptjunkie{}
CSS アーキテクチャ、パート 4: MetaCoax アプローチによる CSS のリファクタリング (フェーズ 3 と 4)
Denise R. Jacobs | 2013 年 5 月 9 日
野放し状態の CSS を管理するのは容易ではありません。有名な スケーラブルなモジュール構造の CSS のアーキテクチャ (英語) を学んだ方は、CSS についてのチームの苦悩の原因を突き止めることができたことに大喜びすると同時に、そこで提案された変更をドキュメントやワークフローに追加する方法を見積もってみて愕然としたに違いありません。
MetaCoax による CSS のリファクタリング プロセス (英語) では、コードを着実に整頓し、管理が簡単になるように、時間をかけて段階的に CSS に変更を加える方法を紹介しました。CSS アーキテクチャ シリーズの最終回となる今回は、4 つのフェーズから成るプロセスの最後の 2 フェーズと、このプロセスによる成功事例を紹介します。
では、CSS をスケーラブルに保つために必要な最後の手順について見ていきましょう。
フェーズ 3: スマートなセレクター、グループ、および分離
フェーズ 3 では、スタイルシートの軽量化を図ることに重点を置きます。このフェーズでは、セレクターの最適化とコードのモジュール化を進め、スタイルのカテゴリを基に CSS を個別のファイルに分離し、スタイルパターン ライブラリとサイトのスタイル ガイドを作成することによって、引き続き冗長性を排除します。ここで行う変更は、以前のフェーズ (フェーズ 1 と 2) を基盤とする追加層となるため、以前のフェーズの実装を終えているものとします。
このフェーズでは、以下のことを行います。
- さらなるモジュール化
- 関連するクラスに状態名と JavaScript 名を使用する
- すべてのスタイルをモジュール レベルに移す
- スマートなセレクター
- セレクターとしての要素を完全に取り除く
- セレクターとしての ID を完全に取り除く
- グループ化と分離
- DRY (Don't Repeat Yourself: 同じことを繰り返さない)
- CSS をカテゴリ別に分離する
- @media について計画を立てる
さらなるモジュール化
時間が経つにつれ、またサイト コードのモジュール化を進めるにつれ、パターンが徐々に顕著になってくるため、おそらく、サイトのモジュールを特定および判断するプロセスが進んでいきます。
ここまでは、古いセレクターをクリーンアップし、少ないコードで作業を完了し、複数のサイトから再利用できる新しいスタイルや新しいセレクターに置き換えるというすばらしい仕事を行ってきました。 CSS for Grownups (英語) により、スタイルをモジュール レベルで保持することにより、本当の意味でスタイルの移植やリサイクルが可能になり、スタイルがモジュール自体に結び付き、ページ、ページ セクション、またはコンテナーに結び付くことがなくなることを示しました。このような手法をいくつか使用すれば、コードは確実にクリーンな状態に保たれます。
モジュール化の過程でもう少し調べておきたいのが状態クラスと JavaScript クラスです。OOCSS、SMACSS、および CSS for Grownups ではクラスに名前を付けることを推奨しています。その結果、状態クラスと JavaScript クラスが明確に表現され、スタイルシートの中でクラスが明確な状態に保たれ、検索と更新が容易になります。
状態クラス
SMACSS の手法の 1 つに、要素の状態クラスがあるときに状態名を使用する手法があります。状態クラスはスタンドアロンで作成され、通常、単一のクラス セレクターになります。たとえば、次のように、状態によってモジュールを拡張できます。
.is-collapsed
.is-active
.is-error
.is-hidden
SMACSS では、!important を使用できる (すべき) 場所は状態クラスのみです。
特定のモジュールの状態ルールを作成する場合は、クラス名だけでなくモジュール名も含めることをお勧めします。たとえば、次のようにします。
.is-navitem-hidden
個人的にはこの構文をぎこちないと感じるので、次の構文にすれば、簡単にスキャンでき、ルール セットをより迅速に検索できるようになる思います。
.navbar-is-hidden
.is-hidden-navbar
JavaScript 固有のクラス
優秀なフロント エンド開発者の Nicholas Gallagher は、特に JavaScript 関連クラスの作成手法を紹介し、 特定のクラスは JavaScript のフックのみに使用し、これらのクラスにプレゼンテーションを結び付けない (英語) ことを推奨しています。このような JavaScript クラスは次のような名前にします。
.js-login
このようなクラス名を使用すると、モジュールまたはコンポーネントの構造やテーマを変更することで、必要な JavaScript の動作や複雑な機能に間違って影響を与えてしまうことがなくなります。
スマートなセレクター
前回までに、修飾子を削除し、セレクターが DOM の上位要素に基づかないようにし、連結子を 3 段階以下にすることで、スタイルシートのセレクターの構造を整え、 セレクターが肥大化 (英語) するのを抑えました。今回はセレクターのクリーンアップの最終段階として、セレクターの真の効率化と最適化を図ります。
セレクターとしてのタグを完全に取り除く
この推奨事項は、レイアウト、モジュール、状態、またはテーマのスタイルに当てはまります。スタイルのリセットやベース スタイルには関係しません。これまでに、要素のセレクターは、モジュール レベルまたはコンポーネント レベルで HTML 構造に密接に結び付けられることを確認しました。そこで、セレクターの一部としての要素を含むセレクターが CSS に残っている場合は、そのセレクターをそのまま .class に変更する方法を考えます ( Make It So、英語)。
セレクターとしての ID を完全に取り除く
同様に、セレクターとしての #ID がスタイルシートに存在する場合、このようなスタイルはドキュメント自体またはドキュメント内の場所に密接に結び付けられる可能性があります。さらに重要なのは、このようなセレクターは具体性がかなり高くなるため、このスタイルをオーバーライドするには、より明確にセレクターを記述しなければならなくなり、スタイルシートが長くなって手に負えなくなる可能性があることです。このような状態は避けます。#ID を含むスタイルを取り除き、スタイルの具体度をすべて同じレベルにします。
グループ化と分離
スタイルシートの改善提案のほぼ最後は、異なるものを分離し似たものをまとめることで、CSS を細かく管理することです。
DRY (同じことを繰り返さない)
DRY CSS の強みは、「同じことを繰り返さない」という考え方にあります。DRY CSS 手法の多くを MetaCoax プロセスに取り入れる方法は見つかっていませんが、セレクターをスマートにグループ化して同じスタイルにすることをお勧めします。
たとえば、スタイル シート内で "font-weight: bold" が何回も繰り返されている場合は、要素のセレクターの多くをメインのスタイルとして {font-weight: bold:} にグループ化する状況であることがわかります。ただし、スタイルのセレクターを完全に最適化してから、一連の手法の最後としてこの手法を当てはめます。
CSS をカテゴリ別に分離する
フェーズ 2 では、スタイルシート内に SMACSS (またはこれに相当する) カテゴリを作成しました。今回はさらに進めて、このようなセクションを個別の CSS ファイル (base.css、layout.css、module.css、state.css、および theme.css) に分離します。
必要なスタイルを複数の場所から検索するのは望ましくないため、個人的にはファイルを分離することに手放しで同意するものではありません。ただし、驚くほど長いスタイル シートをスクロールしながら検索することに時間が掛かっている場合は、この手法が役に立ちます。
@media について計画を立てる
前もってレスポンシブ デザインを計画する場合、SMACSS には、@media クエリを管理する方法に関してもう 1 つの優れた推奨事項があります。通常行われているように、これらのクエリをスタイルシートの最後でグループ化する代わりに、 モジュール (またはレイアウト) の状態の近辺にメディア クエリを配置し (英語)、影響するレイアウト スタイルやモジュール スタイルにメディア クエリを追加することを Snook は提案しています。もちろん、メディア クエリは複数回宣言される可能性が高くなりますが、すべてのモジュール情報がまとめられるため、それ自体でモジュールをテストできます。先ほどの推奨事項に従うと、モジュールのスタイルは別のファイル (module.css) に含まれることになるため、1 つの大きな CSS ファイルを検索してモジュールを探すことがなくなります。
フェーズ 4: 共有は思いやり
MetaCoax プロセスでの CSS の最適化と (CSS for Grownups で特に顕著な) スケール変換手法の最終フェーズは、("パターン ライブラリ" とも呼ばれる) スタイルモジュール ライブラリと Web サイトのスタイル ガイドを作成することです。パターン ライブラリは、さまざまなモジュールやコンポーネントすべてのリポジトリです。これに対してスタイル ガイドは、Web サイト全体のコンテキストにおける各コンポーネントの適切な使用方法とコンポーネントの連携方法を示すドキュメントです。スタイル ガイドでは、サイトのページにあるすべての要素と、この要素に対応するスタイルについて説明します。初期ページ要素をページのレイアウトに結び付けることはありませんが、代わりに各要素は一般ページのコンテキスト内で独立して機能します。次にレイアウト要素を追加し、ページ内部で機能するようにコンポーネントをテストします。パターン ライブラリとスタイル ガイドを作成するのは、Web サイトの将来に向けて一貫性を保つためです。
このフェーズはプロジェクトの最終フェーズですが、実際最後に行うことではありません。プロジェクトの早い段階から始めます。パターン ライブラリや付属のスタイル ガイドは、プロジェクトの最終段階での結果論として追加すべきではありません。これらは CSS リファクタリング プロセスに必須のコンポーネントです。
このフェーズでは、以下のことを行います。
- パターン ライブラリを作成する
- Web サイトのスタイル ガイドを作成する
パターン ライブラリ
パターン ライブラリを作成しておけば、完全に中立な環境でスタイルのテスト ケースを作成する手法になります。パターン ライブラリの作成は、コードの調整と同時に行います。サイトの優れた新しい CSS 用にパターン ライブラリを構築に着手する場合の推奨事項をいくつか示します。
- サイトに含める一意の要素とコンポーネントを決め、テキスト、ヘッダー、ボタンのメイン カラーにも注意する。
- ページの核となる要素 (見出し、リンク、テーブル、ブロック引用、箇条書きリスト、番号付きリスト、フォームなど) のスタイル設定を開始する。
- ページのモジュールまたはコンポーネントのスタイルを、モジュールまたはコンポーネントを使用するページには依存しないように設定し、ページを真にモジュール構造にする。
- 検索ボックス、階層リンク ナビゲーション、テーマ ボタン、モジュール内のさまざまなバリエーションなど、ベース スタイルをオーバーライドするコンポーネントのスタイルを設定する (ホバー状態、フォーカス状態、アクティブ状態などの操作のスタイルを含む)。
- パターンに簡単にアクセスして管理できるツールに、コードやスタイルのスニペットをすべて入力する。
リファクタリング プロセスの一環として、手順 1. ～ 3. は必ず実行することになります。パターン ライブラリの作成で難しいのは、パターン ライブラリの構造を考えることです。Web には、インスピレーションを得たり、エミュレーションを行うのに役立つ優れたサンプルがあります。 MailChimp UI パターン ライブラリ (英語) は単一ページのパターン ライブラリの優れた例です。 PatternPrimer (英語) は、ページ レイアウトのコンテキストに依存しないコード スニペットを作成する優れた例で ( GitHub でも確認できます、英語)、特に、モバイル優先のレスポンシブ デザインを対象にしています。 Pears パターン ツール (英語) は WordPress を使用して構築した一種のミニ パターン ライブラリ CMS で、1 つのリポジトリにマークアップやスタイルの共通パターンを入力して管理します。このリポジトリに含まれるスタイルはすべてコンテキストに依存しません。
Web サイトのスタイル ガイド
これで Web サイトのコンポーネントを用意したので、サイト全体のコンテキスト内ですべてのコンポーネントが連携する方法 (ページ単位に連携するだけではありません) を記述したスタイル ガイドを作成します。パターン ライブラリにまとめたスタイルを含むスタイル ガイドを作成することで、頼りにするドキュメントがなく、以前の開発者が何をしたかわからないまま多くの開発者の手で作成された CSS を使用する多くのサイトで起きる悲劇の連鎖を断ち切ることができます。
ただし、 スタイル ガイドにおける問題 (英語) が発生する可能性があることにも注意してください。スタイル ガイドは、以前のグラフィック標準のマニュアルのように厳密に規定しすぎないようにします。厳密すぎると、創造性を抑圧され、無意味な官僚主義に陥ることがあります。スタイル ガイドは柔軟性に富み、スタイルがページ上のどこにあっても、モジュールになっているかどうか、スタンド アロンで実行できるかどうかを実際に判断できる必要があります。スタイル ガイドは、サイトの設計チームと開発チームとの接点になります。
改めて強調しておきますが、スタイル ガイドを作成することで新たに厄介な問題を抱え込まないようにするには、サイトのスタイルを改良するときは、併せてスタイル ガイドも作成するようにします。パターン ライブラリの作成に続いて実行することとして、Anna Debenham は、 フロント エンドのスタイル ガイド (英語) で、サイト用のスタイル ガイドを作成する際の最終手順を以下のように提案しています。
- 最後にレイアウトを追加し、コンポーネントを配置する。各レイアウトは別のドキュメントに表現する。
- コーディングのプロセス (名前付け規則やコンポーネントのグループ化、分類などを決めた背景にある考え方) をドキュメントにする。
- 知識を結集するために、チームやすべてのフロント エンドの開発者の参加を求める。
ヒント: この MailChimp のブランド アセット ガイド (英語) のように、スタイル ガイドはできるだけ簡潔に保ちます。学術書を執筆する必要はありません。スタイル ガイドが長くなるにつれて、他人が読む機会は減り、ガイドラインに従う可能性はかなり低くなります。
Starbucks.com のスタイル ガイド ( http://www.starbucks.com/static/reference/styleguide/、英語) は、要点がまとめられ、うまく整理されたドキュメントになっていて、優れたオンライン スタイル ガイドを構成するための優れた指針になります。 Kalei スタイル ガイド (英語) は、自身のサイトの CSS 向けに Twitter Bootstrap (英語) のようなドキュメントを生成できるため、一見の価値があります。Anna Debenham は、 より一層すばらしいスタイル ガイドの例 (英語) を構築しています。
スタイル ガイドを用意しておけば、サイトの構築中にスタイルのドキュメントがないために自身で同じスタイルを実現する方法を見つける必要がなくなります。確かに、レイアウトに多種多様なオプションがある大きなサイトでは、スタイル ガイドの作成はかなり困難です。しかし、スタイル ガイドは、将来のサイト開発者の役に立ち、簡単に活用できるものなので、最終的には作成する価値があります。
MetaCoax の成功事例
プロセスに関連して展開される理論は、知的演習としては優れていますが、最も優れたアイデアとは実際に使用できるものです。複数のシステムのベスト プラクティスを組み合わせることで MetaCoax プロセスを開発し、7,500 行の複雑で膨大な CSS コードを含む Web サイトでテストしました。MetaCoax プロセスでは以下のことを行いました。
- CSS の総行数を 7,500 行から 2,250 行に減らしました。
- 大部分のインライン スタイルとセマンティックではない要素を取り除きました。
- 最新のベスト プラクティス (英語) を当てはめました。
- グリッドを構築し、327 の width インスタンスと 738 の margin インスタンスを取り除きました。
- また、以下のものも取り除きました。
- 1259 の div# インスタンスと 836 の div インスタンス
- body# を含む 936 のスタイル
- 126 の !important インスタンス
- 189 の margin-top インスタンスと 112 の margin-bottom インスタンス
- サイト コードの将来の利便性を高めました。
さらに、これらすべては、サイト上の表示の変化に簡単には気付かない状態で実現できました。
スケーラブルでモジュール構造の CSS が最適
このシリーズでは、自身の開発だけでなく、開発チームにも役に立ち、Web 部門全体のワークフローも変化する可能性がある、CSS を改良するための原則、手法、およびプロセスについて説明しました。今回のプロセスに従わない場合でも、このプロセスを確認することで、CSS を更新するプロジェクトを進める方法について新たな確信を得ていただけたらさいわいです。では、CSS のリファクタリングに取り掛かりましょう。
この記事は、Internet Explorer チームによる HTML5 技術シリーズの一部です。3 か月間無料の BrowserStack クロスブラウザー テスト ( https://modern.IE) を使って、この記事の概念をお試しください。
参考資料
- CSS Lint のページ (英語)
- 良い習慣を破る (英語) – Front Trends Conference 2012 での Harry Roberts の講演
- ビッグ CSS (英語) – もう 1 つの Harry Roberts による優れたプレゼンテーション
執筆者紹介
Denise R. Jacobs は、Web デザインのエキスパートであり、14 年以上の経験を持つ業界のベテランです。彼女は今最も好きなこと、つまり、講演者、著者、Web デザイン コンサルタント、創造的なエバンジェリストになることに取り組んでいます。Twitter ( @denisejacobs、英語) では、"great resources" (優れたリソース) を紹介して高い評価を受けており、CSS コードのトラブルシューティングに関する主な書籍である『 The CSS Detective Guide』(New Riders Press、2010 年) の著者であり、『 Interact with Web Standards』(New Riders Press、2010 年) および『 Smashing Book #3: Redesign the Web』(Smashing Media GmbH、2012 年) の共著者です。長年構想を練ってきた最新のプロジェクトでは、少数派の人々に表舞台で活躍する Web エキスパートになって Web でロックする (英語) ことを奨励しています。彼女の連絡先は、 denise@denisejacobs.com(英語のみ) です。 DeniseJacobs.com (英語) で詳細を確認できます。