Help us understand the problem. What is going on with this article?

CSS設計・Sassディレクトリ管理の標準化(CROCSS)

はじめに

HTML+CSSコーディングにおいて、Sass管理ディレクトリを標準化する方法を紹介します。
CSS設計は、サイト種別やプロジェクト規模、分業の有無や人数によっても最適解が異なります。
この仕組みは、様々な設計を同じロジックで受け入れることによって、CSSコードの管理効率を画一的に最大化する狙いのものです。
コーポレート・ポータル・ブログ・EC・LP・管理画面…など、様々な種別のサイトのCSSを、同じ仕組みで設計して管理できるようになります。

前提事項など

  • SassなどのCSSプリプロセッサの使用を前提とします。
  • 本記事の一部は、後で見られるよう別記事として切り出しています。(📝のマークのもの)
  • この記事は標準化ノウハウ公開の一環として書いています。
    仕組みの概要や前提事項などについては「UltimateCoding 概要・前提事項」のエントリをご確認ください。

セクション一覧

  1. 全体の把握
  2. 仕組みの概要
  3. CROCSSの標準分類
  4. 物理化と実例
  5. 実用にあたって
  6. 使用感や設計・実例
  7. その他・考え方など
  8. さいごに

1・ 全体の把握

まずは全体像の説明です。
今回の仕組み(CROCSS / クロックス)は、過去に公開したHCDCモデルHTML Partsを実務利用するための具体的なノウハウとなります。HCDCモデルとHTML Partsは、以下の図のように制作行動の "要所" において、設計の在り方を示すガイドとして働きます。

コーディング全体の流れと対応する手法
そして今回紹介するCROCSSは、これらの概念をSassファイルの管理ディレクトリに変換し、概念と実務をスムーズに連動させる役割を担います。

過去記事は先にお読み頂いても良いですし、この記事からのリンクで局所的にお読み頂いても問題ありません。
もっと詳しく全体を把握したい場合は、記事内の「よりよい把握のための図解」や「著名な設計手法10個との概念比較」をご覧ください。

過去の記事

直接関連するもの

論拠や背景

2・ 仕組みの概要

基本ロジック

この仕組みの基幹にあるのは「分類の乗算」です。
以下のように2つの分類を掛け合わせることで、Sassディレクトリの主たる構造をつくります。分類-1,2は、CROCSS標準のものがあります。この記事ではそれらを中心に説明します。
基本ロジック図解
また、このロジックは思考の幅を広げ、構造の幹をつくるためのものです。隅々にまで適用しなければならないような「強制力」はありません。設計の枝葉の部分においては管理効率を最優先してください。

物理化メソッド

つぎに、実際にSassディレクトリを構築するまでの流れを図説します。
以下は、前述の「基本ロジック」にCROCSSの標準分類をセットして全体の流れを把握しやすくしたものです。
分類-1には、制作者が自然と判断できる分類を使い、分類-2には、HCDCモデルのデータ分類を使います。
Sassファイルを作成するまでのステップ
そして、分類-1の中に分類-2を平等に設置することで概念上の「型枠」をつくり、その中から必要なものを物理化(ディレクトリ化)します。
サイト種別ごとのガイドや、ディレクトリ構造の実例、使用感は後のセクションにて記載します。

このアプローチにより、以下の3つの効果・特徴を得ます。
リストをクリック or タップで展開できます


1 ・ 拡張しやすさの確保
この物量を見ると、反射的に「こんなに沢山のディレクトリは制御しきれない」とか、「もっと少ない方がよいに決まっている」と感じるかもしれません。
しかし、人は物量や階層の深さによって混乱するのではありません。人が混乱するのは「情報の捻れ」や「曖昧さ」「不整合」などが発生している時です。
 
最終的に物理化するものは絞られます。最大枠を概念側に置いておく事で、役割が欲しくなった時にすぐに拡張できるようにしておきます。


2 ・ カスタマイズ性
2種類の分類は、中身を変えることで設計を大きく変更・拡張できます。
例えば図中の「分類-1」を、FLOCSSの第一階層に変更しても同じように乗算できます。
 
この場合、当然FLOCSSではなくなりますし、CROCSS標準でも無くなりますが、新たな設計を試せます。
また同様に、標準として定める全ての文言や役割は追加・変更・削除しても問題ありません。


