はじめに
業務で新規サイトを制作するにあたり、今まで採用していたCSS設計をそのまま採用するのではなく、このタイミングで一度どの設計手法にするのか見直すことになりました。
そして結果的に新しい手法を取り入れることとなったので、新しい手法を学びながらサイトを作っていった時のお話をまとめたいと思います。
ちなみに、CSS設計手法についてまとめた記事を以前書いたので、記事内に出てくる設計手法に関してはこちらの記事を参考にしていただけますとありがたいです。
結構メモ的に書いてるので詳しくはないです。
各CSS設計手法を取り入れる上でのメリット・デメリットをまとめてみた
もくじ
今までの話
今までは主にSMACSSを採用してきました。
（主に、というのは作り直すこともできず設計もなにもないサイトもまだ存在しているため…）
SMACSSを採用して良かったなと思うところは、
- 細かいパーツをmoduleとして作るので使い回しがしやすい
- margin等の位置調整はlayoutに切り分けているので同じ見た目だけどmarginが違うものを作りやすい
- マルチクラスつかいやすい
このあたりです。
ちなみに上記で紹介した私の記事に書いているSMACSSのメリット・デメリットの内容と同じです。
そして、使いづらいなーと思うところが、デメリットにも書いた
- 場所に依存するパーツが使いづらい
というあたりです。
サイト上でLPOのABテストをよく行うのですが、その際に
「このページに使うパーツは既存パーツとほぼ一緒だけどちょっと違う」がでてきてしまい、結局moduleとして切り分けても新たにスタイルを作ることになり使い回せないパーツが増えてくるようになりました。
このような問題を踏まえて、新規サイトにはどのような手法を取り入れたらわかりやすく使いやすく管理のしやすいCSSを作ることができるのか、と各設計手法を調べました。
そして、FLOCSSを採用することとなりました。
FLOCSSを採用した理由
なぜ採用したのか、それはSMACSSで私達がメリットだと感じていたところはそのままに、デメリットと感じていたところを補填できるためです。
FLOCSSは、
1. Foundation - reset/normalize/base...（ベースのCSS）
2. Layout - header/main/sidebar/footer...（ページを構成するプロジェクト共通のコンテナーブロックを定義）
3. Object
1. Component - grid/button/form/media...（再利用可能なパーツ）
2. Project - articles/ranking/promo...（プロジェクト固有のパーツ）
3. Utility - clearfix/display/margin...（便利クラス）
このようなルールで構成する手法となっています。
上にあげたSMACSSで良かったところは下記のような置き換えで対応できました。
-
細かいパーツをmoduleとして作るので使い回しがしやすい
→ObjectのComponentとProjectを使えばOK -
margin等の位置調整はlayoutに切り分けているので同じ見た目だけどmarginが違うものを作りやすい
→Projectを活用すればOK -
マルチクラスつかいやすい
→命名規則はBEMだけどマルチクラスOKなので問題なし
そしてデメリットとしてあげていた
- 場所に依存するパーツが使いづらい
に関しては、Projectで補えるのではないか？という話になり、採用することとなりました。
ちなみにどの設計手法にするのか検討するMTGのために各設計手法を調べてメリット・デメリットを出しました。
それをそのまま記事として出したのですが、思った以上にいろんな方のお役に立ててうれしかったです
その時合わせてそれぞれの手法を取り入れているサイトも調べてリストアップしていたのですが、
昔FLOCSSを勉強しようと採用しているサイトを探したときよりも断然多くなっていて驚きました。
実際に作ったときの話
ここからは、私がどのようにCSSを作っていったかの話になります。
今回は実際に作っている最中どのようなことを考えて作っていったのかも書きたいと思います。
FoundationとUtility
すごく最初の話になりますが、とりあえずフォルダを作ってベースのCSSやリセットCSS、Utilityを入れていきました。
Utilityですが、参考記事等を見て、出回っているものを使用しようかとも思いましたが、今回は随時必要なものを自分たちで作って追加していく形になりました。
marginやフォントサイズについては、もともとpxなど決め打ちの数字を入れるUtility的なClassを作らずに相対な名前をつけたものを使用していたので（class名にmb20というようなものを入れない、large/smallなどを使って基準数値に対してのclass名をつける）その部分に関しては同じルールでつくりました。
また、今回命名規則はBEMだったので、Utilityは
.u-display--flex
というように、
「u-プロパティ--値」のルールを決めて書きました。
Layout
SMACSSで今まで書いていたので、最初はLayoutに戸惑いました。
SMACSSのときはmoduleに対してのレイアウトを指定するようなイメージでつけてたのですが、FLOCSSはページを構成するプロジェクト共通のコンテナーブロックのスタイルを定義、とありました。
今までは細かい単位でLayoutを指定していたのですが、FLOCSSではパーツをみたときのレイアウトではなく、ページ全体をみたときのレイアウト指定のためのスタイルとして作りました。
このへん言葉むずかしいですね。ヘッダー、フッター、サイドバー、というような全体のレイアウト構成に対してのスタイルを各Classに当てていきました。
このときに、headerのCSSはLayoutの中に全部入れちゃうの？とかも悩んだのですが、参考にしていたサイトたちはLayoutのheaderには配置を構成するスタイルを指定していたので、あくまでもLayoutとしてのスタイルのみを指定することにしました。そしてheaderの見た目を指定するスタイルはProjectにいれました。
今回FLOCSSを採用するにあたって、Spotlightさんをすごく参考にさせていただきました。
その他にもいくつかFLOCSSで書かれているサイトはかなりソースを拝見しました。食べログさんなど…。
CSSを書くときは本当に他のサイトを見て回ることが大事だなと改めて思いました。あとはgithubでもかなり検索しました。github、ありがたい…。
Component
Objectの中のComponentです。
FLOCSSで一番不安だったのは、ComponentとProjectの切り分けです。
ここに関してはBootstrapをかなり参考にし、BootstrapのComponentにあるようなものはComponent、ほかはProject、というわかりやすい判断基準を設けました。
あくまでも迷ったときの判断基準です。
FLOCSSのドキュメントにもComponentについて
一般的によく使われるパターンであり、例えばBootstrapのComponentカテゴリなどに見られるbuttonなどが該当します。
と記載されていたので、迷ったらまずはBootstrapを見に行くようにしていました。
実はUtilityに関してもBootstrapを参考にしたりしています。
Project
その他、場所に依存するパーツや最小単位にならないパーツなど他のものはProjectに入れています。
SMACSS時の良かったことにあげていた
- margin等の位置調整はlayoutに切り分けているので同じ見た目だけどmarginが違うものを作りやすい
に関して、Projectで対応できたので、Componentと同じ名前のファイルをProjectにも生成し、Projectで細かい調整などはしています。
BEMについて
命名規則はBEMということで、今回始めてBEMで名前をつけました。
正直導入前は長いのやだな〜きもちわるいな〜なんて思っていたのですが、
実際やってみるとわかりやすく考えやすくて、これいいかも、と思ったりしました。
実際に後輩がBEMの考え方で名前をつけるようにしたら命名しやすくなったと言っていたので、さすが多く採用されているだけあるな…と勝手に思っていました。
ちなみにですが、私は名前を考えるときに
| なまえ | イメージ |
|---|---|
| Block | わかりやすいかたまり |
| Element | Blockの中に置く単体で置けないやつ |
| Modifier | Block-Elementの〇〇バージョン、って言えるやつ |
というようなイメージを頭の中につくって考えています。
すごい雑なんですがこれでうまく伝わる…と…いいな…。
実際に作ってみて
というような感じで作ってきました。
今回は複数人で作っていたのですが、ある程度Componentを作ってからなら複数人で作っていってもバッティングも少なくできたのでよかったです。
途中からはComponentの使い回しとProjectの生成になるのですが、Projectはあまり複数ページに跨ぐものではないので、同じものを作ってバッティング！みたいなことはなかったです。
複数人でガッとつくる場合はECSSが良いんだろうな〜とは思っていたのですが、今回はFLOCSSを採用して結果的にはとても良かったです。
さいごに
まだ作ったばかりで、SMACSS時に問題になったLPOによるCSSの増加という段階までいっていないので、本当に課題が解消されるのかというのはここからが本番だと思っています。
が、今の段階ではかなり管理はしやすいそうな感じはしています。
また運用してみて見えてきたことや、そこからもし改善をしていったときにはまた記事にまとめられたらいいなと思っています。
設計を考えていたりするときに思うのですが、やはりCSSの大変さというものは他の職種の人たちには伝わりづらいのかもしれません。
まだCSSというものに対して見た目を作るもの、見た目をつくるだけだからすぐできそう、としか認識されていないときもあります。
このように、見た目を作るだけではなくて管理しやすいCSSを作るために、破綻しないCSSを作るために悩んでいたり考えて作っているんだよということがもっと伝わるといいなあと思います。
もっといろんなサービスの設計時の記事がふえるといいなー！と希望を書いて終わりにしたいと思います。
ありがとうございました