前回までで、Enduring CSS（以降ECSS）の考え方を紹介してきました。ECSSというのは端的に言うと「分けて考えよ」という設計思想です。当たり前ですけれども、どう「分けて」考えるかは、設計者自身に判断が任されています。

ECSSには、Webアプリケーション向けに考えられた設計方法であると書かれていますが、筆者Takazudoとしては、より広い範囲で応用できる考えだと感じました。今回は、どのようにECSSの考え方を活かすべきかという点について考えてみます。

コンポーネント指向のフレームワーク

2017年時点において、ReactやAngularのようなコンポーネントベースでWebアプリケーションを構築できるフレームワークが台頭しています。このようなフレームワークでは、コンポーネントの中にだけCSSを適用するアプローチを取ることができます。

• Reactを使ったモジュラーCSS : CSS-in-JSとCSS Module | POSTD
• CSSモジュール ― 明るい未来へようこそ | POSTD
• Angular – Component Styles

例えばAngularでは、コンポーネントを定義するファイルの中で、以下のようにstyleUrlsにCSSファイルへのパスを指定することができます。

@Component({
  selector: 'hero-details',
  template: `
    <h2>{{hero.name}}</h2>
    <hero-team [hero]=hero></hero-team>
    <ng-content></ng-content>
  `,
  styleUrls: ['app/hero-details.component.css']
})
export class HeroDetailsComponent {
  /* . . . */
}

ここで指定されたCSSファイルの内容は、コンポーネントの内部にのみ適用されるよう、Angularが処理します。

この方法でアプリケーションを実装すれば、CSSの特徴である、書いたセレクタがグローバルに適用されてしまうという事態を避けることができるため、意図せず他の箇所にスタイルが適用されてしまうということがなくなります。

ECSSとこれらフレームワークには直接的な関わりはありませんが、このようなフレームワークが用意している、ローカルにのみCSSを効かせるという実装を利用することで、分離による保守性の向上というメリットを得ることができます。これは、ECSSの設計思想と非常に似た考えと言えます。ECSSはモジュールごとの分離を命名規則で実現し、これらフレームワークはその用意したフレームワークの機能の中で実現します。

このようなコンポーネント指向のフレームワークを用いてアプリケーションを設計する際、ECSSを理解することは、そのCSS設計のための助けとなるかもしれません。

制作チームが別れている運用体制

筆者Takazudoは、ECSSの考え方を、制作チームが別れている運用体制にて活かすことができたという話を聞きました。

私にその話を聞かせてくれた方は、一つのサイトを複数のチームで運用する際、どこまでを共通化して考えればよいのか、汎用的なモジュールをどう考えれば良いのかということについて悩んでいたようです。制作チームが別れていると、密に連携が取れるわけではないので、汎用的に作った細かいモジュールを、各チームで共有するのが難しいということでした。

その方は、そのような環境を改善するため、ECSSの考えを取り入れました。ヘッダとフッタのみを共通のモジュールとし、それ以外の箇所については、サイト上のカテゴリのまとまりごとに完全に分離してしまうことにしたそうです。具体的には、各々の管理範囲へ個別の名前空間を与え、CSSを書く際は、クラス名の頭にその名前空間の接頭辞をつけることをルールとし、そのクラスセレクタで基本的にCSSを書くことで、競合を避けました。

また、アセットも管理範囲毎に分離し、お互いが干渉しないようにしたそうです。その結果、チームごとに触るべきファイルが明確になり、お互いの衝突を減らすことに成功したとのことでした。

これは端的に言うと、モジュールの汎用化を諦めてしまったということですが、制作の体制によってはそのような解決策がベストになることもあるかと考えさせられた話でした。CSS設計の理想とはかけ離れていると感じる方もおられるかもしれませんが、このような諦めは、実際の仕事の中では有効な解決方法となることも多いのではないでしょうか。

汎用モジュールをベースとした設計

前項で挙げた事例のような、完全にチームが別れるなどしない場合でも、ECSSの「分離する」考え方は応用できるものと筆者は考えます。というより、Webサイトをモジュールベースで考えて設計していた場合、はじめは分けて考える必要がなかろうとも、運用していたら分ける必要が出てくるというケースは往々に発生するであろうから、基本的にECSSの「分ける」設計をベースにしておいたほうが、後々の保守性の向上の助けになるであろうと感じています。

筆者は以前、コーポレートサイトをワンストップで制作することの多い制作会社にて、フロントの実装を行っていました。その会社では、コンサルから設計、デザイン、コーディング、CMS組み込みまで全てやっているという制作体制を基本としていたことと、主に制作していたのがコーポレートサイトという、汎用的なUIパーツで大量のページを作る必要があるという状況があり、これを効率的にこなすため、どの制作工程においても汎用化されたモジュールでページを構成するという意識を共有することに、それなりに成功していました。