3 ・ 雛形作成と設計切り替え
この仕組みは雛形化しやすくなっています。特定のサイト種別のために作ったディレクトリ構造でも、概念枠によっていつでも拡張・縮小して多種別対応できます。
 
毎回最初から同じような構成を作る必要はありません。雛形を作成し、ブラッシュアップしていけばそれだけで業務標準化・効率化になります。

対応範囲

記事作成時点での実務利用実績(実際に対応した種別)は以下の通りです。

コーポレートサイト / ポータルサイト / サービスサイト / システム管理画面 / ブログサイト / ECサイト(オンラインショップ) / ランディングページ(LP) / イントラサイト

上記以外の実績はありませんが、おおよそいずれかに似た属性となるため問題なく使えるでしょう。

3・ CROCSSの標準分類

CROCSS標準の分類について説明します。
標準となるのは以下の2つです。

  • 【分類-1】:スコープ分類 … 4つの対象範囲による分類
  • 【分類-2】:データ分類 … 4つのデータ属性による分類

【分類-1】 スコープ分類

分類の1つ目は、多くの制作者にとってすぐに判断できるものを使います。
以下の2つの事柄によって、4つの項目を定義します。

  1. 一般的な制作ステップ
  2. ページ内での所属区域

1. は、「下地を整えてから枠組みをつくり、中にコンテンツを入れていき、各ページの固有の上書きをおこなう」といった、初期制作時における一般的な制作フローです。
2. は、対象が「ページの主たる情報」なのか「サイトの枠組み」に使うものなのか。といった判定で、制作者であれば恐らく誰もがすぐに特定できます。

この2つを組み合わせると、下地(Base)、共通の枠組み(Frame)、コンテンツ(Contents)、ページ(Pages)という4種になります。物理化した時に、それぞれのディレクトリ内部に格納したものは、その分類の役割が果たす範囲(スコープ)でしか使いません。

スコープ分類とレイヤーの図

また、これら4つのスコープは、概念によるレイヤー構造を持ちます。これらの関係は「下にあるものは上で使える」「上にあるものは下を上書きできる」というシンプルなものです。
このルールによってCSS管理に法則と秩序を与え、まずは大きな区分けでの影響分離をおこないます。

1・スコープ分類の詳細説明

詳細については長くなるため別記事に記載しています。
※まずは全容を把握したい場合には、後からご覧頂いても問題ありません。

📝 スコープ分類について

2・ディレクトリ化

スコープ分類による、最終的なディレクトリの構成は以下のようになります。

  • base/  … サイトの下地・土台・基底
  • frame/  … サイト全域で共通利用するような枠組み部分
  • contents/  … ページの主たる情報や機能、入力操作のための領域
  • pages/  … 全てを包括する最も大きな概念

3・カスタマイズ

何かが足りない場合や、他の英単語の方が馴染みが良い場合は、自由に追加・変更してください。例えば、theme/skin/templates/などの追加、contents/object/にした方がプロジェクトに馴染む。といった事が考えられます。

【分類-2】 データ分類

分類の2つ目は、「HCDCモデル図」の4つのデータ分類を使用します。
HCDCモデル図
このうち、左半分(Block , Parts)は「HTML Parts」による粒度分類・定義をそのまま使います。右半分(Structure , Utility)はCROCSS側でガイドを定めます。

1・データ分類の詳細説明

詳細については長くなるため別記事に記載しています。
※まずは全容を把握したい場合には、後からご覧頂いても問題ありません。

📝 データ分類について

2・ディレクトリ

これらのデータ分類を全て展開すると、以下のような構造になります。

  • block/
    • ※下層は適宜設置
  • parts/ (HTML Partsにより粒度分類)
    • module/
    • component/
    • element/
  • structure/
    • ※下層は適宜設置
  • utility/
    • ※下層は適宜設置

この構造は、最終的に「分類-1」の4つのスコープ(Base・Frame・Contents・Pages)内部に平等に設置でき、実際に物理化して利用する時にはそれぞれのスコープにおいて統治します。

3・カスタマイズ

何かが足りない場合や、他の英単語の方が馴染みが良い場合は、自由に追加・変更してください。
例えばwidget/vender/などの追加。小規模なサイトであればparts/が丸ごと不要。といったケースも考えられます。逆に、今回不要だったものが、次のプロジェクトでは必要になる。という事もあるでしょう。

