Web制作を始めて3～4年は経ったのでcss設計のマイルールを書き出してみた

cssについて暫定で決めているマイルール。

この記事は自分用メモを兼ねて。ただ私自身初心者の頃に「みんなどういうルール作りをしているんだろう？」という疑問を持っていたので、反面教師でもなんでも何かの参考になるかもしれないと思っての記事化。

私の主な制作条件。

とりあえずは自分だけがわかればいいとはいえ、後で見て混乱はしない程度の規則性は持たせたい。もちろん自分がずっと管理し続けるとは限らず、だれが見てもわかりやすいは必要。

なお私がcssのルールや命名規則等をなんとかしなきゃと思った時に主に参考にしたのは以下。この記事の自分ルールも、多くはこの本での学習がベース。

css設計思想等

1. OOCSSをベースに（BEM等）
2. 詳細度にできる限り頼らないが適宜利用はする
3. 基本的にstyle.cssファイル一つだけに書く（reset.cssと合計で2つ）
4. 命名規則は以下を使う

css命名規則

1. __アンダーバー2つ…レイアウト的に親子関係　.menu__wrap→この場合親ブロックに.menuというクラスがある。子ブロックが増えていく場合はこんな感じ.menu__wrap__hogehoge
2. —ハイフン2つ　バージョン違い。.mark－－a .mark－－b　※見にくいので全角
3. _アンダーバー1つ　ブロックが親子関係ではないもの同士をつなぐ。bottom_menu→ボトムブロックのメニューだがレイアウトは親子ではない。
4. –ハイフン1つ　単語同士をつないで一つの言葉にしたい。my-keywords

ただ毎度制作が進むにつれ適当な命名になっていく。もともと情報の整理は苦手。だから上のようなルールを決めていてもうまく守れない。

特に1.と3.は使い分けを間違えたりあいまいになることが多々。また3.と4.も正直その時の気分のような感じになることも。

4.についてはここだけキャメルケースにするほうが見やすいかなと思いつつ、-と_のみで統一したいという理由。cssに大文字があってほしくないというただの好み。ただこのルールはちょっと失敗かなと思うのは、パッと見てわかりにくいこと。

例えばこんな感じのクラスをつける。

.menu__search-keywords__wrap

サイト上で使いまわす検索窓パーツをsearch-keywordsと命名した。ただあとで見るとmenu__searchとkeywords__wrapがつながっているのか？とか思ってしまう。まあ仮にそうならばルール上③のようにアンダーバーでつなぐはずなのでよく考えればわかるが、ぱっと見で混乱するというのは本当は良くない。あと他人が見たらそんなルール知らんとなる。やっぱりここはキャメルケースにした方がわかりやすい。

.menu__SearchKeywords__wrap

これなら「SearchKeywords」というのは分かれておらず、最小単位なのがすぐにわかる。

あと実はこれ.menuという親はない。ということは最初の__は_のほうがルール上は良いはず。でもこうしてしまった。こういう感じで毎度制作が進んでくるとマイルールから少しずつずれていく。でもしかたがない。完璧主義でやろうとするとモチベも下がるし速度もかなり落ちるのである程度適当も心がける。

1枚のstyleへの書き順とコメントアウトルール

1. 全体（に影響があること）
2. ヘッダー
3. フッター
4. コンテンツエリアの基本レイアウト
5. サイドバー
6. 汎用パターン、ブロック（全ページで使える）
7. トップページ
8. 下層ページ

コメントアウトルール

上リストを大見出しとして普通に以下。

/*トップページ*/

これに小見出しをつける場合はアンダーバーをつける。

/*＿特集slider*/

この場合トップページに置くスライダー。

孫ならアンダーバー2本になることもある。

/*＿＿特集slider slickカスタマイズ*/

上の場合スライダーのjQueryに対しての上書きcss。どこが関係する部分なのかはっきりさせるためにコメントをつけた。

なぜスタイルシート一枚か

まずいろいろ試した結果私の場合は一枚が一番ラク。

「複雑なトップページだけ分ける」とか「レイアウトのcssと装飾パーツのcssで分ける」とかもやろうとしたことがあるけど、私の場合かえって手間に感じた。共通化とか分類とかファイルの開閉とか。後で分けるにしても最初から分けて書くにしても同じ。

あとはWordPress化することが多い、というのがある。まずスタイルを一枚のstyle.cssにしてルートに置いておけばテーマ化したときにそのままで済む。別に分割しておいても特に手間ではないが、なんとなく一発で終わるというのがいい。

またfunctions.php側や自作プラグイン側にcssを追記したり移動したりすることも多い。静的HTMLファイルの時点でcssフォルダ内に複数のstyleファイルがあるパターンだとかえって手間になる可能性がある。

部品共通化のタイミング→2~3回繰り返したら

部品や同じレイアウトパターンは明らかに共通して使いまわすことがわかっていればもちろん最初から切り出す。ただ最初から完璧にやろうとしてもほぼ必ず漏れが出る。また制作中に追加や変更がある場合もある。

ということで後から共通化する場合には2回出てきたら切り出して共通化する。最初3回でてきたら部品として切り出す的な考え方を本で学んだのでそうやろうと思っていたが2回にした。

理由は2回出てくると3回以上になる可能性も高いし、3個になってからだと逆に面倒くさい場合もある。単に3つという作業数もそうだし、詳細度などの関係もあるので。

共通化するか迷ってまだしないという場合はそれぞれはっきりと判別できるような別のクラス名をつける。いままで詳細度などを使って中途半端に共通化してきたが、あとで忘れて崩したり余計な思考力をつかったりで時間の無駄が多かったため。

最初の頃はなぜか異常にcss記述を短くしたがるというか、重複していたらダメみたいに思っていたが、今は重複している記述がたくさんあってもそれはそれで良いことと捉えている。破綻するよりは冗長なほうがいい。

メディアクエリ

大抵のものはデザイン案の時点でスマホ中心（にしたい）。PC幅時はそれにサイドバーをプラスしての2カラム、といった感じ。

ということでmin-widthで書く。ブレイクポイントは今のところ基本を769px。

@media(min-width: 769px){

ブレイクポイントの数については1つで行くのを基本に、どうしてもなら2つ。そもそもタブレット対応で2つ以上にしないとうまくないようなデザイン設計にはしないという感じ。

マイルール、方針まとめ