そのような制作体制の中、HTMLとCSSでテンプレートを作っていたのが筆者だったのですが、そのようにモジュール化を強く意識していた現場であったからこそ、汎用化されたモジュールが多くなりすぎてしまうという問題に頭を悩ますことが多くありました。

具体的には、トップページでしか使わないようなメインビジュアル、一部のキャンペーンページでしか使わない特殊なモジュールなど、おおよそ他のページで使わる可能性がないようなものであっても、汎用的なモジュールとして考えてCSSの設計を行ってしまっていました。

いや、むしろそのように「汎用的である」とか「そこでしか使わない局所的なものである」などという考えの元にCSSを設計していませんでした。BEMでいうBlockの集合でWebサイトを作っていましたが、ただそれだけで、とにかくなんでも使いまわせることを念頭に置いて設計を行っていました。

そのように、局所的にしか使わないモジュールを、汎用的なモジュールであると考えて設計してしまったことで、なにかCSSの容量が増えすぎてしまい問題になるというようなことは起こりませんでしたが、今考えればそれは、サイト全体で使う汎用的なモジュールらと、局所的に使うモジュールで分けて設計すべきでした。

例えば、汎用的なモジュールはsw-（SiteWide）、トップページだけで使うモジュールはtop-（Top）、キャンペーンページだけで使うモジュールはcamp-（Campaign）と名前空間を分けるなど。そのようにしておけば、前回までで紹介したように、トップページのみのリニューアルや、キャンペーンページの更新や削除にも対応しやすくなります。

そのように名前空間によりモジュールを分けるのは、一段階、モジュールのカテゴライズを設計する必要があることに注意する必要があります。ですが、基本的に汎用的なモジュールで構成されるようなWebサイトを作る場合でも、このようにECSSの考え方を適用しておくことは、将来の保守性向上へ貢献するのではなかろうかと筆者は考えます。

CSS設計のヒントはデザインカンプの外側にあり

そのように考えていると、もはやCSSの設計について考えることは、デザインカンプを眺めながらHTMLとCSSを書いているだけでは、ベストなゴールへ到達できない問題であるということに気付かされます。前項で上げたようにモジュールのカテゴライズを考えるということは、つまるところ、Webサイトを構成するモジュールをどのように考えるのかというところに辿り着き、画面の設計をどう考えるという設計に習う必要が出てきます。

また、どのようにモジュールを切るかという点について考えた時、HTMLとCSSを書いた後の工程へ目を向けることも重要かもしれません。例えばブログシステムに組み込むためのHTMLテンプレートを書く場合、そのブログシステムが、「ヘッダ」「フッタ」を、システム的にテンプレートを分離していて、それらのファイルをインクルードするような作りになっていたとしたら、HTMLとCSSでも「ヘッダ」「フッタ」を個別のモジュールとして用意することで、ブログのテンプレート組み込みとのモジュール感を一致させることができるでしょう。

プログラミングにおいて、同種の処理は共通化し、DRYを意識するのが、良い設計を行うための考え方の一つとして重要であることはよく知られているところです。OOCSSはそのような考えに習った設計思想でした。しかし、HTMLとCSSはプログラミング言語ではないことに注意しなければなりません。SassなどのCSSプリプロセッサやPostCSSの力を借りれば近いことができますが、行き過ぎた抽象化が保守のコストを高めてしまう可能性があるのでは？と、ECSSは考えさせてくれます。保守性を見越し、行き過ぎた複雑さを排除した、適切なモジュールの分離を目指すのがECSSです。

ECSSを取り入れるべきか否かは、プロジェクトの性質によって左右されるであろうと筆者は考えます。Webサイトは作って終わりではありません。サイトローンチ後も継続して変化しうるHTMLとCSSについての保守を考える場合、ECSS的な視点も考慮しつつCSSの設計を考えてみてはいかがでしょうか。

前回までで、Enduring CSS（以降ECSS）の基本的な設計指針や、命名規則などのルールを紹介しました。ECSSの後半は、著者Ben Frain氏の考える、設計が破綻しないためのCSSの書き方が、Tipsの集合のような形でまとめられています。

ECSSは「分けて」考えることで、サイトが破綻しないようにすることに重きを置いた考え方です。なので、あらゆるサイトにとって最適な解となるわけではなく、自身の目的に合った設計を選ぶべきであると著にはあります。100%この内容にならう必要はありませんので、参考になりそうなノウハウをピックアップし、自身のプロジェクトに活かすとよいのではないでしょうか。

とはいっても、サイト全体で共通のModuleというのはあるでしょう？

前回までの内容からすると、ECSSでは「ヘッダ」「フッタ」のようなサイト全体の共通のUIを除いては、すべて名前空間でカッチリ分け、「汎用的に使われるコラム」だったり、「ナビゲーションのリスト」みたいなものも、各々の名前空間に属する、個別のModuleとして扱うべきであると言うふうに思われるのではないでしょうか。

例えば以下は、Bootstrapで用意されているPanel（左）、List Group（右）というコンポーネントです。このような見栄えのUIが何度もサイトの中で登場するのだとしても、個別のModuleとして定義しておくべきなのでしょうか。

