前回までで、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をどのように利用していったらよいか。実際に書いてみて気をつけたほうがよさそうなことを筆者なりにまとめて、締めとしたいと思います。