はじめに

HTML+CSSコーディング専用の粒度分類を紹介します。
この仕組みは、デザインやワイヤーフレームなどの視覚情報を分解することに焦点をあて、分解した対象を部品化する流れも併せてガイド化した汎用手法です。
世の中には、コーポレートサイト / ポータルサイト / サービスサイト / システム管理画面 / ブログサイト…　といった様々な種別のサイト、Webページがありますが、これらの「完成予想図（視覚情報）」を同じ方法で分解して、コーディング用の部品にできます。

粒度と言えばAtomic Designが有名ですが、この「HTML Parts」も粒度そのものの考え方についてはAtomic Designの踏襲です。その上で「思考の入り方・捉え方」や「名称と定義」をコーディング側に寄せることで、CSS設計やコーディング業務を標準化しやすくしています。

※この記事は標準化ノウハウ公開の一環として書いています。
仕組みの概要や前提事項などについては「UltimateCoding 概要・前提事項」のエントリをご確認ください。

前置きとAtomic Design

そもそもAtomic Designをコーディング視点で評するのはお角違いかもしれませんが、業界の一部ではAtomic Designを"コーディングの万能薬"として組み入れようとする試みがあったのも事実です（今でも探せばそのようなブログ記事やサイトを見ることができます）それほど、画期的かつ魅力的な概念でした。

主題に入る前に、「Atomic Designは、なぜコーディングの万能薬にならなかったのか」を簡単に分析・箇条書きします。

• 小さなものから積み上げていく概念と、多くのコーディングで必要となる分解の行動が相反する
• TemplatesとPagesが別の意味を喚起してしまい、そのままコーディングに使うと混乱する
• サイト種別や規模によっては、図のA側に欲しい粒度が一つ不足することがある

といった所でしょうか。良い解決方法があるかのもしれませんが「そのままの状態で万能か？」と言われたら、そうではないでしょう。
しかしこれは、Atomic Designが不出来だとか、不完全であるといいたいのではありません。デザインを始原としたメンタルモデルや設計・方法論を説いた仕組みを、「同じ概念で作られていない他のプロジェクトのコーディング全て」に転用しようとしても、やはりどこか無理が出てくる。というお話です。

HTML Partsの概要

では、本題の「コーディング側から考える粒度分類」の話です。
HTML Partsは、以下のようにデザインやワイヤーフレームを「大きなものから小さなものへと分解」する事で粒度を分類します。

この方法は、改めて言われなくとも既に多くの制作者が自然とおこなっているであろう流れ・ステップです。こういった一般的な流れの上にガイドを沿えることで、思考による変換や再構築を発生させず、負担がかかりにくいものとして提起します。

また、これがもしAtomic Designによって「システマチックに作られたプロダクト」であったとしても、同じように上から綺麗に分解できることでしょう。

実用の見通しと説明内容

粒度の概念を実際のコーディングに実用するためには、以下の3つの内容把握と、Sassファイル管理の仕組みが必要となります。

1. 視覚情報の分解方法 を把握
2. 部品再利用設計の考え方 を把握
3. 粒度の定義 を把握

以降、上記の順に従って説明します。
Sassファイルの管理方法については、最後に要点を述べた上で、今後別の記事で詳しく説明します。

1 ・ 視覚情報の分解方法

まず1つめの、具体的にどのように分解するのかについての説明です。
方法はいたってシンプルで、分解する対象である「完成予想図」を用意し、以下の図のように大きなものから4つの粒度によって分解していきます。

図は企業系サイトを例にしていますが、サービス系サイト、ポータル系、システム管理画面、LP、ブログなど、どんな種別であっても「Webページの視覚情報」がある限り、分解手順そのものは同じです。

また、上記の図と、この記事の情報は、過去記事「1段上のCSS設計・コーディングの概念図」の内容と連動しています。この記事を単独で読んでも意味は通じますが、より良く利用したい場合には併せてご覧下さい。