ECSS的には、その答えはYESです。別の機能の中で登場するのであれば、別のModuleとしたほうが良いと考えます。しかし、ECSSはそのような汎用的なModuleの存在を完全に禁止しているわけではありません。例えば、サイト全体で汎用的に使われるModuleを用意したければ、sw（SiteWide）という名前空間に属させてはどうかと書かれています。この場合であれば、sw-Panel、sw-ListGroupというModuleにするという具合です。

しかしながら、このように汎用的にどこでも使えるModuleを増やしすぎないようにしたほうが良いとECSSは警告しています。理由は簡単で、そのように汎用的なModuleを増やしていけば、それはどこでも使われる可能性があるゆえに、二度と消せないModuleとなってしまうからです。

前回挙げたトップページだけをリニューアルするような例を考えてみると、その意味が分かるのではないでしょうか。トップページに登場するModule群が、汎用的にどこでも使われているもので構成されていたとしたら、前回紹介したように、もう使わなくなったModuleを消すということがやりづらくなります。

ECSSは、そのように汎用的なModuleでサイトを構成することを否定しているわけではありません。ただ、そのようにModuleの汎用化を進めていくとECSSの目指している、分けて管理するという設計からは外れていくということです。

このように、汎用的に使用できるModuleを用意することは、Module構成の複雑化とのトレードオフであると考えることができます。かたくなに汎用的なModuleを禁止する必要は無いかと思いますが、ECSS的な設計を取り入れたいのであれば、汎用的なModuleが増えすぎないように注意する必要があるでしょう。

ビルドによるCSS結合の必要性

前回、ECSSはアセットを名前空間ごとに分けると書きましたが、そのように分けたCSSやJavaScriptのファイルを、1つずつ読み込ませるのが良いと考えているわけではありません。gulp、PostCSS、Sass等を使い、必要に応じてCSSをまとめることを推奨しています。

このあたり、どうCSSをまとめるかという設計が必要と考えても良さそうです。そこまで細かく設計する必要は無いと感じるのであれば、全NamespaceのCSSを一つにまとめてしまうのでもいいと思いますが、テンプレートごとに必要なCSSは何かを把握し、どうまとめるかという設計を挟むことで、ユーザーに不必要なCSSを読み込ませないようにすることが可能になるでしょう。

筆者Takazudoは、ECSS著者のBen Frain氏に、どのようにCSSをまとめたらいいのかと聞いてみたことがあるのですが、それは自分の必要に応じて柔軟に決めれば良いとアドバイスを貰いました。

SPAなど、全てのCSSルールが1ページの上で必要な場合は、あえてCSSファイルを分ける必要がないので全部CSSファイルを一つにまとめたり、例えばキャンペーンサイトのような、そこでしか使われないという具合にNamespaceが明確に切り分けられるのであれば、それらだけを別のCSSファイルとしてまとめたりするなど、様々なまとめ方が考えられます。

PostCSSやSassとの付き合い方

ECSSでは、開発の効率化のため、PostCSSやSassなどの、CSSを書くのを手助けするツールの使用を推奨しています。ECSS書籍内で紹介されている機能の一部を紹介します。

autoprefixer

まず、ぜひ使うべきと紹介しているのが、autoprefixerです。このautoprefixer、使ったことのある人であれば分かると思いますが、autoprefixerが自動で必要なvendor prefixを足してくれるため、vendor prefixを自分で書く必要がなくなります。vendor prefixを自分で書かないといけないような状況は、コードの複雑さを高めます。この複雑さを自動で排除できるautoprefixerは、コードの保守性を高めるのに寄与するものとECSSは考えています。

変数

ほか、PostCSSやSassで利用できる、変数、mixinの機能も利用すべきであるとECSSは考えています。変数やmixinを使ってしまうと、「分けて」管理することがしづらくなくなるのではないか？と思われるかもしれませんが、まさにその通りで、利用用途に注意して、控えめに使うべきであるとECSSでは述べられています。

例えば変数ですが、ECSSでは、サイズ、色、z-indexのために使用することをオススメしています。サイズ、色を変数化しておくのは、デザインやコードの統一性を確保するためです。

既存のコードを眺める際、widthが50pxと書かれている場合と$size-doubleと書かれている場合では、コードを読む者の捉え方は異なります。前者の場合は50px以上のなんの情報も得られませんが、後者の場合、基準のサイズが25pxであり、その長さを基準にしてデザインが行われているということが想像できます。

デザインの矛盾や意図しない値の差異を発生させないため、このようなマジックナンバーは、なるべく変数化しておき、数値の指定を行うときにはこれら変数を利用するとよかろうとECSSには書かれています。

mixinとextend

mixinは控えめに使うべきであると、ECSSは考えています。控えめというのはどういうことかというと、Moduleの抽象化をするために使うべきではないということのようです。

