North Detail / ノースディテール

BLOG ブログ

ブログ
CATEGORY
TECH

css設計・命名規則の歴史(BEM・OOCSS・SMACSS・FLOCSS・tailwindcss)

前置き

css設計・命名規則の件ですが、マークアップする上で避けては通れない比較的面倒な悩み事です。
案件によってはクライアント様側からのルールが決められている場合もあり、その場合はそのルールに則って構築すれば済むことですが、一般的にはマークアップする方にお任せされることも多いですね。
その場合、個人の好みだったり、その時の流行りなどから、悪く言えば適当に設計されることも多いかと思います。
なんだったら「css設計ってナニ?」的な場合も多々見受けられます…
新規構築も、運用も1人で全て行うような案件であれば問題ないとも言えますが、チームでの構築や運用は別の方(もしくは別会社の方)が行うような場合は、その設計自体や命名規則などがハッキリとしたルールに則っていなければ、それ自体を読み解くことに時間を費やされ、結構な負担となります。

実際に新規構築する際に「なぜ class名を考えるのにこんなに時間を使っているんだろう」って思うこともありますし、運用フェーズでちょっとしたレイアウト改修などの際に「ここのスタイル記述を変更したら影響範囲はどこまでなのだろうか?」などと、思い悩んだり検証・調査に時間を無駄にすることもあります。
当たり前ですが、最初からある程度明確にルール化されていると、無駄に悩んだり検証する時間はぐっと少なく抑えられると思います。

明確なルール化するためにも
マークアッパー達が今まで散々悩んで…闘ってきた歴史をまとめたいと思います。

世間一般的に認知されている設計手法

  1. BEM
  2. OOCSS
  3. SMACSS
  4. FLOCSS
  5. tailwindcss

BEM

BEMは、Block(大きな括り)・Element(ブロック内の要素)・Modifier(Block・Elementの亜種パターン)の頭文字をとったもので、厳格なクラス命名規則が特徴の手法です。
画面構成する要素を、この3つのどれかに当てはめてクラス名を付与していきます。

命名規則

命名規則的には BlockElementModifier の順でつなぎ合わせます。

  • block と element はアンダースコア2つで区切る
  • element と modifier はハイフン2つで区切る
  • 各々が複数単語になる場合はハイフン1つで区切る

例えば common-list という blockの中に common-title という element がある場合この elementのクラス名は common-list__common-title になります。

設計規則

  • block の子として block が登場してもよい
  • block の無いところに element が登場してはいけない
  • シングルクラスで記述する
  • 記述は親和性の高い scss(sass) 推奨

メリット・デメリット

  • スタイルの使いまわしが少なく class名で範囲が絞られるため、メンテナンス性が良い
  • class名が冗長になり、巨大なサイトだと命名する際に意外なほど疲れる…
  • 同じスタイル記述(marginとかfont-sizeとかpositionとか…)を何度も書く羽目になる…
  • 固有(ユニーク)レイアウトが多いデザインだったりすると、とてつもない量の css を書く羽目になる…

記述例

<div class="Block">
    <div class="Block__element">
        <div class="Block__element--modifier"></div>
    </div>
</div>
.Block {
    &__element {
        &--modifier {
        }
    }
}

OOCSS

Object Oriented CSS の略語で、『構造と見た目を分離』することを心がけて設計・記述していくオブジェクト指向cssという概念になります。
ザックリいうと位置・レイアウト・大きさなどの構造系のプロパティと、色・装飾などの見た目に関するプロパティを、同じクラス内に記述してはいけないという考え方になります。
ある意味、設計手法というより 【心がけ】 ですね。
Atomic Design でいうところの『分子(molecule)』モジュールを使用するような設計になります

設計規則

  • 構造に関する記述と、見た目に関する記述を切り分ける

