#自前で最強のCSS設計（）を構築する
今やCSS設計という言葉自体がかなり浸透して、OOCSS・BEM・SMACSSといった設計方法を
実際に使ってる方も多いと思います。
上記のようなCSS構成案を既に取り入れている場合でも、
- 各設計方法の良いところを取り入れたい
- 細かいところで融通が利かない
- もう少しわかりやすく簡潔にしたい
なんて感想を持っている方は結構いるんじゃないでしょうか。
これから紹介するものは、著者が実際に使用しているものもありますので、
新しいCSS設計を構築したり、アレンジする際のヒントにしていただければ幸いです。
##設計概念について
様々な概念がありますが、ここでは代表的なものを取りあげます。
同じ意味合いを持つ概念でも、CSS構成案ごとに名称が異なっていたりしますので、
名称の違いだけ混同しないように注意が必要です。
##ベース
ブラウザのスタイリングをリセットしたり、均一化するものです。
Reset CSS,Normalize CSS,Sanitize CSSがあるので、要件に適したものを選びましょう。
###Reset CSS
ブラウザのスタイルをすべてリセットする。
Eric Meyer's,html5doctorなどが代表的。
####Eric Meyer's
http://meyerweb.com/eric/tools/css/reset/
####html5doctor
http://html5doctor.com/html-5-reset-stylesheet/
###Normalize CSS
ブラウザごとのスタイルの違いを補正する。
http://necolas.github.io/normalize.css/
###Sanitize CSS
Normalize CSSにユーザビリティ等の改善が加えられている。
ただし、対応ブラウザは最近のものに限られる。
http://10up.github.io/sanitize.css/
##レイヤー
MCSSやFLOCSSでは、この考え方が使われている。
サイト上の構成要素を大まかなものから順に配置して組み立てる概念。
PSDのレイヤーを想像するとわかりやすい。
後から読み込むものほど、粒度が高いもの（細かいパーツ等）にすることで、
自然とCSSの詳細度（specificity）が管理しやすくなるという仕組み。
粒度の高いものほど詳細度が高くなる傾向があるので、これを有効活用した設計。
CSS Wizardryの方が提唱していたITCSSによる
設計思想もこのレイヤーに該当する考え方じゃないでしょうか。
##コンポーネント/モジュール
BEMのBlock、SMACSSのModuleなどが当てはまる。
サイトを構成するブロックやパーツを示す。
##サブクラス
BEMのElement、OCSSやSMACSSのSub Classなどが当てはまる。
ブロック内のパーツや構成する細かな要素に使われる。
##バリアント
BEMのModifierが当てはまる。
要はバリエーションのこと。前述のサブクラスがバリアントを担っているケースもある。
rscssではバリアントの接頭辞（プレフィックス）として、
-（ハイフン）を用いたらいいのではないかという提案があります。
<button class="icon -overkill">バリアントナイフ</button>
rscss - Variants
http://ricostacruz.com/rscss/variants.html
また、BEMを発展させた考えとして、Modifierを切り分けて--（ハイハイフンフン）から
始めればいいんでないかという考え方もあります。
（※どっかにソースがあったんですが、URLを失念しました／(^o^)＼）
<button class="icon --magictape">バリバリサイフ</button>
##ステート
コンポーネント/モジュールなどの状態を表す考え方。
SMACSSのStateが当てはまる。
ECSSでは、このStateを表す方法としてWAI-ARIAの利用を勧めています。
Enduring CSS: McrFRED, November 2015
http://ecss.io/slides1/
- aria-disabled="true" (used instead of is-Suspended)
- aria-live="polite" (used instead of is-Live)
- aria-busy="true" (used instead of is-Busy)
以下のページではケーススタディとして、より詳しくWAI-ARIAの利用例が示されています。
The Accessible Current Page Link Conundrum | HeydonWorks
http://www.heydonworks.com/article/the-accessible-current-page-link-conundrum
<nav role="navigation">
<ul>
<li><a href="/" aria-describedby="current">home</a></li>
<li><a href="/about">about</a></li>
<li><a href="/contact">contact</a></li>
</ul>
</nav>
ただし、アクセシビリティのためにWAI-ARIAを使うのではなく、
CSS設計をメインとして使うのは、バッドプラクティスだと思いますので、
目的と手段が逆にならないように気を付ける必要がありそうです。
また上記のような使い方の問題を回避するために、
カスタムデータ属性を活用するのも良い方法だと思います。
How I'm Using Data Attributes to Write CSS Components — Sacha Schmid, Front-End Developer
https://sacha.me/articles/css-data-components/
<div data-grid>
<div data-col="1-2 M1-4 L1-5"></div>
<div data-col="1-2 M1-4 L1-5"></div>
<!-- ... -->
</div>
カスタムデータ属性を使用するケースでも、上記の例のようにコンポーネント/モジュールとして使ったり、
ステートとしても使ったりする場合は、どこまでをclassでどこからをdataで対応するのかを
明示しておかないと逆に扱いづらくなることも考えられるので、
コーディングルールで明確にしておくことが必要です。
##ヘルパー/ユーティリティ
CSSプロパティ単体で成り立つもの。
一般的にEmmetの略語で表記されることが多い。
<div class="tac">ヘルパーはタックが安定</div>
rscssではヘルパー/ユーティリティの接頭辞（プレフィックス）として、
_（アンダースコア）を用いたらいいのではないかという提案があります。
rscss - Helpers
http://ricostacruz.com/rscss/helpers.html
##最後に
オレオレCSS設計を使うには、ドキュメントとして残しておくことが必須です。
「とりあえず引き継いだけど、設計が全然把握できねええええ！」といったリスクだけは避けるようにしましょう。
独自要素満載にしないのも結構大切じゃないかなと思ったりします。
今回紹介したものの中には実際に使用しているものもありますが、独自CSS設計を扱う際は、
スタイルガイド内にコーディングルールを記載し、CSS設計の内容についても把握できるようにしています。
最初は面倒ですが、一度作ってしまえばほとんど手を加えることがないのと、独自CSS設計を使わない際は、
該当の部分をコメントアウト（または、差し替え）してしまえばいいので思ったよりラクです。
改めてCSS設計を考えるうえで、何かの参考になれば幸いです。