例えばOOCSSでは、共通部分のスタイルをベースのObjectにまとめ、そこに差分のスタイルを当てたクラスをSkinとして適用することで、似た見栄えのUI表現を実現するという旨を、連載第1回で紹介しました。このようなOOCSSの設計思想を、OOCSS自身はマルチクラスを利用して実現しますが、mixinやextendを使えばスタイルの抽象化をCSS内で済ませられるため、よりスマートにModuleの抽象化が実現できると言うことができるでしょう。

しかしECSSでは、このようなmixim、extendの利用を禁止します。理由は簡単、Moduleが複雑になるからです。このmixinやextendも、汎用的なModuleを作るのと同じ問題をはらんでいます。そのような抽象化をmixinやextendで行うと、作ったmixin、extendが様々なModuleの中で使われるわけです。そうなってしまったら、そのmixin、extendをいじった場合、どこかで意図しない崩れが発生するかもしれませんから、作ったmixin、extendの内容は2度と編集することができず、「分けて」管理するというポリシーからは外れてしまいます。

もっと言えば、そんな風に最初は抽象化できたように見えても、サイトが成長していけばより色々なバリエーションのUIが登場するため、そのような抽象化を完全に行うことはそもそも無理であろうとさえECSSは考えています。（ECSSはって言うより、著者Ben Frain氏がという感じですね）

ではどのようにmixinを使うのか。その例として、ECSSではフォントに関する指定を例に挙げています。特定のfont-family、font-size、font-weight、line-heightの組み合わせを色々なところに使いたいと考えるのであれば、それは単純に変数で表せるものではないから、mixinとしてまとめ、使いまわすといいだろうと、ECSS書籍内では紹介されています。

このような、あくまで簡単なスニペット的なmixinの使い方に限定し、究極的には10個以内のmixinに収めておくのが良いだろうとECSSは考えているようです。

複雑な書き方は避けるべし

このように、ECSSは、CSSを書くことを手助けするツールの使用を推奨しているものの、そこに多くの機能を求めません。むしろ、なにか込み入った機能を持ち込む場合、その学習コストを考慮し、プロジェクトに適しているのかを判断すべしとECSSには書かれています。複雑さは運用の負荷を高めます。その結果、CSSを編集することに対してかかるコストが上がってしまうということです。

ほかにもECSSは、複雑なCSSの書き方も避けるべきであるとアドバイスしています。その例としてFlexboxを例に挙げています。Flexboxを使えば、少ない数の要素で柔軟にレイアウトを組むことができるわけですが、もし開発メンバーがあまりFlexboxに慣れていないような状況であったなら、Flexboxを積極的に使用することで得られるメリットと、Flexboxを理解するための時間を天秤にかえて考えてみる必要があるであろうと警告しています。

CSSを書いていると、新しい技術仕様をどんどん使うのがクールなコードであるように思えることはないでしょうか。筆者Takazudoは結構、そのように考えていたところがありました。対応環境の許す限り、なるべく最新の仕様をどんどん使いたいなと、まぁ技術者だとそういう欲望はある程度あるのではなかろうかと個人的には思うわけですが、それであとから見た時に読解に時間がかかりすぎてしまうようでは本末転倒です。なにを重要とするのかを考えろということです。

これってCSSだけではなく、プログラミング全般に言えることだとも思うのですがどうでしょうか。

※ Enduring CSSが書かれた時期からするとFlexboxはだいぶ普通に使われるようになってきたかと思いますので、そこまで警戒すべきものではないかとは思いますが、重要なのは、開発メンバーがその技術に慣れているか否かという点です。

今回は、ECSS書籍内より、実装のヒントとなりそうなトピックのうちのいくつかを紹介しました。ECSSには、他にもたくさんの実装のヒントがありますので、ご興味が有る方は是非、ECSSのサイトをチェックしてみるといいかと思います。

次回は、ECSSをどのように利用していったらよいか。実際に書いてみて気をつけたほうがよさそうなことを筆者なりにまとめて、締めとしたいと思います。

本連載では、Enduring CSS（ECSS）というCSS設計方法論を紹介しています。

• Architect CSS and scale CSS with the ECSS CSS methodology

前回は、ECSSの考え方の特徴と、Module、及びその内容について見てきました。今回は、Namespace（名前空間）とアセットの分離について解説します。

Namespace（名前空間）

ECSSの大きな特徴の一つに、Module群をNamespace（名前空間）でまとめるという点があります。前回解説したクラスの命名規則だったり、実際のWebサイト上で使われているクラス名には、名前空間を示す接頭辞がついていました。

以下に、前回登場したクラス名の一部を列挙します。括弧内の文字列が、Namespaceです。（各モジュールがどういうものかは、第一回目の終わりに紹介したECSSサイトのトップページのモジュール一覧をご覧ください）

• home-Benefits（home）: ECSSの利点をまとめているモジュール
• home-Testimonials（home）: ECSSの推薦コメントをまとめているモジュール
• st-Nav（st）: ヘッダ部にあるナビゲーションのモジュール
• st-Footer（st）: フッタのモジュール
• hero-Standard（hero）: ヒーローエリアのモジュール

