はじめに

Webサイトの中長期的な運用を見据えて、「設計」すべきものはいまやJavaScriptだけではありません。

度重なるコンテンツの増減や修正を効率よく行うために、どのようにCSSを書いていけばいいのでしょうか。

この連載では、「FLOCSS」という設計思想をベースに、CSS設計について解説します。

今回は、なぜCSS設計が必要なのかという点と、FLOCSSの基本についてです。

誰でも書けるCSSをあえて「設計」する

私たちエンジニアは、デザイナーが作ったデザインカンプをwebページとして再現するためにCSSを書きます。
CSSを用いてデザインを再現することは、決して困難なことではありません。

困難ではないにも関わらず、コーディングに関わる人の多くが、CSSを書くことに悩みを抱えます。
いったい、何が問題になった時に悩んでしまうのでしょうか。

「新規作成」よりも「修正」で悩む

CSSを書いていると、多くの場合で、「修正」に問題が発生します。

例えば、不要になったコンテンツを削除した際に、それらに寄り添うように配置されていたコンテンツたちがつられて崩れてしまってしまった経験はありませんか？

また、一部の装飾を変更したつもりが、意図せぬ場所まで影響が及んでしまい、上書きを繰り返すことになった経験はありませんか？

Webサイトの「修正」は必然

どんなWebサイトも、運用の中で形を変えてより優れたサイトに変化していく ものです。
その中で、修正作業の発生は必然です。

しかし、どのような修正が入るかはわかりません。
なぜなら、Webサイトを取り巻く要因によって都度最適な形が存在する からです。

Webサイトは、運用することによって利益を生むこと が大事です。
優れたCSSを書くこと自体が利益になるわけではありません。

しかし、CSSを書くことをないがしろにしたが故に、工数が膨れ上がることは、損失にあたります。 規模の大きいサイトほど、損失は大きくなることは言うまでもありません。

工数がかからず、損失を出さないCSSこそが、価値のある優れたCSSと言ってもいいでしょう。

私たちエンジニアは、その前提のもとで、よりよいCSSを書くということを目的にすべきです。

理想のCSSは、どうあるべきか？

GoogleのエンジニアであるPHILIP WALTON氏のブログによると以下のように書かれています。

4つのポイントがあります。

予測可能である

予測可能なCSSは、期待した場所に、期待した通りの振る舞いをします。

どこに影響が及ぶかわからない、どのように振る舞うかわからない、ではいけません。

再利用可能である

再利用可能なCSSは、ある場所で解決した動作を、再びコーディングすることなく別の場所で用いることができます。

一つのルールで「こんな見た目でこんな配置、こんな風に動く」と定めてしまうことは再利用できる可能性を奪います。

できるだけ抽象的に、機能を分離する必要があります。

維持できる

維持できる（＝保守性の高い）CSSは、新たな機能を追加しても、既存の機能を阻害しません。

新しく機能を追加した際に、それが別の機能を阻害するがために、都度見直しが必要になっては工数が増えてしまいます。

拡張性がある

拡張性があるCSSは、多くの開発者の手によって拡張されていく際に、管理コストを下げます。

例えば、学習コストが低いことで、書いた本人でなくても修正が可能である必要があります。

FLOCSSとは

FLOCSSとは、Hiroki tani(@hilokiによって考案された国産のCSS設計思想です。

ドキュメントはGithub上に公開されています。

本連載では、このドキュメントをベースに、実際にコードを交えて解説していきます。

hiloki/flocss : CSS organization methodology.

FLOCSSの基本構成

FLOCSSは、下記のように3つのレイヤー、及び３つの子レイヤーによって構成されます。

• Foundation
• Layout
• Object
  • Component
  • Project
  • Utility

それぞれのレイヤーの役割

各レイヤーの役割は以下の通りです。

Foundation

Reset.cssやNormalize.cssなどの リセット系CSS 及び、要素セレクタの基本スタイル を定義します。

Layout

ヘッダー、フッター、サイドバー、メインエリアのように、サイトで共通したコンテナー を定義します。

Object

Webサイトの中で用いられるすべての ビジュアルパターン を総称して定義します。Objectは、さらに３つのレイヤーに分けられます。

Component

ページを最低限の 機能単位で分割したモジュールのスタイルを定義します。

Project

プロジェクト固有のパターン を定義する。Componentとそれに該当しないものによって構成されるものがこれにあたります。

Utility

ComponentとProjectレイヤーのObjectのモディファイアで解決することが難しい・適切では無い、わずかなスタイルの調整のための便利クラス などを定義します。

命名規則はMindBEMding

FLOCSSでは、MindBEMding を使用します。
これは、BEMという設計思想を元にした命名規則です。

モジュールをBlock、Element、Modifierにわけて考え、それぞれを.Block__Element--Modifierのようにつなげて記述します。
（詳しくは次回以降で解説します。）

接頭辞（プレフィクス）をつける

FLOCSSでは、クラスがどのレイヤー属しているかによってそれぞれ接頭辞をつけます。

これにより、クラスがどのような役割を持っているのかわかるため、「予測しやすく」 なります。

また、予測しやすいことは開発者にとっても意図がわかりやすいため 「拡張しやすい」 とも言えます。

レイヤーとそれに対応する接頭辞は下記の通りです。

• Component : .c-
• Project : .p-
• Utility : .u-

さらに、状態を表すクラスの接頭辞として.is-を使います。

これは、SMACSSという設計思想における「State」パターンに由来するものです。
参考：SMACSS

（例）ナビゲーションの現在位置を表す要素に.is-currentを与える。

今、なぜFLOCSSを選択するのか？

数ある設計思想のうち、FLOCSSを取り上げた理由。
それはFLOCSSが 「幅広い思想のいいとこ取り」 であるという点です。

FLOCSSは、OOCSS,SMACSS,BEM,SuitCSSといった既存の設計思想を組み合わせたものがベースとなっています。

様々な思想の組み合わせとはいっても、単純に結合したわけではなく、それぞれの思想のいいところを組み合わせたものです。

ベースとなったそれぞれの設計思想は、それぞれの開発者が経験則に基づいて考案したものです。

それらをさらに組み合わせることで生まれたFLOCSSに触れることで、様々な開発者の様々な意図を取り入れることができます。

また、本連載は 「FLOCSSを覚える」ではなく「FLOCSSを通して、よりよいCSSを書くための設計力を高める」 ことを目的としています。

それぞれのレイヤーについて解説を通して、設計上のどういう部分を担っているのかということを考えながら読んで、実践してほしいと思っています。

まとめ

• CSS設計は修正コストを減らし、拡張性を高めるために必要
• よいCSSとは「予測しやすく」「再利用しやすく」「保守しやすく」「拡張しやすい」
• FLOCSSは「Foundation」「Layout」「Object」レイヤーの3レイヤーから成る。
• 「Object」レイヤーはさらに「Component」「Project」「Utility」の３レイヤーに別れる
• FLOCSSは既存の設計思想のいいとこ取り

次回からは、デモを交えて実際にコードを書いていきます。

---

この連載に関するご意見やご感想がありましたら、ぜひtwitter(@nayucolony)までお気軽にリプライ、DMをお願いします。

気に入っていただけましたら、Facebookでのシェア、いいね、Tweet、はてブなど、お願い致します！