scsidnikufesin

「BEM CSS」あたりでググると検索キーワード候補に出てくるので応援しておいた。BEMは気持ち悪い。人気の検索ワードをTITLEタグに掲げてしまっては、同志が押し寄せてしまうかもしれない。いまからひどいことを書きます。

BEMみたいなことをやろうとする思想は理解できる。だが客先自身で更新・運用されるにせよ手が加わるのはCMSでできる範囲内のみで、ほかに何かあれば自分のところにメンテ依頼が来るといった規模感の案件を、チームもSCSSもSASSもGitHubもクソもない零細企業・部門または個人のコーダーがやるにあたり、自分自身に対して厳格なバカよけをした挙句に視認性の著しく劣るHTMLが出来上がるのは納得いかないし何より非効率だ。
とはいえ自分のうっかりや見通しの甘さでクラス名がぶつかりそうになったり、命名の必要に迫られるたびに20秒～1分くらいウーンと考え込んでしまうようでは宜しくなく、そのあたりは何らかのシンプルなルールがあるといい。

ということで、個人的に採用している記法について書いてみるが、他に同じことをやっている人を見ないから多分最悪に問題のあるやり方なのだとは思う。常に自分ひとりが俯瞰できている場合に限り、けっこうラクなやり方だ。

クラス名に迷わないのはBEMのいいところ、それはそのとおり。でも視界内に20個くらいheader__とかentry__といった文字列が繰り返されるHTMLには耐えられない。
ならば共通部分、BEMのBやMを端折ってしまえば？
それをやった途端、BEMの思想からはかけ離れたものになるが、そもそもクライアント自身がリッチテキストエディタで自由に編集しうるエリアにクラスなど怖くて使わない。その外側の、CMSのテンプレートに埋まっているのであれば、柔軟な変更の可能性を常に想定する必要があるだろうか。建て増しみたいな改修がマメに発生する場合はその限りではないが、いまの勤め先で対応する案件でそういうことはあまり多くない。

つまりこうする。

<ul class="serviceMenu">
　<li><a href="（ページURL）">
　　<div class="__pic"><img src="（画像URL）" alt=""></div>
　　<div class="__txt">
　　　<h3 class="-ttl">タイトル</h3>
　　　<p>説明文</p>
　　</div>
　</a></li>
（以下li要素がいくつか）
</ul>

.serviceMenu {　～　}
.serviceMenu .__pic {　～　}
.serviceMenu .__txt {　～　}
.serviceMenu .__txt .-ttl {　～　}

HTMLは劇的に読みやすい。.__picや.__txtはHタグやPタグのようにそこかしこで使えばよい。もう命名に迷う必要はない。
CSSは一見かなりBEMだ。食品サンプルとリアル食品くらいに別物だが。頭にアンダーバーが二つもついていれば、うっかり裸の.__txt要素に何かを宣言してしまうヘマはするまい。
必ず親にユニークなブロックを作って、その中だけでスタイルを指定するようにする。

ちなみにBEMでいうところのModifierにあたる部分がこの例ではハイフン1個の.-ttlとしてあるが、先頭にハイフンを2つ使ったクラス名はIEで無視されてしまうようだ。もうIE対応なんてしたくないが、無用な事後対応を避けるためトラブルのもとは事前に排除する。

.__txtや.__picといった汎用なクラス名をエレメントとしてガシガシ使い回しているため、中に違うブロックを含んだ途端破綻するのが目に見えていますが、大丈夫ですか？というのが、この手法の最大の懸念だとは思う。

単独作業者なら、今作ろうとしているパーツが今後に渡ってそんなことあり得ない性質のものかどうかは判断がつくと思いたい。
仮にそういう可能性があるのであれば、CSSでは直下セレクタを使うなりして無用な波及を避けるようにし、それにあわせてHTMLはいたずらに要素の階層関係が乱れることのないよう、あらかじめ可能な限り無駄のないコードを書く（というかそれは常にやる）。
それでも危うい時は多少ユニークなクラス名を登場させる。危うい時がそんなにないように見極めをしっかりすれば、そのくらいの特例を作っても破綻はしない。

明らかに汎用な要素の類（日付-件名が並ぶ新着情報リスト、会社概要などに使うDLタグを使った疑似テーブル、横N分割のパネル表示、半透明の背景色を敷いたパディングつきボックス、etc.）は、細かなあしらいを除いた基本の骨組みをがっつりフレームワークの如くまとめて、いつも同じものを流用する。ここが充実していると先述の特例は随分減る。
HTML内にデザイン内容を直接示すクラスがぼちぼち書き込まれることにはなるが、死んでもそれをやるなというのは潔癖かなと思う。ソースの美しさは「あとから読みづらい/さわりづらいものにしない」という目的のもとにあるべき。

チームとかSASSとかSCSSとかGithubとかBacklogとかSlackとかがある世界の人はこんなの全員発狂するだろう。バカ呼ばわりには甘んじるし、Qiitaからのリンクは断固ことわる。
その手の境遇じゃない、ほどほどサイズの案件専門の人にとってのちょうどよい情報は、あんまりわざわざウェブ上で主張されていないようなので書いてみた次第。自分はこれのおかげで作業中に立ち止まる時間が大幅に減った。