上記であれば、home-Benefitsとhome-Testimonialsはhomeに、st-Navとst-Footerはstに、 hero-Standardはheroに属するという具合です。

なお、ECSSには、クラス名上でのNamespaceは、単語の頭文字らをとったりして略称にすると良かろうと書かれています。書籍の内容によれば、ここで登場しているstというのは、Structureを意味し、ヘッダやフッタなど、サイト共通の基本構造的なModuleを属させているようです。

セレクタの競合を回避するNamespace

このように、Moduleを必ずNamespaceに属させる意味としてはまず、セレクタの重複を避けるという点が大きくあります。

どのようなCSS設計方法論を用いていたとしても、ECSSでいうModuleの名前をどうするかという点に頭を悩ませることが多いのではないでしょうか。筆者は数多くのWebサイトをコーディングしてきましたが、この名前付け作業にはいつも多くの時間をかけていました。今後どこかで使われることを見越し、どういった名前にしようかなどと考えると、最適な名前はなんだろうかと悩むのです。

ECSSは、Moduleを必ずNamespaceに属させるというルールにしています。そして、前回解説したように、Moduleのクラス命名規則が

namespace-Module

であり、Module内の要素にスタイルを当てたい場合は、その要素をChildNodeとし、

namespace-Module_ChildNode

とクラス名を付け、そのクラスセレクタでスタイルを当てるルールになっています。なので、Moduleの名前をそのNamespace内で重複しないようにさえしておけば、別のModuleのセレクタと競合することがありません。

例えば、前回例に出したBenefitsというModuleは、Namespace homeに属します（home-Benefits）。homeというのは、このサイトを眺める限り、トップページで使うModuleらをまとめるために使用されているように見受けられます。とすれば、トップページの中で重複しないModule名であればそれで良いのです。

どこかでBenefitsという名前のModuleが登場したとしても、それは別のNamespaceでの話です。hoge-Benefitsなどという、別のNamespaceを示す接頭辞から始まるクラスセレクタでスタイルが当てられるでしょうから、セレクタの競合を恐れる必要はありません。

もちろん、このように深く考えないで良いという前提としては、前回解説したように、例え似たようなModuleがどこか別のところ（この場合ですとトップページ以外）で登場しても、そのためには別のセレクタを書き、別にスタイルを当てるという、CSSの重複を許す諦めがあってのことです。

Namespaceの切り方

では、具体的にどういう風にNamespaceを用意したら良いのでしょう。ECSSでは、Namespaceの切り方として、ショッピングカートを例に挙げています。ショッピングカートの仕組みを作るのであれば、scという、ShoppingCartを略したNamespaceを用意し、そこで使われるModule群をscに属させるようにするという具合です。

この例を、もうちょっと発展させて考えてみます。

• トップページ
• 商品詳細
• ショッピングカート

という3つのテンプレートで構成されるサイトがあったと仮定します。この場合、例えばこんな風にNamespaceを分けてしまうのはどうでしょう。

トップページで登場するModuleは全てtp（topPage）に、商品詳細で登場するModuleは全てpd（productDetail）に、ショッピングカートで登場するModuleは全てsc（ShoppingCart）に属させるという具合です。

しかし、大抵の場合、ヘッダやフッタはサイト全体で共通のものになっていることでしょう。ほかにも、サイドナビにある広告エリアがどのページでも共通であるような状況を想像してみてください。そんな時は、共通Moduleをまとめるcmn（common）というNamespaceを用意してみてはどうでしょう。

cmnに、ヘッダやフッタ、サイドエリアの広告エリアを属させるのです。

例えばこんなModule名で。

• cmn-Header（ヘッダ）
• cmn-Footer（フッタ）
• cmn-SideAd（サイド広告）

これは、あくまでテンプレートの種類でNamespaceを切るというひとつの例にすぎませんので、当然、必ずテンプレートごとにNamespaceを用意せよというわけではありません。Namespaceの切り方は設計者次第であり、自由です。

このようにECSSでは、Namespaceを切ることで、セレクタの重複を防ぎます。Namespaceをどう切るかという設計は必要になりますが、Moduleの名前を考えるのは、かなり気軽になるのではないでしょうか。

アセットの分離

ECSSでは、Namespaceごとに、そのNamespaceに属するModule内で使用するCSS、JS、SVG、画像等のリソースを分離してしまうのが良いと考えています。本連載では、便宜上、これらのリソースのことを「アセット」と呼ぶことにします。

普段Webサイトを作る時、例えば以下のようにCSSやJSファイルを一つにまとめて管理したり、

/src
├── css
│   └── styles.css
└── js
    └── app.js

機能やModuleごとにCSSやJSファイルを作り、アセットの種類ごとにディレクトリを作り、ファイルをまとめたりしていませんでしょうか。