4・ 物理化と実例

CROCSS標準の分類2つが把握できれば、あとは物理化するだけです。
方法は概要に記載した通り、まずは「スコープ分類」と「データ分類」の2つの概念を掛け合わせて「物理化のための型枠」を用意します。
物理化のための
作成した「型枠」は概念的なものであるため、一旦資料に残しておきます。テキストファイルやMarkDownでの箇条書き、Excelによる資料などで充分です。
何か問題があれば分類を見直し、常に概念と物理がスムーズに繋がるよう再設計します。

5・ 実用にあたって

部品(Sassファイル)の保存方法

Sassファイルには部品と同じ名前を与えます。
大抵の場合はHTML要素のclass属性の値で与えた名前になりますが、id属性によるスタイリングを許可する場合はidの値も対象になります。ファイルを作成する時は、全てのディレクトリを通して同一名のファイルは作成しないよう注意します。
Sassファイルを作成したら、対象に関連する部品や効果は、そのファイルの内で影響が収まるようにスタイリングします。

スタイリングは、グローバルに再利用する場合はスタイリングのパターンAになり、関連部品を自身の所属物とするなら、パターンBか、パターンCのどちらかになります。

プレフィックスやサフィックス

接頭辞(プレフィックス)や接尾辞(サフィックス)に関しては、制作レギュレーションや実務用のコーディングガイドなどで自由に定めて下さい。
Layoutに関しては「命名重複回避」を主たる理由として、l-などのプレフィックス付与することを推奨していますが、強制力を持つルールではありません。

ページの識別・特定方法の問題

部品主体のコーディングをおこなう場合は、常に「ページ識別」の問題がつきまといます。
ディレクトリ名やファイル名などを、識別子としてbodyのclassに記述すると判定しやすくなりますが、全て手動でテキスト入力するのは面倒です。
そこで、こういったclassを自動出力する「bodyclass.js」を同グループで作成しています。
現在のところjQuery依存ではありますが、必要に応じてご自由にお使い下さい。

6・ 使用感や設計・実例

コーディング時の使用感

実際にコーディングする時の使用感は以下のようなものになります。
リストをクリック or タップで展開できます


ファイル管理
「スコープ分類×データ分類」によるディレクトリ構造は、いわば「部品の片付け先」をあらかじめ用意するようなものです。いざという時に引き出しがあればすぐに収納できますが、なければ引き出しを作るところからはじめなくてはなりません。
 
少し考えれば置き場所が見つかる・すぐに増やせる。そして、Sassファイルの置き場所で設計内容をある程度伝達・把握できるようになります。


CSS設計
CSS設計を柔軟に切り替えて使えます。部品は、グローバルに再利用するかどうかで別途部品化(=新規Sassファイル化)するかが決まります。
 
命名や単語連結手法(いわゆる命名規則やBEMのような手法)は普段慣れたものを使えます。また、プロジェクトごとに最適なものに入れ替えて使用することも可能です。


マークアップとスタイリング
Structureをうまく使うと「弁当箱を間仕切りして具材を詰めるように」コーディングできます。
 
Block内部のホワイトスペースはStructure側で制御できるため、主要な情報の部品(Component等)に余計な余白や位置決め用のスタイルを与えることなく、それぞれの責任範囲を分離してコード管理できます。
また、レスポンシブの制御もキャンセルを多用しなくても済むようになるでしょう。


レギュレーション
業務を標準化するには、最終的にHTMLの書き方や、部品ごとのマークアップ方針・レギュレーションが必要になります。これについては、また別の機会に紹介します。


命名の雛形化
こういったSassディレクトリ構築の取り組みをおこなう中で、その現場やチームで使用する「概念の型枠」は最適化され、次第に独自の型が定まっていきます。
この時、よく使う部品に固定の命名を与えて雛形化しておくと、デザインの後入れ(Design Injection)によるコーディングがおこなえます。
 
このような考え方にご興味があれば、「DI-CODING」のページをご覧ください。(1枚物の簡単なページで、もう少しだけ詳しく説明しています)

サイト種別ごとの管理設計

サイトの種別ごとに、どのように管理できるのかの概要を記載します。
リストをクリック or タップで展開できます


