POSTD PRODUCED BY NIJIBOX

POSTD PRODUCED BY NIJIBOX

ニジボックスが運営する
エンジニアに向けた
キュレーションメディア

本記事は、原著者の許諾のもとに翻訳・掲載しております。

CSS方法論を使って保全性を高める

CSSプリプロセッサ、CSSポストプロセッサのようなツールは、CSS開発のエクスペリエンス向上に向かって長い道のりを歩んでいます。しかし、これらのツールだけでは巨大なCSSコードベースの保守に伴う問題を解決するには足りません。対応策として、人々はCSSの記述方法に関する様々なガイドラインドキュメントを作成し始めました。一般にCSS方法論と呼ばれるものです。

特定のCSS方法論を詳しく知る前に、CSSの長期にわたる保守が困難な理由を理解することが重要です。問題の鍵はCSSが持つグローバル性、定義したスタイルは全てページのあらゆる部位にグローバルに適用される、という性質です。固有のクラス名を維持するために細かい命名規則を用意する、または 詳細度の規則 に抗い、あらゆる要素にどのスタイルを適用するかを決めるのがあなたの仕事になります。CSS方法論は、そのような面倒が大規模なコードベースで発生するのを避け、系統立ったCSSを記述できる手段を提供します。よく知られる方法論を大まかに時系列で見てみましょう。

OOCSS

OOCSS (オブジェクト指向CSS)は、2009年に最初に紹介された、2つの主要な原則に基づいて体系化した方法論です。1つ目の原則は 構造とスキンの分離 です。つまり、構造(レイアウトなど)を定義するCSSと、スキン(色、フォントなど)を定義するCSSを混合させないということです。この方法により、アプリケーションの「スキンの付け替え」がラクになります。2つ目の原則は コンテナとコンテンツの分離 です。要素を再利用可能なオブジェクトとみなします。オブジェクトはページ上のどこにあろうと同じに見えるものだ、という発想がその鍵です。

OOCSSは綿密なガイドラインではありますが、アプローチの細部においては規範としてあまり役立ちません。後述するSMACSSなどのアプローチはそのコンセプトの核心を引き継ぎつつ、実際に活用しやすい詳細が加えられています。

SMACSS

SMACSS (CSS向けスケーラブルモジュールアーキテクチャ)は2011年に紹介された方法論です。5つの明確なカテゴリ、 ベースルール、レイアウトルール、モジュールルール、状態(ステート)ルール、テーマルール を基盤にCSSを記述します。SMACSS方法論には推奨する命名規則もあります。レイアウトルールでは、クラス名に l-layout- などのプレフィックスを付けます。状態ルールでは、クラス名に is-hiddenis-collapsed といった状態を記述するプレフィックスを付けるのが良いとされます。

SMACSSは、OOCSSと比べてアプローチが詳しく説明されているのですが、それでも、どのカテゴリにどのCSS規則を当てるかという判断は慎重に行わねばなりません。次のアプローチ、BEMはその意思決定のプロセスを省き、さらに適用を容易にします。

BEM

BEM (ブロック、エレメント、モディファイア)は2010年に紹介された方法論で、ユーザインターフェースを独立した塊に分けるという発想に基づいて体系化されています。 ブロック は再利用可能なコンポーネント(一例は検索フォーム。 <form class="search-form"></form> で定義します)です。 エレメント はブロックにおけるより小さな部位で、単独で使い回しができます(一例は検索フォーム内のボタン。 <button class="search-form__button">Search</button> で定義する)。 モディファイア は、ブロックやエレメントの外観、状態、またはビヘイビアを定義する実態です(一例は無効状態の検索フォームボタン。 <button class="search-form__button search-form__button--disabled">Search</button> で定義します)。

BEM方法論は、具体的な命名規則によって初心者でも複雑な意思決定を経ずに適用でき、簡潔で理解しやすいのが特徴です。不便な点を挙げるとすれば、クラス名が非常に冗長な場合があること、 セマンティックなクラス名を記述する 従来の規則に沿っていないことです。

Atomic CSS

Atomic CSS (またはFunctional CSS)は2014年に紹介された方法論で、ビジュアルの機能に基づく名称を付けた、小さな単一目的のクラスを作るという発想で体系化されています。このアプローチはOOCSS、SMACSS、BEMとは正反対です。ページ上の要素を再利用可能なオブジェクトとして扱う代わりに、Atomic CSSはそれらのオブジェクトを全て無視し、使い回しのできる単一目的のユーティリティクラスを使って各要素にスタイルを当てます。つまり、例えば <button class="search-form__button">Search</button> としたいところは、 <button class="f6 br3 ph3 pv2 white bg-purple hover-bg-light-purple">Search</button> といった形式になるのです。

この例を見てまず怖気付いても、それはあなただけではありません。多くの人はこの方法論を、確立したCSSのベストプラクティスに対する完全な反則だとみなしました。しかし、様々なシナリオにおける従来のベストプラクティスの有効性に疑問を投げかける姿勢から、多くの優れた議論が生まれました。 この記事 は、従来の「関心の分離」がHTMLに依存するCSSを作り出すことになった経緯に焦点を当て、他方アトミック、あるいは機能性のアプローチはCSSに依存するHTMLを作り出すものだと述べています。どちらも誤りではありませんが、厳密に調べれば、CSS、HTML間の真の「関心の分離」がまず不可能なのは明白でしょう。

それ以外のCSS方法論、CSS in JSなどは、実際にCSSとHTMLは常に互いに依存関係にある、という概念を受け入れ、かつてないほど物議を醸す方法論になりました…。

CSS in JS

CSS in JS は、2014年に紹介された方法論で、CSSスタイルを分離するスタイルシートではなく、それぞれのコンポーネント自体に直接定義しようとする発想に基づいています。 React JavaScriptフレームワーク へのアプローチとして導入されました。(フレームワーク自体が既に賛否両論の方法を取っていました。コンポーネントのHTMLを、分離したHTMLファイルではなく直接JavaScriptに定義していたのです。)この方法論では元々はインラインスタイルを使っていましたが、後の実装ではJavaScriptを使ってCSSを生成し(コンポーネントに基づく固有のクラス名で)、それをスタイルタグでドキュメントに挿入するようになりました。

CSS in JS方法論もまた、「関心の分離」におけるCSSの確立したベストプラクティスに真っ向から反対するものでした。その理由は、Webの使われ方が時間の経過と共に劇的に変化したことにあります。元来、Webの大半は静的Webページが占めていたのです。そこでは、HTMLコンテンツとCSSの体裁の分離は非常に理にかなっていました。近年のWebは、動的Webアプリケーションの作成に使われています。すると、再利用可能なコンポーネントかどうかで分離するのが合理的です。

CSS in JS方法論の目標は、独自にカプセル化したHTML、CSS、JSで構成されるハードな境界でコンポーネントを定義できるようになることです。そうすれば1つのコンポーネントの中のCSSが他のコンポーネントに影響する余地はありません。Reactは、ハードな境界を持つコンポーネントを促進したフレームワークとしては最初に広く普及したものの1つで、その他のメジャーなフレームワーク、Angular、Ember、そしてVue.jsがそれに影響を受けて追随しました。ぜひ知っておくべきなのは、CSS in JS方法論が比較的新しいこと、そしてWebアプリケーション用コンポーネントの時代にあって、開発者たちが新たなCSSのベストプラクティスを確立しようと数多くの実験を進めていることです。

巷にあふれるCSS方法論につい圧倒されそうになりますが、アプローチに正解はないということを忘れてはいけません。ある程度複雑なCSSコードベースを目の前にした時に使える様々なツールとしてそれらを考えるべきです。熟慮した選択肢を持っていれば、必要に応じて活用できます。また、この分野で行われている最近のあらゆる実験は長い目で見れば全ての開発者に利益をもたらすはずです。

まとめ

以上がモダンCSSの簡単な概要です。取り上げたのは、文字属性を伴う 基本的なスタイル指定でのCSS利用 、フロート、フレックスボックス、グリッドベースのアプローチを伴う レイアウトでのCSS利用、CSSプリプロセッサによる変数やmixinなどの新しい構文の利用、CSSポストプロセッサによるベンダープレフィックス追加などの変換機能の利用、CSS方法論を使った保全性強化 、CSSスタイルのグローバルな性質の克服です。他にも掘り下げられなかったCSSの機能はたくさんあります。アドバンストセレクタ、トランジション、アニメーション、シェイプ、動的変数など、数え切れません。CSSが網羅する領域は非常に広いので、「簡単だ」などと言い出す人はおそらくその半分も把握していないのではないでしょうか。

モダンCSSは急速なペースで変化、進化をし続けているので、並大抵では使いこなせないのは当然でしょう。しかし、Webの進化のあり方を歴史的な文脈でとらえることが重要です。世間には頭の良い人が大勢いて、CSSのベストプラクティスをWebに沿って全うに進化させるツールや方法論を構築しようとしています。開発者としてはワクワクする時代です。この情報があなたの旅のロードマップとして役立てば嬉しいです。


注釈:「ハハッ!まあそれでもイケてる子たちは皆、CSSがキライだろ?」
「だから言っただろ、いいとこ取りはできないって!」
「…まあいい。でも僕がCSSの『知』を楽しむのを止めないでくれよな。だってCSSは本当にサイコーだから」

2003年(恐竜がWebを支配した時)以来、不条理ユーモアの傑作をいくつも生み出している
@ryanqnorthDinosaur Comics に重ねて感謝します。