/src
├── css
│   ├── ProductDetail.css
│   ├── ShoppingCart.css
│   └── TopPage.css
└── js
    ├── ProductDetail.js
    ├── ShoppingCart.js
    └── TopPage.js

ECSSでは、ファイルタイプ別ではなく、Namespace別にアセットを管理します。前例の

• トップページ – TopPage
• 商品詳細 – ProductDetail
• ショッピングカート – ShoppingCart

だと例えば、以下のような形になるかもしれません。

/src
├── ProductDetail
│  ├── ProductDetail.css
│  └── ProductDetail.js
├── ShoppingCart
│  ├── ShoppingCart.css
│  └── ShoppingCart.js
└── TopPage
    ├── TopPage.css
    └── TopPage.js

各Namespaceのディレクトリ配下は、もっと好きなように便利に管理して良いのですが、重要なのは、Namesapce毎にアセットを分けて管理するという所です。

ECSSでは、このように分けたアセットらを、必要に応じてビルドしてまとめたりして使うよう、想定しています。

アセットの分離がもたらすメリット

Namespace毎にアセット分けられていると何が嬉しいのでしょうか。先述した、Namespaceの切り方として挙げた例をベースに考えてみます。

探しやすさ

アセット分離のメリットとしてはまず、どこにアセットがあるのか探しやすいという点が挙げられます。

例えばトップページの、以下のヒーローエリアへ配置されたtp-HeroImageというModuleの、CSS／JS／画像を探したいとします。

この場合、Namespaceごとにアセットが管理されていたとすると、このModuleに関するアセットは、トップページのアセットがまとめられているディレクトリ内にあるはずです。トップページのアセットを、/topPage（tp）に置いていたとしたら、このModuleのアセットもその中にあることが分かります。また、新しく画像やJSを追加したい場合でも、このディレクトリの中に置けばよいということも分かります。

捨てやすさ

見つけやすいという点は重要ですが、何にも増して重要なのは、使わなくなったアセットを捨てられるという点です。

CSSを書いていると、一度書いてしまったルールセットは二度と消せないと感じないでしょうか。自分一人で書いていたならまだしも、複数の人間がひとつのWebサイトのCSSを編集していたら、自分が書いていないルールセットを編集したり、消したりするのには細心の注意が必要です。ECSSの「アセットの分離」というアプローチは、これを解決する一つの方法です。

例えば、トップページのデザインをリニューアルしたいと仮定します。

この場合、それまでトップページで使っていたModule群はもう不要となるでしょうから、当然、そのModule内で使用していた画像なども不要になります。

このような場合、トップページ上のModule群をNamespace tp（topPage）に属させていたとして、そのアセットを/topPageに配置していたとすれば、もう過去のトップページのアセットは不要であると判断される場合、この/topPageディレクトリごと消してしまえばよいのです。

そしてリニューアルされたバージョンのトップページで使うModule群は、Namespace tp2（topPage2）に属させることにします。そして、そのアセットを/topPage2に配置することにしましょう。

結果として、リニューアル前のトップページで使用されていたCSSや画像などは、どこにも残りません。

もし、トップページで使っているModule群が、他のページでも使えるよう、汎用的なModuleとして作られていたとしたら、このように、簡単に消すことはできないはずです。そのように汎用的に作ってしまったModuleは、永遠にWebサイトのCSSの中に残り続ける運命にあります。

また、前回解説した、「抽象化を避ける」という点についても思い出してみてください。もしOOCSSで言うレゴのように、細かな汎用的なModuleが沢山トップページで使用されていた場合、このように古いModuleを簡単に消すことができるでしょうか。きっと、使われていないModuleを一つ一つ吟味し、慎重に消すことになるでしょう。

何を重要とするかはプロジェクトにより異なるでしょうが、ECSSは、このようにNamespace毎にアセットを分離することで、運用にシンプルさをもたらし、永続的にCSSを運用していく事ができるようになると考えます。

今回は、名前空間とアセットの分離について解説しました。次回は、ここまでで紹介していないトピックのうち、いくつかを選んで紹介します。

本連載では、Enduring CSSというCSS設計方法論を紹介します。Enduring CSSは、Ben Frain氏の著書で、末永く破綻させずにサイトのCSSを設計するにはどうすればよいか。その方法論をまとめたものです。電子書籍でも販売していますが、Webサイトで全ての内容が公開されていますので、無料で全内容を確認可能です。

• Enduring CSS by Ben Frain [Leanpub PDF/iPad/Kindle]
• Architect CSS and scale CSS with the ECSS CSS methodology

CSS設計方法論（CSS methodology）と言うと、OOCSS、BEM、SMACSSの3つが著名なものと言えるのではないでしょうか。

• An Introduction To Object Oriented CSS (OOCSS) – Smashing Magazine
• BEM — Block Element Modifier
• Ja – Scalable and Modular Architecture for CSS