1 ・ 情報発信系サイト
多くの情報発信系サイトにおいて一般的な使い方は、BaseでHTML要素のデフォルトスタイルを整え、ContentsとFrameにてそれぞれの専用部品を管理。条件的な上書きをPagesで一元管理する。といったものです。
 
コーポレート系やブランディング系など、一般的な情報発信系サイトであればこの方式で対応できます。
小さい規模のサイトであれば、Blockの粒度のみでサイトが完成するでしょう。


2 ・ システム管理画面系サイト
システム管理画面などにおいて、サイト全域で小さな部品を再利用する場合はbase/にて部品を管理します。
これにより、Frame領域とContents領域とで同じ部品を利用できます。
CSSフレームワークやテーマなどの「既製部品」を利用する場合も同様です。もし、こういったものを使う場合は、vender/などで丸ごと一元管理すればよいでしょう。
 
逆に、Contents部分のみに「既製部品」を使いたい場合(Frameでは一切使わないと明示したい場合)は、contents/vender/などで管理します。


3 ・ ECサイト
カタログタイプのECサイトの場合、多くの中規模部品を再利用する事になります。
例えば、カテゴリ別の商品一覧や、おすすめ商品、ランキングなど、同じものを異なるページで再利用することが多くなるでしょう。
この時、部分的な機能や表示の塊をmodule/粒度のものとして管理できます。


4 ・ ランディングページ
ランディングページ(LP)は、プロジェクトによってはFrameそのものが不要かもしれません。
この場合、全てをContentsとして作ることになるでしょう。将来的に顧客の要望によってページが追加されれば、最初は不要と思っていたFrameが必要になる(簡易なヘッダーとフッターを追加する)事もあり得ます。


5 ・ その他のサイト
その他のサイトは、上記のいずれかに近いか、折衷した管理になるでしょう。
スタイリングのアプローチは部品単位で切り替えられるため、より良い管理を模索できます。

ディレクトリ構成の実例

ディレクトリ構成の実例を紹介します。
以下は、コーポレート系のサイト制作を対象にしつつも、念のため他の種別にもすぐに対応・拡張できるように構成したディレクトリの例です。

ディレクトリ構成・第一階層

リストをクリック or タップで展開できます


base/ の下層展開
成果物全域に関わるCSSを管理します。
vender/ ディレクトリを追加する事で、独自作成のものと外部のCSSを影響分離しています。
base/ の下層展開 ディレクトリ図


contents/ の下層展開
Contents領域のみで使うCSSを管理します。
block/の内部は、共通利用するものを_commonに収め、サイトのページ名やカテゴリ名でディレクトリを設置すると分業がおこないやすくなります。
contents/ の下層展開 ディレクトリ図


frame/ の下層展開
Frame領域のみで使うCSSを管理します。
Frameのblock/の内部は、部位や機能によってディレクトリを設置しておくと、何かあったときに拡張しやすくなります。
frame/ の下層展開 ディレクトリ図


pages/ の下層展開
コーポレート系サイトを想定した場合、Pagesのサブディレクトリは必要ないと判断し、単一階層でSassファイルを管理しています。
pages/ の下層展開 ディレクトリ図

上記は実務利用しているものと近く、実際には「DI-CODING」によってSassファイルの命名雛形も含めてスターターキット化しています。作る手間より削除する手間の方が楽であるため、雛形化するときには少し広げて作っておいたほうが後々楽に使えます。
目視でファイルを追いかける場合、平置きの大量のファイルをアルファベット順で探すより、格納場所が分かっている適量のディレクトリを下った方が遥かに楽に探せます。

これらにより、コーポレートを中心としながらも、どんな種別の案件でも対応できるようにしています。

7・ その他・考え方など

よりよい把握のための図解

「1 - 全体の把握」の図を再掲載した上で、仕組みについてもう少し詳しく図解します。
コーディング全体の流れと対応する手法

上記の詳細が以下の図です。これにより概念がどのように使われ、物理化されるのかが把握できます。
一見すると複雑に見えるかもしれませんが、1つづつは単純です。
仕組みの図解/実務と概念の流れ
青文字と矢印が「制作における行動」で、オレンジの文字と矢印が「概念の流れ」です。
制作の流れとしては(1)~(4)を繰り返しおこない、概念はそれをサポートする形で関与しています。

