#CSS階層モデル
土台の部分から順に
- リセット/ノーマライズ
- グリッドシステム（レイアウトモジュール）
- ベース（要素の設定・装飾）
- モジュール（クラスの設定・装飾、各種パーツ）
- 微調整用CSS（マージン調整など）
WordPress案件が多いのでそれに合わせてネーミングとかは行う。
1~5の階層でそれぞれパーシャルSassファイルを作ってstyle.scssで統合してコンパイルする。
1~3をまとめたものはeditor-style.scssでまとめてeditor-style.cssに出力する。
#Sassファイル構成
_parameter.scss
サイトで使う変数をまとめる。ブレイクポイントやテーマカラー、フォント関連など。
_reset.scss
基本的にNormalize CSSをコピペ。
重複/上書きがノーマライズCSS自体に結構あるのでその辺整理しといたものを作っておくといいかもしれない。
これに追加で、
* {box-sizing: border-box;}
a img {border: none;}
を入れておく。a imgは古いIE対策。さすがにIE11時代に入ってからは不要だと思うけど。
_grid.scss
レイアウトを制御するグリッドシステムを入れる。
BootstrapやFoundationのような巨大フレームワークよりはPure.cssなど、グリッドシステムのみに絞ったフレームワークを採用する方がいい。
Bootstrapからグリッドのところだけを抽出するのも良いけど、保守を受け継いだ人がフルスペックのBootstrapを使っていると勘違いしてしまうのもよろしくないかなーと。
私の場合は自家製のlecssを使っている。
ここまでの階層はすべてのウェブサイトで共通に使える。
リセットとグリッドは大体いつも一緒に使うので、１ファイルにまとめるのもいい。
_base.scss
h1～h6など、クラス名を付けない状態での要素の装飾などを規定する。
WordPressではここまでのscssをeditor-style.scssにまとめ、editor-style.cssにコンパイルする。
_module.scss
個々のウェブサイト全体のパーツなどの設定はここに書く。
今までこのファイルは1つのファイルにしていたが、最近は細分化した方がよいのではないかと考えている。
メディアクエリごとに分けた場合、コンパイル後のファイルサイズが小さくできる。これには欠点もあって、PCサイズの装飾を変更する際、間違ってスマホサイズ用のファイルを編集してしまう、といった取り違えのリスクがある。
保守のしやすさを追求するのなら、WordPressの案件の場合、各テンプレート（home, archive, page, singleなど）毎に分割し、同一ファイル内でメディアクエリを設定するとよいと思う。
現在1ファイルでやっているが、行数が多くなると修正のたびに該当箇所を探し出すのに時間がかかる。
_utility.scss
マージン、フォント、色など、1ヶ所だけ特別に調整したいという用途用に作られたクラスをまとめる。
#クラス名のネーミング問題
今のところ、（機能）（使用箇所）（装飾）の順でハイフンつなぎ、というやり方をしているけど、100%ちゃんと運用できているわけでもなくて悩みの種になっている。
もうちょっと厳密なルールを検討しなければと感じている。
また、リストや表など、構造ががっちり決まっているものに対しては、.class li {}という感じで、詳細度を上げてもよい例外としている。これは、確実かつ大量に存在する子要素の一つ一つの項目にクラス名を付けるのはhtml側の負担が大きいと考えているため。
ただ、最近はこれが必ずしも正解とは言えないような気がしている。リストや表などの特定の箇所のみ、他と違うスタイルを適用したい場合に詳細度地獄が待っている。