特にBEMは、フロントエンド界隈でクラスの命名規則のデファクトスタンダードになったとも言ってしまっていい気がします。このEnduring CSS（以降ECSS）は、これらのCSS設計方法論と比較すると、知名度は低く、事細かにドキュメントが用意されているわけではありません。

しかしながら、ECSSの内容は筆者Takazudoにとって目からウロコであり、CSS設計に対する考え方をかなり改めさせられることとなりました。ECSSは、そこまでカッチリとしたルールではありません。サイトを長生きさせるにはどうすればいいかというヒント集のようなものと思って読むとよいと思います。

そんなEnduring CSSというCSS設計方法論を、ざっくりと紹介していきます。

ECSSの特徴

多くのCSS設計方法論では、ページを構成するUIをモジュールなどと呼ばれる単位に分け、管理するところから始めます。ECSSでもその考え方は同じです。この「モジュール」は、BlockだとかObjectだとかComponentだとか、いろいろな呼ばれ方をしますが、ECSSではこれをModuleと呼びます。

ECSSは、Module及びそのModuleの中身がどう構成されるかという考え方について、BEMを参考にしています。そこにNamespace（名前空間）や、Componentという概念を付け足したのがECSSの考え方になります。

抽象化を避けるECSS

ECSSでは、抽象化を避け、なるべく「分けて」管理することで運用の負荷を下げるというアプローチを取ります。

例えばOOCSSでは、ページを構成するUIをレゴの組み合わせで構成すると例えています。複雑なUIも単純なレゴをうまく組み合わせで構成し、新しいページを作る場合でも、既存のObjectで使えそうなものがあったらその組み合わせで構成し、足りないものは新しく作るという、HTMLとCSSの再利用を推し進めた考え方です。その結果、CSSを書く量が減るため、CSSの容量を減らすことができると。

そして、一つ一つのレゴをObjectと呼び、このObjectの変化のパターンをバリエーションをSkinという概念で表現し、オブジェクト思考における継承の考えを取り込んだ、かなりCSS的にミニマムな設計を指向しています。UIパーツをObjectで抽象化して考えるという具合です。

ECSSは、OOCSSのこのアプローチとは真逆と言ってよい考え方をします。ページを構成するUIパーツをモジュール化して管理するという点については同様ですが、多くの機能で汎用的に使用するModuleの存在をあまり良しとしません。同じような見栄えのUIパーツが登場したとしても、基本的にそれは別のものであると定義します。

そう聞くと疑問に思うことでしょう。その考えでコードを書いていったら、おなじCSSを何度もコピペすることになってしまうのでは？と。

CSSの重複を許すECSS

ECSSはそのようにCSSを重複して書くことを良しとします。

そのように考える大きな目的は、複雑化の回避です。幾つものObjectが組み合わされ、Skinでそれぞれが拡張された状態のコード。これを編集するのは、時に大変な作業になりえます。何が大変かというと、他所での影響を考慮しなければならないからです。

既に書いてあるCSSのルールセットを変更した場合、他のどこかで問題が発生しないと言い切れるでしょうか。小さなサイトであればそれは可能でしょう。しかし、複数のデベロッパーがコードをいじるような環境では、それを制御するのは困難を極めます。

そのように複雑な構造を一度作ってしまったら、ゆくゆくはコードを編集することが不可能になる。そしてCSSは破綻する。CSS容量を増やしてしまったとしても、「分ける」ことにより、これを避けるメリットのほうが遥かに大きいと考えるのがECSSです。CSSの容量増加は、gzipすれば大した差にはならないとECSSは考えています。

これは筆者Takazudoのイメージですが、OOCSSが目指すのが一つの高い塔であれば、ECSSが目指しているのはビル街です。

ECSSには、自身が大きなWebアプリケーションのCSS設計のため、合理的なアプローチが必要で考えたものであると書かれています。また、どのようなサイトにも適した考え方であると言うわけではないということも書かれています。このことは予め理解しておく必要があります。

ECSSにおけるModule内の構成

まずはECSSにおいて、Module及びその内容をどのように考えているのかを紹介します。基本的な考え方はBEMと同じなので、以下、BEMと比較する形で説明します。

例えば、こんなタブUIの構造を例に考えてみます。

BEMにおいて、このUIのタブ部分をBlockであると定義すると、

タブUI全体がBEMにおいてのBlock。これはECSSではModuleと呼びます。

そして例えば、一つ一つのタブがBEMにおいてのElement。これはECSSではChildNodeと呼びます。

状態により変化するようなパーツは、BEMではModifierというフラグを付加することで表現します。これをECSSではvariantと呼びます。

このあたりは、BEMを理解しているのであれば、呼び方が変わっているぐらいの差に過ぎません。

BEMのクラス命名規則

BEMでは、このように考えた上で、各要素に命名規則に沿ったクラスを付加し、単純なクラスセレクタでルールセットを書いていきますが、これについてもECSSは同様です。

BEMにおけるクラスの命名規則は以下です。

block__element--modifier

例えばこのタブUIのコードだと、以下のようになるかもしれません。