メリット・デメリット

  • 初期構築・設計をキチンとガッツリしておけば、サクサク構築できる
  • cssの記述自体を少なくすることができる
  • htmlタグに付与された class名を見ただけで、構造・スタイルがある程度把握できる
  • それぞれが独立したパーツ構成なので、CMSなどとの親和性が良い
  • 影響範囲が分かりずらいのでメンテナンス性が悪い

記述例

OOCSSではない記述例
<ul>
  <li class="label-news">NEWS</li>
  <li class="label-pickup">PICKUP</li>
  <li class="label-info">INFO</li>
</ul>
.label-new {
  margin-right:.5em;
  padding:.2em 1em;
  display:inline-block;
  background-color:yellow;
}
.label-pickup {
  margin-right:.5em;
  padding:.2em 1em;
  display:inline-block;
  background-color: pink;
}
.label-info {
  margin-right:.5em;
  padding:.2em 1em;
  display:inline-block;
  background-color:#73d1fa;
}
OOCSSだとこうなる記述例
<ul>
  <li class="label label-news">NEWS</li>
  <li class="label label-pickup">PICKUP</li>
  <li class="label label-info">INFO</li>
</ul>
.label {
  margin-right:.5em;
  padding:.2em 1em;
  display:inline-block;
  &-news{
    background-color:yellow;
  }
  &-pickup{
    background-color:pink;
  }
  &-info{
    background-color:#73d1fa;
  }
}

SMACSS

SMACSS は、Scalable and Modular Architecture for CSS の略語で、厳格なフレームワークというものではなく、スタイルガイド・設計する上での概念です。

基本的な考え方は OOCSS と同じで、オブジェクト指向な記述方法です。
おおまかに下記のように5つに分類・細分化して記述していきます。

  • ベース(base.css):要素そのもののデフォルトスタイルを定義
    要素セレクタ・属性セレクタ・擬似クラスセレクタなどのスタイリングを指定します(ID・classなどは指定しません)
  • レイアウト(layout.css):画面をエリアごとに分割するためのスタイルを定義
    『l-』や『layout-』などの接頭辞を付けてレイアウト要素を指定します
  • モジュール(module.css):再利用可能な単位でパーツの見た目を定義
    再利用可能な粒度で、各パーツを具体的に指定します
  • 状態(state.css):レイアウトやモジュールの特定の状態におけるスタイルを定義
    特定状態によってスタイルを指定します(jsなどで動的処理場合は『is-』接頭辞を付けたりします)
  • テーマ(theme.css):サイトのトンマナ(統一性)を定義
    サイト全体の見た目や、雰囲気を統一させるためのスタイルを指定します

メリット・デメリット

  • 構造・カテゴリを分類化することで記述コード量を少なくする
  • メンテナンス性もある程度担保できる
  • 作業者全員にルール共有をしておかないと、カオスになりうる

記述例

ベースの記述例
body {
    background:white;
}
input[type=text] {
    border:0;
}
a:visited {
    color:red;
}
レイアウトの記述例
.l-main {
    width:70%;
}
.l-sub {
    width:30%;
}
モジュールの記述例
.c-buttonType_normal{
    padding:10px;
    text-align:center;
    min-width:150px;
    background:#000;
    border-radius:5px;
}
状態の記述例
.is-hidden{
    display:none;
}
テーマの記述例
.theme-background_red{
    background:#c00;
}

FLOCSS

FLOCSS は、Foundation Layout Object css の略語で、BEM・OOCSS・SMACSS・SuitCSS・MCSS などの考え方を取り入れた設計手法で、基本的な命名規則は MindBEMding を採用し、【Foundation・Layout・Object】の3つのレイヤーで構成します。
また、Object レイヤーには、【Component・Project・Utility】の3つの子レイヤーを持ちます。

