脱カオスなCSSのために実践している7つの事

突然ですが、CSSってカオスですよね。

まぁそうですよねー。紳士協定とはうまいこと言ったもんです。言語仕様としてどうしようもない。全部グローバル。JavaScriptとかでやったらまずクソコードって言われるやつです。

そうはいっても、レスポンシブだとかでどんどん肥大化していく一方なので、何とかしないと身の破滅です。

とりあえず結論として、FLOCSSやれば良いんじゃないですかね。と言ってしまうのもあれなので、とりあえず実行している事を箇条書きで。

とりあえず何かしら公開されているCSS設計思想を取り入れる。

何かしら入れましょう。SMACSSでもMCSSでもFLOCSSでもモジュール組みでも、とりあえずなんでも良いかと思います。大事なのはそれがドキュメントになっていることです。オレオレ設計なんて、1年もすれば、オレオレ設計ver5.0(下位互換性無し)くらいになっている事が多いので、ろくなもんじゃないです。

そんなにオレオレ設計が良いなら、ちゃんとドキュメンテーション作って、メンテしましょう。

別のモジュールへのカスケーディング、CSSの上書きは可能な限り避ける

ここで言うモジュールとは、BEMで言うところのブロックだったり、MCSSでのモジュールだったりです。

別のモジュールへのカスケーディングを行うと、モジュール同士が密結合になり、モジュールに分割した恩恵がほとんど感じられなくなります。かといって依存性注入はできないし仕方が無い部分があるのですが、あまりに他のモジュールのセレクタが出てくるようであれば、リファクタリングが必要です。

こんなCSSが乱発するようならリファクタリング、再設計が必要です。

リファクタリングする。時々モジュールの設計を見直す

カオスが大きくなると手がつけられなくなり、さらに大きなカオスを生み出すので、小さなカオスが生まれたら(先述の他のモジュールへのカスケーディングが大量発生したとか)即座に解消しましょう。CSSの複雑性ってとんでもないので、放置すると突然でかくなったりします。特に序盤の設計が甘いとなおさらなので、「後でやろう」が効かないことが多いです。

気になったらすぐに手を打ちましょう。

命名規則もしっかりと設計しておく

特に何も考えたくなければ、BEMを採用することをおすすめします。

CSSには名前空間という概念が存在しないので、classの命名には気を遣わないとすぐに破綻しますし、一般的な名詞を使うと、それが他のCSSと干渉しがちです。

そこら辺を解決するアプローチとしては、モジュール組みとかもありますが、ぱっと見で干渉しているかどうか等がわからないので、長くて気持ち悪い命名でカバーする方が安全性は高いと思います。

特に、Bootstrapやらfoundationを使うプロジェクトだと、カオスになりがち感がやばいです。サイト用のCSSにはプリフィックスをつけておく方が良いかなと思います。

また、これを守らないオレオレclass名が発生すると大変なことになるので、コードレビューなり、スタイルガイド、ドキュメンテーションでしっかりと食い止める作業も必要かなと思います。語彙集なんかを作っておくのも手かなと思います。

[CSS]BEMの方法論とMindBEMdingという記法 – Qiita

モジュールごとにファイルを分ける

面倒くさいと思いますが、PHPとかでClassごとにファイルを分けるくらいのノリで分割しましょう。モジュールの量、粒度が視覚化されやすいです。また、感覚的に一つのモジュールから他のモジュールに触りづらくなります。

CSSがどんどんプログラミングチックになってきているので、プログラミングで割と使われているやり方を取り入れると都合がいいことが多かったりします。

CSSプリプロセッサを活用する。

使ったことが無ければ、SASSのSCSS記法がいいかなと思います。とにかく情報が多い。

特にBEMを採用するのであれば、”&”がかなり威力を発揮します。それに変数化できるものは極力変数化しておくと、特に後述のメディアクエリ周りでかなり威力を発揮します。

いわゆるメディアオブジェクトというやつは、こんな感じに書けます。

 

爆捗! WordPressテーマ作成ショートカット(3):CSSコーディングで泣かないためのSassの基礎知識と10の利点 (1/3) – @IT

メディアクエリ(Media Queries)を散らかさない。

メディアクエリの指定が何種類もあると、もうデバッグなんて無理です。とてもじゃないけどやってられない。SCSSを使うのであれば、foundationみたいに、こんな感じにまとめておくといい気がします。

Media Queries | Foundation Docs

また、CSS一番小さな画面から設計するのか、大きな画面から設計するのかの方針は最初に決めておきましょう。まぁ基本的にはモバイルファールストが良いとおもいます。

CSSごとにデフォルトスタイルがモバイル用なのか、大画面用なのかがぶれると最悪です。変数化するなり、Mixinを作るなりで、メディアクエリを書かない努力をすべきです。

とにかくメディアクエリの指定は必要最小限にとどめる。メディアクエリを書かずに乗り切れるところで使ってしまうと後々デバッグで苦労します。

結論

現時点では、FLOCSSをちゃんとやることが最適解かなと思います。ドキュメントも日本語で整備されているし、説明も細かいのでおすすめ。Frontrend in Nagoya で存在を知ってから3ヶ月くらい取り入れてやっていますが、SMACSSとかやっている時のモヤモヤが解決されてていいです。

最初からBEMを使うことが前提になっていることも良いと思います。

ドキュメントが長いので最初に躊躇しがちですけど、すぐにどうしていいかわからなくなるので、ドキュメントが長いのはいいことかなと。

慣れてない人は、メロン本を読みながら繰り返し体にたたき込むのがいいとおもいます。あと、CodeGridのBEM、SMACSSの記事辺りは読んでおきましょう。

CSSってフリーダムすぎるので、使ってて最初のうちにものすごい不自由で、CSS書く時間が2倍くらいになってしまうこともありますが、それくらいがっちりしないとすぐに破綻しやすいものかなーと思います。

参考図書

Web制作者のためのCSS設計の教科書 モダンWeb開発に欠かせない「修正しやすいCSS」の設計手法 Web制作者のためのCSS設計の教科書 モダンWeb開発に欠かせない「修正しやすいCSS」の設計手法