［翻訳］MCSS (Multilayer CSS)

ナビゲーション

• 基本原則
• スタイルの格納ルール
• モジュールの対応図
• レイヤー 1 — ベース（ファーストレイヤー）
• レイヤー 2 — プロジェクト (セカンドレイヤー)
• レイヤー 3 — コスメティック (サードレイヤー)
• コンテキスト
• 実際の例
• 略語辞典
• 推奨事

基本原則

MCSS は非常に拡張性が高く、特定のコードスタイルやファイルシステム構成、または特定のツールなどを強制しません。重要なのはそれぞれのブロックごとにルールを分けるということです。

CSS モジュール（及び、その内部ブロック）はレイヤーごとに分離され、そのそれぞれのレイヤーは他のレイヤーモジュールと連携したり、一方的に利用するような独自のルールを持つことになります。

スタイルの格納ルール

モジュールの全てのスタイルは、分割されたセクションまたは CSS ファイルに配置されなければなりません：

/* モジュール名
-------------------------------------------------- */
.module { }

.module_list { }
  .module_list.__modifier { }
/* /モジュール名 */

同様に、カスケードにより変更されたセレクターも他の親セレクターの近くに格納されます：

/* モジュール名
-------------------------------------------------- */
.module { }

.module_list { }
  .module_list .other-module { }
/* /モジュール名 */

唯一の例外はコンテキストレイヤーです：

/* モジュール名
-------------------------------------------------- */
.module { }

.module_list { }
  .touch .module_list { }
  .ie9 .module_list { }
/* /モジュール名 */

この章は個別のドキュメントとして、より正確に説明する予定です（ロシア語版では既にそうなっています）。

スタイルのリンク順序

全てのレイヤースタイルは、異なるモジュール／レイヤーのセレクター間の正しい関係を維持するために、正しい順序でページにリンクされなければなりません：

0_layer_foundation
  reset.css

1_layer_base
  base_modules.css

2_layer_project
  project_modules.css

cosmetic.css

ルール

ファーストレイヤーの主要ルールは、全ての構成要素は名前とマークアップのどちらも抽象的である必要があるということです。

• クラス名はインターフェースのいかなる場所においても「無関係である」ように見えてはなりません。
• モジュールブロックはデフォルトスタイルを持たなくてはなりませんが、様々なプロジェクトモジュールやタスクに応じて簡単に変更できる必要もあります。

ファーストレイヤースタイルは同じレイヤーやセカンドレイヤーの他のモジュールからカスケードによって変更される可能性があります。これは関連するスタイルの位置は一ヶ所にあると見なすルールによるものです。

ベーススタイルはセカンドレイヤーモジュールから分離され、プロジェクトレイヤースタイルから独立した状態を保たなければなりません。

フォームの標準：

.input-field { }
  .input-field_text { }

フォームの標準とボタンの標準の相互作用 - ファーストレイヤーからのカスケードによる変更：

.input-field { }
  .input-field .button { }

セカンドレイヤー内におけるプロジェクトモジュールとフォームの標準の相互作用：

.project-module { }
  .project-module .input-field { }

ファーストレイヤーからのセカンドレイヤーの変更は禁止です！ この場合、レイヤーは混同され、混乱を引き起こします：

  .input-field .project-module { }

ベーススタイルはセカンドレイヤーより優先されてファンデーションの直後に配置され、セレクター詳細度における優先度を低い状態で維持します。

メリット

再利用可能でよく考えられたファーストレイヤーは、よくある構造をサポートする時間を節約し、複数の類似モジュールを維持する必要性を排除します。
また、再利用可能性は最終的な CSS ファイルサイズとページのレンダリング時間に良い影響を与えます。

より良く開発されたベースを持つことで、大部分が標準要素で構成された新しいインターフェース作成が簡単になります。

標準デザインサンプルは、あるプロジェクトから別のプロジェクトへ再利用可能で、レイアウトとそれに関連づけられたバックエンド機能の両方の開発を促進できます。

ルール

セカンドレイヤーレイアウトでは、可能な限りユニークな CSS クラスの使用が推奨されます。現在のデザインがスタイリングを必要としない場合でも、それに対してユニークな CSS クラスを割り当てることはベタープラクティスです。このようなアプローチにより、HTML の構造に影響を与えることなく正しいスタイルを容易に適用できるようになり、個々のレイアウトブロックごとに有用性を維持できるようになるでしょう。

ベースレイヤーのみと作用する独立したインターフェースブロックの各モジュールはできる限り分離される必要があります。

プロジェクトモジュール内でファーストレイヤー構造を利用するには、HTML にもう1つ CSS クラスを割り当てる必要があります：

<header class="toolbar">
  <a href="/" class="toolbar_logo"></a>
  <menu class="toolbar_dropdown_ul umenu">
    <li class="umenu_li"></li>
    <li class="umenu_li"></li>
  </menu>
</header>

セカンドレイヤーモジュール .toolbar がファーストレイヤー標準の .umenu を利用している例です。プロジェクトモジュールの要求のために標準を変更する場合、CSS カスケードが使用されます：

/* Toolbar
-------------------------------------------------- */
.toolbar { }

.toolbar_dropdown_ul { }
  .toolbar_dropdown_ul .umenu_li { }
/* /Toolbar */

プロジェクトレイヤースタイルは、他のプロジェクトレイヤーモジュールからのみ、カスケードによる変更が行われる可能性があります！

正しい記述：

.project-module .other-project-module { }

誤った記述：

.base-module .project-module { }

メリット

モジュールを分離することで、他のインターフェース部分へ影響が及ぶ危険性なしに、そのスタイルへ簡単にアクセスできるようになります。チームで作業する場合、各チームメンバーが別々に1つのレイヤーを開発することで、他の開発者とのコンフリクトが発生しなくなります。

各モジュールのスタイルは、ページが必要とする箇所に適用することができます。

ウェブサイトから機能性が失われているとき、不要なスタイルを簡単に取り除くことができます。あるモジュールと対応するスタイルを投げ捨てればよいのです。

ルール

サードレイヤースタイルはスタイルが破棄されている場合でもレイアウトを安全に保つ方法で構成されなければなりません。色やパディングなどのように、損失は小さくあるべきです。

稀にある非プロジェクトモジュールのために、シンプルな OOCSS クラスをブロックで最大3つまで使用できます：

<div class="font-size_XL margin-t_L color_red"></div>

コスメティックレイヤースタイルはコンテキストセレクター以外の他のレイヤーからカスケードによる変更を行ってはいけません。

コスメティックスタイルは CSS の最後に適用されます。!important の使用はお勧めしません。

メリット

スタイルはウェブサイトのレイアウトに対して大きな影響は持っていませんが、重複コード問題への対処や、小さなプロジェクトモジュール・ベースモジュールを作る必要性の排除といった助けになります。

非プロジェクトモジュールに少々のプロパティを適用する必要が出たとき、シンプルなセレクターはその稀な状況にすぐに対処できます。

コードスタイル

MCSS に加えて、コード品質を向上させるために以下に挙げる便利な実例の利用をお勧めします：

• Principles of writing consistent, idiomatic CSS
• Google HTML/CSS style guide - HTML と CSS のコード設定のためのスタイルガイド
• CSScomb - CSS プロパティのソートを行うツール

ベストプラクティス

• CSS にできるだけ多くのコメントを書きましょう。全ての非標準構成に、マジックナンバーに。私たちがそうするように、数ヶ月経ってコードレビューのためにあなたが戻ってきたときには、これはチームメンバーだけでなく、あなたにとっても役立つものとなります。