<ul class="tab">
  <li class="tab__item"><button>One</button></li>
  <li class="tab__item tab__item--active"><button>Two</button></li>
  <li class="tab__item"><button>Three</button></li>
  <li class="tab__item"><button>Four</button></li>
</ul>

ECSSのクラス命名規則

これに対し、ECSSにおけるクラスの命名規則は以下です。

namespace-Module_ChildNode-variant

namespaceというのは名前空間を意味しますが、これは追って解説します。他はBEMの名前が置き換わったぐらいと考えておいてよいです。

<ul class="tp-Tab">
  <li class="tp-Tab_Item"><button>One</button></li>
  <li class="tp-Tab_Item tp-Tab_Item-active"><button>Two</button></li>
  <li class="tp-Tab_Item"><button>Three</button></li>
  <li class="tp-Tab_Item"><button>Four</button></li>
</ul>

ECSS著者はBEMの区切り文字が好みではないらしく、アンダースコアとハイフンで区切りを表現します。

ほか、ModuleとChildNodeはアッパーキャメルケースで記述します。これは、多くのプログラミング言語で、クラスの宣言は大文字からはじめ、そこからインスタンスを作成することになぞらえ、HTMLにおけるこのクラス属性に指定するこの文字列は、具体的なUIを表現するための雛形であるという考えのもと、アッパーキャメルケースで記述することにしたそうです。 （筆者Takazudo的にはけっこうナルホドと思いました）

Component

ECSSでは、Module内で登場するある程度の大きさを持ったUIの塊を、Componentとして定義することにしています。

例えば、ヘッダーのModule内でプルダウンメニューが登場したら、そのプルダウンをComponentとして扱うというような具合です。その場合は、上記クラス命名規則は以下ように、ModuleがComponent名に置き換わった形になります。

namespace-Component_ChildNode-variant

どのようにComponentとしてまとめるかは各々が判断して設計する部分で、明確な切り分け基準があるわけはありません。Componentは、Moduleの大きさが大きくなった場合、コードの可読性やJavaScriptとして操作するまとまりの区切りをつけるために用意されるものと考えておいて良さそうです。

Moduleの粒度

ECSSには、Moduleは以下であると書かれています。

a module is the widest, visually identifiable, individual section of functionality.

「Moduleは、視覚的に認識できる個別の機能領域のもっとも大きな区分である」とでも訳せばよいのでしょうか。この定義からは、あまり小さい単位のUIをModuleであると定義しないような印象を受けます。

具体的なModuleの例

具体的にはどうModuleを考えればよいのか。丁度ECSSのWebサイト自体がECSSで書かれているので、そのクラス名から、Moduleの粒度がどのようなものかを見てみました。

※2017年1月時点でのWebサイトのコードを参照しています

ページの中ほどにある、ECSSの利点を述べたBenefitsというModuleです。

このようなUIをHTMLとCSSで作る場合、例えばBEMであればどのようにBlockとElementを構成するでしょうか。

明確な決まりは当然ありませんが、例えば上部にある見出し部分、アイコン一つ一つ、アイコン直下にあるラベルなどを個別のBlockとして切り出し、Blockの入れ子により構成されると考えることもできます。

他でもそのBlockが使えそうだなと、そのように細かくBlock分けをしてもよさそうですが、実際のECSSのWebサイトでは、以下のようにクラス名が振られていました。

以下は、上記で青で囲んだhome-Benefits_Unitの内容です。

このクラス名から判断されることは、このBenefitsとういうModuleは、このModule内に別のModuleやComponentが含まれておらず、中にある要素はすべてChildNodeとして構成されていることです。このことから、このModule内の要素は、このModuleの外側では一切使われないことが分かります。

また、このModuleの名称がBenefitsという、具体的な機能を示すという点についてもECSSらしいと言えそうです。もしこのModuleが他でも使用されることを想定するのであれば、IconTextSetなどという、汎用性を持った名前にしたほうが、後々都合が良いのではないでしょうか。

しかし、BenefitsというModule名からは、このModuleが、ECSSのBenefitsを表すためだけに使用されることが想起されます。

トップページにあるその他のModule群

ECSSのWebサイトトップページにおいて、他のUI群は、どのようにModule分けされているのかを見てみました。以下がその図になります。

各Module中のクラスも確認してみましたが、Module内に別のModuleがあるという、入れ子状態になっているModuleはありませんでした。また、各Module名称は、かなり具体的な単語になっているのも分かるのではないでしょうか。

単に一つのページの構成を例として挙げたにすぎませんが、このように、ECSSでは、Moduleを細かく分け、Moduleの入れ子で構成するような作りを避けることで、そのModuleがそれ自身で完結するようなModule分けを基本として考えています。同じような見栄えのUIが出ても、そのModuleの担う機能が別であれば、それは別のものとして扱います。

今回は、ECSSの考え方の概要と、Moduleについて解説しました。次回は、Namespaceとアセットの分離について解説します。