図との対応としては、左の2つの概念を実用するためのガイドが「HTML Parts」です。「Block」が今回のBlockと等価で、「Parts」が、今回のModule / Component / Elementに細分類されます。

2 ・ 部品再利用設計の考え方

粒度の具体的な説明に移る前に、重要な考え方・ポイントを先に説明します。
何かというと「粒度分類と実装は別で考える」という事です。ここを一緒にして捉えると後で混乱のもとになるため、先に2つの意味を説明します。

1 ・分類は必ず発生している

まず、分類そのものは常に発生しています。どういうことかというと、仮に、デザインやワイヤーフレームを紙に印刷して、ペンで四角い線を引いて分解しながら囲っていったとします。もうこれ以上分解できない。という所まで線をひくと、実質、紙の上に全ての粒度が洗い出されたことになります。
そして、特定の部分を見て、「AtomicDesignではこれはAtomsと呼ばれている」とか、今回の「HTML PartsであればElementと呼ばれている」というように、変わりようのない定義・事実として認識できます。

これが、分類は必ず発生している。という意味です。そして、この時点では実装に関する決めごとは何も発生していません。決める（設計する）のは制作者です。

2 ・どのように部品化するのか

次に、部品をどのようなコードで実装するか。という話です。
判断・意思決定するのは1つだけ。「その対象(部品）を、グローバルに再利用するかどうか」です。これが、CSS設計が大きく切り替わるポイントとなります。

「グローバルに再利用する」とは、以下のようなものです。

これは、CSS設計手法の「OOCSS」と同じ方向にある手法で、システム管理画面やサービス系サイトなどの「システマチックなサイト」で利用したくなるものです。

もし、上記のように再利用しないのであれば、その部品は以下のように「上位粒度の所有物」としてスタイリングします。

これらの図をテキストでまとめると以下のようになります。

1・単体でグローバルに再利用できるCSSを書く

図：スタイリングパターンA

2・上位粒度の所有物となるCSSを書く

図：スタイリングパターンB

図：スタイリングパターンC

そして、これらを「サイト全体視点」と「部品単独視点」の2つの軸で判断していくことが、「CSS設計」の中核であり重要ポイントになります。

これらの前提を踏まえた上で、以下から粒度の説明をおこないます。

3 ・ 粒度の定義把握

各粒度の詳細説明です。
それぞれに細かな定義や判断基準などを記載していますが、先述の通り「粒度分類と実装は別」であり、これらはあくまで制作のためのガイドです。制作者の判断以上に強い立場ではありません。

レギュレーションによって「完全遵守・例外は認めない」と定めるなら話は別ですが、そうではないなら「その視覚情報をどのようにコード管理したいのか」という、制作者の意思・意図を優先し、"ねばならない"の思考に捕らわれることがないようご注意下さい。

1 ・ Block

Block（ブロック）は、情報の意味や役割的に自立・独立した領域や区画・塊です。
機能・役割・情報属性などの基準によって、制作者が「これ以上は他と同じにできない」と判断した範囲によって切り出します。

多くの場合はdivによるコンテナに名前が与えられます。

Blockの粒度判断

粒度の判断は、主たる情報である「コンテンツ」と、ヘッダー・フッターなどの「フレーム」部分とで分けて考えることができます。具体的には以下のようになります。

• コンテンツ
  • article section asideといったタグでマークアップできそうな範囲
  • 見出しに使うhタグを含むもの（文書上の暗示・省略されたものも含む）
  • 任意の構造体が入りそうなもの
• フレーム
  • ルートのheader main footerや、nav の領域

また、これらは、プロジェクトやデザインの文脈によって解釈が異なるというのはあり得る話です。
例えば、同じブランディングエリアであっても、ヘッダーバーの中に小さくあるものと、ブラウザ全面に画像や動画が敷かれ、数点のリンクと共に中央に配されるようなブランディングエリアとでは解釈・役割が異なるでしょう。

Blockの部品作成方法

block/にSassファイルとして切り出してCSSを管理します。
もし、Blockの内部部品に「下位粒度のグローバルな再利用部品」（スタイリングパターンAで作られた部品）を設置する場合は、Blockはそれらの部品を設置するための枠組みのような役割にとどまるでしょう。
逆に、Block内部の部品を自分の一部としてスタイリングする場合は、先述のスタイリングパターンB・Cどちらかでスタイリングすることになります。

Blockのユースケース

コーポレートやブログ、ブランディング、LPなどの情報発信系サイトであれば、よほどの規模ではない限り、この分類でコード化は完成するのではないかと思います。
内部部品はスタイリングパターンB/C（※近年の慣例手法はCのBEM式）のみで作成し、同じ部品が何度か登場したとしても、パターンAの代わりに、SassのExtendやMixin機能で同一コードを流用して完成させるような方法です。

参考情報

余談・参考情報になりますが、bodyタグ直下に機能的・慣例的に設置する.wrapperといった命名の「全体包括要素」もBlockであると捉えると、「Block同士は恒常的にネストする」という意味が理解しやすくなります。※このとき、思考のつじつまが合いやすい命名は.siteです。

<body>
    <div class="site"><!--この中にあるのは「サイト」の表示用データ-->
        <div class="site-header"> <header>…</header> </div>
        <div class="site-main"> <main>…</main> </div>
        <div class="site-footer"> <footer>…</footer> </div>
    </div>
</body>

また、コンテンツのBlockも同じ構造を意識してマークアップすることで、サイト全体のコードがフラクタル構造（自己相似）となり、ルールが捉えやすくなります。（※サンプルはBEM記法で記載）

<div class="photo-gallery"><!--この中にあるのは「写真ギャラリー」表示用のデータ-->
    <section>
        <div class="photo-gallery__header"> <header>…</header> </div>
        <div class="photo-gallery__body"> … </div>
        <div class="photo-gallery__footer"> <footer>…</footer> </div>
    </section>
</div>

2 ・ Module

Module（モジュール）は、単体でも機能しそうな中程度の情報の塊です。
カードや、ギャラリーの1区画。会員証を模したようなもの、プロフィールのひと塊、ECサイトの商品一覧、メニューナビゲーションの1区画などが該当するでしょう。

多くの場合はdivによるコンテナに名前が与えられます。

Moduleの粒度判断

粒度の判断は、コンテンツ部分とフレーム部分で分けて考えられます。
下位粒度のcomponentが集まったものと捉えるとイメージしやすいかもしれません。

• コンテンツ
  • Blockほどの情報の規模感は無いが、単独でも機能しそうな視覚情報の塊
  • 場合によっては任意の構造体が入りそうなもの
  • その場でリピートして使われそうなもの
• フレーム
  • ブランディングエリアや、コンタクト情報 等
  • ブランディングエリアや、サイトマップリンク、コンタクト情報 等

Moduleの部品作成方法

自身をグローバルな再利用部品として管理したい時に、module/ディレクトリに切り出して管理します。そうではないなら、この粒度のものは、上位粒度の持ち物としてスタイリングが完了しているはずです。

Moduleのユースケース／この粒度は必要か

ModuleはBlockと近い存在となります。特にBEM記法を使っているとBEMのBlockの概念と相まって「粒度が違えば全てModuleディレクトリに切り出さないといけないのか？」となる事もあるでしょう。そういった管理が煩雑になる場合は、Blockとして管理しても何も問題ありません。（究極は、制作者が混乱しなければよいのです）

では、定義の意味は？

「であれば結局は無法地帯では？」と思われるかもしれませんが、そうではありません。どんな時にこの粒度が有用かというと、1つは再利用の明示です。
Blockは最上位にあるため、どのように再利用しているのか、もしくはしていないのかはHTMLファイルを要調査。となりますが、Moduleディレクトリに置いただけで「どこかで必ず再利用されている中粒度部品」もしくは「どこで再利用してもよい中粒度部品」として意識づけできます。
最初にBlockのディレクトリにSassファイルを置いていても、後から上記のように明示したくなった場合は移動させることもできます。

システム開発との連動

もう1つ有用なパターンは、ECサイトやサービスサイトなどのシステムが絡む時です。
システム側のフロントテンプレートなどにおいて「モジュール」として切り出すものは、この粒度と同じ規模感になるものも多くあります。それぞれ同じModuleという名称のディレクトリで管理すれば、双方が意識上対応したものとして管理できます。

このように、実用時には必要に応じて使い分けられる粒度となります。

3 ・ Component

Component（コンポーネント）とは、見出しやボタン、リストや表組などの、単体でもその部品の機能や目的・情報が分かる小さな要素です。
ModuleやBlockから見れば、自分達を構成する小さな部品群で、下位粒度のElementのから見た時には、Elementの組み合わせがComponentであると表現できます。

この粒度のものには「構造体」や「文書構造」が入ることはありません。
divやspanのラッパーに名前を与えることもあれば、ul ol tableなどに名前を与えることもあるでしょう。

Componentの粒度判断

文書構造や構造体が入る余地・感覚が無いもので、かつ、以下の1～4のうち、1つでも当てはまればComponentとなります。

• 視覚情報
  • 1・視覚情報として分割できる
• HTMLコード
  • 2・HTMLタグがHTMLタグでラップされている
  • 3・内部を自然に拡張できる
  • 4・コードとして分割・分離できる

また、レンダリング結果はElementと同一になるが、コード側から見ればComponentと判断できるものがあります。以下のようなパターンです。

コード側から見てComponentになる例

imgタグ単体は後述するElementにあたりますが、これを<div class="image">などでラップすれば、.imageは立派なComponentです。「分解・分離できる状態」であり、後に内部にキャプションを入れるなど、「自然に拡張できる状態」になっています。

同様に、pタグだけの文章はElementの粒度にあたりますが、これを<div class="text_box">といったような命名のボックスでラップすれば、同様にComponentとなります。文章が追加されても、新たなpタグによって内部を自然と拡張できます。

Componentの部品作成方法

自身をグローバルな再利用部品としたい場合に、component/ディレクトリに切り出して管理します。そうではないなら、この粒度のものは、上位粒度の持ち物としてスタイリングが完了しているはずです。

Componentのユースケース

Componentをグローバルな再利用部品として作成・運用したくなるのは、システム管理画面やシングルアプリケーション系のプロダクト、ブログの記事内の部品、サービスサイトのUI部品などでしょう。
OOCSSの概念と併用する事が多くなるでしょうし、"既製品"としてBootstrapのようなCSSフレームワークを利用する事になるのかもしれません。

小規模でシステマチックではない静的サイトであれば、Blockの項に記載したとおり、Componentは全て上位粒度の持ち物としてスタイリングした方が効率よく管理できるでしょう。

部品の集まりをどう捉えるか

この粒度のものは、幾つかの部品が集まり特定の機能になる場合もあります。例えば、ボタンが複数横に並んで連結されていれるような場合です。これはComponentの集まりである。と捉える事もできますし、divでラップして「ナビゲーション」という意味の名前を与えればModuleにも、Blockにもできます。
つまり、そのプロジェクトにおいて、対象の部品をどのように管理したいか。という制作者の意思・意図が第一優先です。それをサポートするように、振り分けできる手立てが用意されている。という事になります。

参考情報

Componentは特性として2つの属性のものがあります。
1つは、テーブル（table）やリスト（ul,ol,dl）など、HTMLの仕様により内部構造が定められているものです。これらは、HTMLの仕様に従い内部を拡張できますが、使えるタグは限られています。

もう1つは、「アイコン＋タイトル＝メニュー項目」「ラジオボタン＋テキスト＝選択部品」とするなど、制作者の意図により小さな部品を組み合わせてComponentとしたものです。

※この区分けは粒度分類には影響しません。属性的に2つのものがあるという参考情報です。

4 ・ Element

Element（エレメント）は、表示上の面積に関わらず、視覚情報上もしくはコード上でもそれ以上部品分解できない最小の要素です。
Elementの組み合わせ、もしくは単体を何らかの要素でラップすれば、Componentとなります。

imgやinputなど、直接レンダリングされるタグやspan、iなどに名前を与える事があるでしょう。

Elementの粒度判断

それ以上分割できない要素で、一行のテキストや、ラジオボタン、チェックボックスなどです。無理に分割しようとすると、意図した情報伝達ができない、機能不全になる、コードとして成立しないといった不都合が起きるようなものが該当します。
また、粒度はレンダリング時の面積にとは関係がありません。いくら面積の広い画像を配置しようとも、imgタグレベルは一様にElementの粒度となります。どれだけ巨大なアイコンや、ラジオボタンを配置したとしても同じ事が言えます。

Elementの部品作成

自身をグローバルな再利用部品としたい場合に、element/ディレクトリに切り出して管理します。そうではないなら、この粒度のものは、上位粒度の持ち物としてスタイリングが完了しているはずです。

Elementのユースケース

この粒度をグローバルな再利用部品として作成・運用するとなると、独自にCSSフレームワークを作る。もしくは、ドラッグ＆ドロップでサイトを作っていくようなサービスを構築する時でしょうか。※他にも用途はあるかもしれません

その他

プレフィックス

実用する際には、これらに名前を与えてからCSSプロパティを書くことになりますが、命名時のプレフィックスのルールはここでは定めません。（ガイドという立場として、特に奨励も制限もしません）
制作の必要性に応じて「再利用前提のものは m- c- e- を付与する」など、それぞれ使い勝手が良いように自由にルールを制定してください。

アイデア

これはまだ試せていませんが、1つのアイデアとして、この粒度分類を逆にデザインシステム側に反映できるかもしれません。コーディング側で最適化したものをデザインシステムに乗せられたなら、スムーズに連携できる可能性はあります。

粒度の総括

以上、4つの粒度をコーディングの側面から定義しました。
分類そのものの本質部分を見ればAtomic Designのそれと非常に近いものですが、思考の入り方と語句の定義を変えただけで、人の認識や使用感は異なったものになります。
では、これが万人向けするのか。といえば、それは分かりません。しかし、少なくとも1つの組織と協力会社において使用する限り、破綻などの問題がゼロであることは事実です。

HCDCモデル図と今回の「HTML Parts」、そして、次回公開する「Sassファイルディレクトリ管理手法」によって、より多くのサイト種別に対応した設計がおこないやすくなります。

Sassファイル・ディレクトリ管理

これらの粒度の名称は、そのままSassファイル管理ディレクトリの名称として利用することになります。
部品化の方法としては、先述の通り「グローバルに再利用する場合」のみ、その粒度のディレクトリに部品を切り出して管理します。

しかし、これらを含めた全体をどのように管理するかは、また別の話となります。これはCSS設計の命題のひとつであり、概念を実務利用するための重要事項となります。

次回紹介するものは、プロジェクトごとにカスタマイズ可能なSassファイル管理の仕組みです。標準ルールを中心として、同じロジックでいくつものサイトタイプに柔軟に対応できます。

この記事作成時点での実務利用実績は以下の通りです。
コーポレートサイト / ポータルサイト / サービスサイト / システム管理画面 / ブログサイト / ECサイト（オンラインショップ） / ランディングページ（LP） / イントラサイト

この管理方法についての情報は、投稿次第こちらの記事からもリンクします。

関連記事

• CSS設計・Sassディレクトリ管理の標準化（CROCSS）
• 1段上のCSS設計・コーディングの概念図（HCDCモデル図）
  • Web制作者の行動分析と考察／HCDCモデル図が出来るまで
• HTML+CSSコーディングの言語化

クレジット・その他

Ultimate Coding
概要・前提事項

• 設計・考案／構築／記事投稿
  • @croco_works - Twitter
• 設計パートナー／技術検証
  • @wildwest_kazya - Twitter

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