ファイル構成

  • Foundation:サイト全体のデフォルトスタイルを定義
    ※reset や mixin などの大元に関わるスタイル
  • Layout:各ページを構成するサイト全体で共通したエリアを定義
    ※header・footer・メインカラム などの共通レイアウトに関わるスタイル
  • Object:サイト全体で再利用できるパターンを持つモジュールを定義
    ※画面を問わず様々な場所・場面に関わるスタイル
    • Utility:最小粒度のスタイルを定義
    • Component:再現率の高い・よく使用されるレイアウトなどの Utility スタイルをまとめて定義
    • Project:共用性が低いユニークデザインに対応するスタイルを定義

メリット・デメリット

  • ディレクトリ・ファイル構成をルール化することにより、改修時に修正するファイルが分かりやすい
  • ファイルをルールに則って細分化することにより、css自体の可読性が良くなる
  • 微妙なパターンも多々あり、分類すること自体に悩むことがある…
  • class名が冗長になり、巨大なサイトだと命名する際に意外なほど疲れる…

記述例

<a class="c-btnLayout c-btnLayout_red u-ma3" href="#">Button</a>
.c-btnLayout {
    padding:.25em 1em;
    text-align:center;
    display:inline-block;
    border:1px solid #333;
    border-radius:.25em;
    &_red {
        color:#fff;
        background:#c00;
    }
}
.u-ma3 {
  margin:1.5em;
}

tailwindcss

tailwindcss は、バージョン2.0 がリリースされたばかりの今注目のフレームワークです。
CSSフレームワークといえば Twitter Bootstrap が代表的ですが、大きな違いは、その粒度になります。
tailwindcss は、Atomic Design でいうところの『原子(Atom)』モジュールのみ使用するような設計となり、ユーティリティーファーストCSSフレームワークというカテゴリーに入ります。

今まで様々な理由・思考で付与してきた『class名』ですが…ユーティリティーファーストCSSフレームワークの概念では、それ自体に悩む時間や手間を完全にゼロにしてくれます!

tailwindcss公式サイト

設計規則

  • 絶対に基本となる css を書き足さない!w

メリット・デメリット

  • class名を考える時間がゼロに!
  • css を書く時間がほぼほぼゼロに!
  • 改修時にもcssをイジる必要がなく、classを付け替えるだけ!
  • jsフレームワークを使用した Webアプリケーションなどとの親和性が高い
  • htmlタグにclassをズラズラと並ぶのが少しくすぐったい。。。

記述例

<button
  type="button"
  class="inline-flex items-center px-4 py-2 border border-transparent text-sm font-medium rounded-md shadow-sm text-white bg-indigo-600 hover:bg-indigo-700 focus:outline-none focus:ring-2 focus:ring-offset-2 focus:ring-indigo-500"
>
 Button
</button>

まとめ

先人たちは、イロイロな観点・角度から少しでも分かりやすく・時間をかけずに!を心がけて様々な手法を提唱してきました。
まさに闘いであり、歴史ですね!
結局のところ『これが完璧!』というものはないです…ハイ。
どの手法にも、必ずメリット・デメリットが存在していますし、案件の種別に依存することもありますし、時の流れとともに新しい手法や考え方が、次次に誰かが唱えてくることでしょうから…

私個人の考えとしては『どの手法を選択する』ではなく、イロイロと検証し、学んで、『様々な手法の良いところだけを使っていこう』です。

  • BEM の厳格な命名規則をヤンワリと踏襲
  • 構造と見た目を分離するという OOCSS の概念を踏襲
  • SMACSS のように構造細分化・カテゴライズを踏襲
  • FLOCSS のような分かりやすいファイル構造を踏襲
  • よく使用するユニークではないコンポーネント・モジュールは tailwindcss を踏襲

上記の良いところをイイ感じにミックスさせれば、最終的に良いのではないかと。
結局一番大事なのは『ルール化・ルールの共有』ですね( ̄^ ̄)ゞ

nanba
WRITER:nanba
高い技術力を誇る『NorthDetail』内では珍しい『チカラワザ系コーダー』
主な記事 一覧へ

一覧へ

IS 501383 / ISO 27001