著名な設計手法10個との概念比較

この仕組みの定義と、著名な10種類のCSS設計や思想との比較・対応表です。
こうしてまとめてみると、それぞれ言い方が違うだけで、やりたい事の本質は似ていたのでは?という事が見てとれます。特に、ComponentとUtilityのあたりは顕著です。
逆を言えば、この度の一連の仕組みはこれらの特徴を併せ持っていると言えます。

概念比較表

各公式サイトへのリンク

SMACSS / OOCSS / BEM / MCSS / RSCSS / ECSS / ITCSS / FLOCSS / PRECSS / Atomic Design

手法とレギュレーションの考え方

現場で制作者が準拠すべきものは、現場ごとに定められたルールやレギュレーション、ガイドライン(図の3)です。これがその制作現場における最高位の権限と強制力を持つと考えます。

概念や手法の実用ステップ図
(1)は、その環境における「特効薬」をつくるための参考資料・材料であり、制作者が「これを使う」「この仕組みに準拠する」と定めて初めて、効力を発揮します。これは、ひとりであってもチームであっても「業務の標準化」を目指すのであれば変わりません。

この仕組みも(1)に該当し、その他多くのCSS設計と同じく「誰かがその人の環境を最適化するために作ったもの」です。取扱業務も、商圏も、組織規模も異なる現場や環境において、全く同じ仕組みがそのままの状態でベストマッチすると捉える方が不自然です。

各所で自由に変更してもよい。と記載しているのは、こういった考え方のためです。そのまま使える方が効率的ではありますが、現場のルールを決定するのは制作者(設計者)です。
決して(1)を(3)と捉えないよう、また、"ねばならないの思考"にはまらないようご注意ください。

8・ さいごに

これまで「HTML+CSSコーディングの言語化」からはじまり、「HCDCモデル図」からなる一連の情報を公開してきました。今回で概念をどのように実務利用するのかをお伝えできたのではないかと思います。

この仕組みは、著名なCSS設計手法では業務が標準化できなかったために独自で構築したものです。
当時の環境は、取り扱うサイト種別が、企業サイトやブランディングサイト、EC、ポータル、LP、サービスサイト、ブログ、管理画面(システム開発も含む)…、という幅広い範囲であったにも関わらず、コーディングルールもなく、過去のサイトに手を入れる場合は一苦労でした。

このような多くの種別の制作方法を統一したくても、当時著名だった手法ではCSSは溢れかえり、何かに寄せればどれかの種別で設計破綻する。といった状況でした。
こういった環境の中で、全てに通用するコーディングの本質は無いものかと求め続け、案件で叩き上げたのが今回の仕組みになります。

合う、合わないは必ずありますし、本当に使いやすい「特効薬」は現場ごとに作ることになりますが、その時のレシピや材料・参考資料になれば幸いです。

今後の情報公開

あと2つの手法の公開が残っていますが、これらは「命名規則」に関する話になります。
HCDCモデル図を実務利用するための4つの標準化手法
しかし、実はもうこの段階で実用できます。
命名に関する標準化は、一連の仕組みとは疎結合の関係にあるためです。どのような単語と連結記法を使おうと、仕組みの本質が変容することはありません。
もし今現在でCSSが氾濫する。設計手法の解釈が人によって違って困っている。といった悩みをお抱えの場合は、是非お試し下さい。

※単語連結手法については、もしご興味があれば、先行してREMMのサイト(http://remm.work/)をご覧ください。BEMの亜流・改良版で、この仕組みの利点を生かしやすくなっています。

次の記事を公開次第、以下の関連記事にリンクを追加します。

関連記事

詳細記事

クレジット・その他

Ultimate Coding
概要・前提事項

この仕組みは、組織所属時に業務効率化のために構築したものであり、許可を得た上で設計者本人が個人活動として公開しています。商用の制作や開発には利用していただけますが、仕組みを販売したり媒体化するなどの、制作以外での商用化はご遠慮下さい。質問その他、何かあれば@croco_worksまでお声かけください。

croco_works
Webデザイン/UIデザイン・フロントエンド・システム設計、ディレクター・PMを経験後、現在はWebサイトやサービス開発などの企画・設計人として活動中
https://twitter.com/croco_works
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした