こんにちは。コーディングファクトリー部（以下CF）の角南です。

ここ数年、OOCSSやBEM、SMACSSなどを筆頭に、様々なCSS設計が打ち立てられてきています。フロントエンドに関わる方々なら、一度はこれらのCSS設計論を聞いたり、実際にプロジェクトで使用した事があるのではないでしょうか？

また、ここ最近でもECSSやAPBCSSなど、次々と新しいCSS設計論がでてきています。

私自身、最近では新規プロジェクトにジョインされる度に、「次はどんなCSS設計にしようか…？新しい設計論を試すのか？それとも…』と悩む機会が増えてきています。
この辺りでCSSの知識のアップデートをする為に、2017年11月4日に行われた、CSS Nite LP54「Coder's High 2017」に参加してきました。
 

CSSNiteとは？

CSSNiteは、CSSのみならず、デザイナー向けのTipsや、時にはSEOをテーマにするなど、Web制作者全体を対象したセミナーイベントです。

今回、私が行ったCSS Nite LP54「Coder's High 2017」の内容は、主にコーディングをテーマに開催されました。

当日は、約300人の人が集まり、Twitterのハッシュタグ「#cssnite 」が、一時、twiiterのトレンド入りするぐらい、かなり盛況ぶりでした。
 

セッションについて

当日のタイムテーブルはこちら。

＊講演者の詳しいプロフィールなどはこちらでもご覧いただけます。

全体的に、ここ最近のHTML,CSS,JSコーディングの初学者〜中級者の方へ向けたイベント内容でしたが、最近のモダンブラウザで使用できるようになったdisplay:grid;のセッションなどもありました。

ICSの鹿野 壮さんのセッション

図や写真を使ってわかりやすく講演してくれました。

途中、休憩を挟みながらも、8セッションで6時間を超える長丁場でしたが、時に真面目に、時に面白く、講演者の方々に話をしていただきあっという間に時間が過ぎていきました。
 

印象に残ったセッション

今回のCSSNiteのトリを飾ったセッションで、
高津戸壮（たかつどたけし）さんによる「CSS設計方法論とその先」が、特に印象に残ったセッションだったので、ご紹介しておきます。

このセッションは、記事の冒頭でも触れた様に「CSS設計」に悩む私に、多くのヒントをくれるような内容でした。

まずセッションの冒頭で、どういった時に「CSS設計」が必要かという事に触れていました。
 

どういう状況で「CSS設計」が必要か?

• 50p以上制作するサイト
• 長期的に運用されるサイトやアプリケーション
• 複数の開発者が関わるサイトやアプリケーション

CSSは、ファイルさえ読み込んでしまえばそのページ全体に適用されてしまいます。
なにも考えずに書き続けていると…適用したつもりのないスタイルが、様々な箇所に適用されてしまい取り返しのつかない状況になってしまいます。
そういった事を避ける為、サイトやアプリケーションを制作する場面においてCSSの設計をする事が必要で、いくつかの方法が提示されていました。
 

トラブルを防ぐためのCSS設計の方法

• CSS設計方法論（OOCSSやBEMなど）を使う
• CSSプリプロセッサ、PostCSS等のツールを使用してのCSSの管理
• スタイルガイドやガイドラインでのコードルールの均一化

しかし、これらはあくまで、CSS設計の方法論を提示したものやツールの使い方を述べたものに過ぎません。
自身のプロジェクトでどうすればよいかを具体的に示してくれるものではなく、設計者が自身が考えなければいけないと言う事を述べていました。

例えば、似た様なUIのモジュールを作成する時に、汎用的に制作するか、局所的に制作するかを例にしてみます。
 

汎用的なモジュール

汎用化したモジュール：.cardのclass名をベースにmodifierで指定する

メリット

• モジュールの再利用前提
• CSSの容量を抑えられる
• 一括でのCSS変更が可能楽
   

デメリット

• 影響範囲が読めないので、後からCSSを編集しにくい
• マルチクラスなどで、バリエーションを表現する為、複雑化する恐れあり
  
   

局所的なモジュール

局所化したモジュール：違うclass名で別モジュールとして扱い、classをつける

メリット

• そこでしか使用しないので、複雑になりにくい
• 影響範囲が読みやすいので、後からCSSを編集しやすい
   

デメリット

• CSSのコードが重複する
• CSSの容量が増える
• 一括でCSSを変更しにくい
   

図の様なモジュールを作成する時に、ほぼ似たUIで少し違ったパーツなどがあると、コードを書く側だと、HTMLやCSSを出来るだけ共通化して汎用的にしたいと考えがちです。
（私の場合も、恐らくOOCSSやBEMをベースにしたモジュールの考え方や、classの命名でmodifierなどを用いて、汎用的に組もうとするでしょう。）

しかし、コーディングをする前の段階での仕様やデザインを考慮するとどうでしょうか？
もしかしたら、仕様やデザインの変更などで、汎用的なモジュールの組み方だとCSSが複雑化してしまい、結局、局所化しているのと変わらないという事になるかもしれません。

また、後行程などの運用や量産、CMSへの組み込み、SPA化などを考慮するとどうでしょうか？
もしかしたら、運用の人がmodifierを上手く扱えないかもしれませんし、そもそもOCSSSやBEMのルールで作成したものが、CMSなどに組み込めないかもしれません。

上記の様な事を考慮すると、最初から、汎用化＋局所化した方法でモジュールを制作していくのが、望ましい結果を得る事ができるかもしれません。

この様な事があり、高津戸壮さんの自身の経験から、講演の最後にCSSを書く上で大切なポイントをこう締めくくっていました。
 

CSS設計のポイント

• CSSを書く上での悩む原因は、コーディングの段階だと解決できない場合が多いが、CSSを書く上で問題として表面化してくる。それらは、CSSの設計論やツールだけだと解決できない事が多く、CSSの設計論やツールに助けを求めるのは間違い。
• ある程度の設計の不完全さを受け入れて、CSSの設計を行うことが多い事を念頭に置く。
• 解決したい問題に向けてCSSの設計を考える。
• 前行程、後行程を考慮＆連携してCSSの設計を考える。

他行程を巻き込んで設計を一緒にやる。単純にコードを書く以上の価値はそのあたりに存在する。

今後のCSS設計を考えていく上でとても参考になる話ばかりでした。

今まで、CSSはフロントの範囲で、なるべくなら完璧を目指していましたが、前行程と後行程も考慮した、ある程度不完全な所を受け入れるというCSS設計にするというのは、考えた事がありません。

すぐに実現していくのは難しいかもしれませんが、少しずつでもとりいれていけたらと思います。
 

最後に

「CSS設計方法論とその先」全体のセッションで一番印象に残った言葉を共有しておきます。

私自身、他行程のメンバーに共有する時に、CSSの設計論ばかり優先して共有していた気がします…反省。
これからは、経験を元にしたCSS設計を共有していきたいと思いました。

今回、初めてCSSNiteに参加してみましたが、学ぶ事が多く、非常に充実した１日でした。

また機会があれば、参加してみようと思います。