職場でFLOCSSについて教わったのだけれど、今ひとつ消化しきれず。自分のブログのテーマをちょうど作成中だったこともありFLOCSSで書こうとしたんだけど、わからないことが多かったのでいろいろ調べてみた。
わからないこと
- ある一つのものを定義したいとして、layoutに所属するCSS要素、componentに所属するCSS要素、projectに所属するCSS要素はどう分けるべきか？
- ある階層化されたFLOCSS要素（BEM）があったとして、それはどのファイルに記述されるべきか。SCSSファイルの適切な分割方針
パンくずリストbreadcrumbを作る場合、l-breadcrumb？ c-breadcrumb？ p-breadcrumb？（それともその組み合わせたマルチクラス？） それはl-headerに記述？ component/c-breadcrumbに記述？ といったようなことでぐるぐる頭が回ってました。
「FLOCSS」でとりあえずググる
これらのサイトでは、Componentは「繰り返し使われる基本的な構造」であり「装飾的なスタイルを定義することは避ける」とある。
こちらの記事には結果として出力されたサイト（リフォマ − リフォーム・修理を定額価格で探せる）が紹介されており、実際のHTML/CSSを見ることができたので大変参考になった。こちらではl-container、l-contentというクラスが多様されており、「構造を分離する」という点で参考になった。
壁に付箋を貼りだして整理された写真が圧巻。ここまでやんないといけないんだ、やっぱり。大ごとだな……。
「FLOCSSを扱いきれないあなたに」……俺だ。orz
たしかにcomponentとprojectを分ける意味がわからないならまとめてしまうという手もある。
最初に職場でもらった参考URLがこれだった気がする。Utilityクラスの扱いについて、私もけっこう慎重派
「Block毎にファイルを切る」という記述があるので、ファイル分割の参考になった。
調べた結果おぼろげに見えてきたこと
layoutには、大きなブロック単位の構造を置く
レイアウト形状による分類なので、非semanticであるように心がけた方がいい気がする。l-headerはheaderという意味を含んでしまっているが、l-full-boxのように意味を離れて形状に特化したclassなら、使い回しが利く。
l-entry-titleとl-article-titleがブロックレイアウトとして共通のCSS要素を持つなら、それはl-titleとして共通化し、残りをc-entry-title、c-article-titleに分けるのがいいような気がする。
追記: いや、必ずしもそうとはいえないか。デバイスサイズによって形状が変化する場合にクラスをつけかえることになってしまう。この辺りのダイナミックな変化をうまく吸収できるようにclassを分けていく作業は、なかなか骨が折れるな……
componentはページをまたいで繰り返し利用されるパーツ
全project中で繰り返し登場する共通の要素（パーツ）、として認識した。
装飾的な要素を含めないとするサイトもある一方で、装飾的な要素もcomponentに書いている例も見受けられるので、そこはあまりキニシナイことにした。なぜ装飾的な要素を避けないといけないのか、理由がよくわからないしな。
projectは、テンプレート固有の要素
これについては、私が念頭に置いているのがブログということで、認識しづらいのかなと思っている。
ブログの場合には、テーマファイルのテンプレート分割に倣うのが良い気がした。曰く、p-front-page、p-single、p-archive、p-searchなど。
参考にしたサイトでは「4回以上繰り返されるものはcomponent、3回以下ならproject」といった登場回数で区分しているものもあったけれど、個人的にはprojectは「componentで対応できない、個別の要因を記述する」場なのではないかと想像している。つまり「singleページとarchiveページに登場する同じcomponentなんだけど、singleページとarchiveページで見栄えが異なる」といったことに使ったら使いやすいのではないか。
となるとprojectには「全ページ共通パーツだけど、そのうちでprojectに固有のCSS要素」「project専用パーツ」という、粒度の異なる記述が含まれることになりそう。
また、「基本的な構造をcomponentに記述しておいて、プロジェクトメンバーが追加するCSSはprojectに追加させる」という記述も見つけた。「サイトの基本マナーはcomponentで、それから逸脱する記述はproject」ということで、サイトの基本マナーを保護する思想になっている。だとすれば、最初projectは空っぽでも構わないわけだ。
ある一つのものを定義したいとして、layoutに所属するCSS要素、componentに所属するCSS要素、projectに所属するCSS要素はどう分けるべきか？
- 大きなブロック構造に関する記述 → layout
- 繰り返される（つまり共通の）要素 → component
- ページテンプレート固有の要素 → project
ある階層化されたFLOCSS要素（BEM）があったとして、それはどのファイルに記述されるべきか。SCSSファイルの適切な分割方針
これはまだ明確ではないんだけど、Block単位でSCSSファイルを作り、そのファイル内にElement、Modifierを入れていくことでいいみたい。でないと、そもそもSCSSの階層化された記述を活かせないしな。
Block単位でSCSSファイルができるので、だいぶSCSSファイルの数は増えるけれど、どうせ最後はapp.cssに集約されるんだし、とりあえずやってみよう。
同じcomponent classの中にも役割の違いが出そう
たとえば、タグの内容によって色を変えたいとする。果物（いちご、りんご、みかん）は赤、野菜（きゅうり、ほうれんそう）は緑といったこと。
この場合、タグとしての共通の振る舞い（サイズ、フォントなど）はc-tagとして記述し、色に関する記述はc-fruit、c-vegieとして分けることになるはず。
この辺はFLOCSSとは無関係に「共通項目をクラス化する」という基本的な分割思想の部分なわけで、その辺を混ぜて理解しようとしてごっちゃになっていた。
Utilityクラスが解決できる部分もあるかもしれないけど。
まとめ
- 大きなブロック構造に関する記述 → layout
- 繰り返される（つまり共通の）要素 → component
ページテンプレート固有の要素 → project
SCSSファイルはBEMでいうところのBlock単位で作成し、Element__Modifierはその中に記述する。
- projectには「全ページ共通パーツだけど、そのうちでprojectに固有の要素」「project専用パーツ」の両方が含まれる
- いずれにせよ、「何を共通項目としてクラス化するか」はよく考えないと、FLOCSSが解決してくれる銀の弾丸ではない。
……いや、すまん、「銀の弾丸ではない」て一度言ってみたかっただけで。
