BEMまとめ奴
- 公開日
- タグ
- Advent Calendar
- BEM
BEM Advent Calendar 2013 最終日のエントリです。
BEM Advent Calendar 2013 に参加していただいた皆さんお疲れ様でした。そしてありがとうございました。
リニューアルした Adventar で最初にカレンダーを登録した時にボックスのヘッダーカラーがアレな黄土色だった時はどうしてくれようかと思いましたし、開始4日前で 18 枠も開いていたりとか、TL では BEM への闇が広がっていたりとかもしていましたが、なんとか 25 日埋めることができました。カレンダーに参加していない方にも BEM の記事を書いていただいたりと、せまい範囲ながら BEM に触れる機会を提供できたのかなと思えています。
最終日 25 日目の本記事では、BEM Advent Calendar 2013 に寄せていただいた記事だけでなく他の BEM な記事もあわせたまとめを公開させていただきます。「で、出た~w最終日にまとめ記事公開奴~www」です。
まずは本家とその周辺から
BEM 公式サイトです。Yandex というロシアの検索サイトで用いられている方法を改定した命名規則がまとめられています。
左メニューから Methodology > Definitions と進むと BEM の定義が書かれています。ここを読めば MindBEMding はすぐに得られると思います。定義の説明だけでなく、XML や JSON で BEM 管理するためのフォーマットなども載っています。また、Filesystem のページではリソースファイルの名前にも BEM を用いて管理する方法が紹介されています。ビルド時に結合するファイルも BEM な名前管理にすることで保守性をあげようという狙いがあるようです。
Smashing Magazine にも BEM の主要な定義とサンプルをひとつひとつ紹介している記事が連載されていました。
- http://coding.smashingmagazine.com/2012/04/16/a-new-front-end-methodology-bem/
- http://coding.smashingmagazine.com/a-new-front-end-methodology-bem-blocks-reiteration/
- http://coding.smashingmagazine.com/front-end-methodology-bem-file-system-representation/
スライドもあります。
日本語で読みたい方はこちらに Index と Definitions の日本語訳があります。
GitHub で公開されているので BEM 神の声をもっと聞きたい方は clone してどうこうするといいと思います。
Let's MindBEMding!
続いて日本の記事です。
- BEM とは - CHROMA
- SMACSS に BEM を取り入れよう - CHROMA
- BEM という命名規則と Sass 3.3 の新しい記法 - アインシュタインの電話番号
- ちゃんと CSS を書くために - CSS/Sass 設計の話
- Sass と BEM
- Less で BEM ってみたらかなりさくさくコーディングできた!という話 | Toro_Unit
- 変数で BEM る | じまぐてっく
上記記事では MindBEMding で CSS を書くにあたっての多数のサンプル、SMACSS から BEM への移行、プリプロセッサーの強力な拡張機能を用いた管理方法、変数名を BEM ることで使われる先や影響範囲の見通しを良くしようという提案などが紹介されています。プリプロセッサーをお使いでない方には興味が薄いかもしれませんが、サイトを BEM 化しておくのは開発支援ツール的にも良いということです。MindBEMding でセレクタに Block 名が子要素へ継承されていくことを利用して、Block と Element のスタイルの結合性をより明確にできるのは大きなメリットです。僕は BEM 自体にはサイトをスタイルする(デザインカンプから HTML に起こす)にあたってアドバンテージはほとんどないと考えているのですが、冗長な名前付けに対する十分な対価はプリプロセッサーが与えてくれると思いました。
僕が観測した範囲なので MindBEMding な記事はもっとあると思います。まとめに追加するかはわかりませんが、他に記事があったら@o_tiまで教えていただけると幸いです。
BEM リプレイス記事
- CSS の命名規則に BEM を取り入れてみる | dskd
- ブログを初めて BEM 化した時の流れ | dskd
- ブログを初めて BEM 化した時の流れの続き | dskd
- ブログを初めて BEM 化した時の流れの最後 | dskd
- psd ファイルのレイヤー名で BEM | dskd
- Qiita のサイトに BEM を勝手に取り入れてみた on @Qiita
- 「Qiita のサイトに勝手に BEM を取り入れてみた」の解説 on @Qiita
- Bootstrap を BEM に考えてみる - Blog.おにぎりたまごうぃんなー
既存のウェブサイトを BEM リプレイスするにあたって頭を抱えることと言えば、直感的な BEM ツリーと現実の DOM ツリーとのギャップです。アイコンなどの装飾のために空要素や多重 div
, span
で HTML が組まれていると BEM ツリーを構築するのは大変な作業となります。とはいえ BEM はチームで共有するものですから、チーム内で仕様についてコンセンサスがとれていればどんな Block や Element が構築されても良いと思います。ルート Block と子 Element のみを BEM 管理にするような易しめな方法もアリです。サイトのグリッドレイアウトに関するものだけとか、更新が激しいパーツだけとか。
ただ僕としてはサイトの一部だけ BEM るなら最初から全部 BEM ってしまった方が後で楽をできると思います。BEM ツリーのイニシャライズはとても労力がかかりますが、全てを BEM リプレイスできるとそのサイトの全容がガッツリと把握できること請け合い、次第に BEM 神の声も聞こえてくるのでオススメです。
世の中を円滑に BEM るための TIPS
- Emmet の BEM フィルターで BEM るときの HTML をサクッと書く | clear sky source
- BEM に迷う | clear sky source
- BEM で命名する時に役に立ちそうな単語 - < /gecko >
- モディファイアの付け方 - < /gecko >
- 実践 めんどうくさくない BEM - ダーシマ・ヱンヂニヤリング
- BEM というよりクラス名をわかりやすく区切りたい - ksk1015 のブログ
- BEM と接頭辞
BEM に限らず OOCSS でもセレクタの名前付けには頭を抱える時間が少なくありません。BEM ではさらに Block と Element の区別や、アンダースコア2つ、ハイフン2つ(Yandex ではアンダースコア1つ)といったデリミタの見た目に対する嫌悪感から、やっていく内に「BEM 道なんてなかった!」とか「Element はみんなの心のなかにあるんだよ......。」などと言いたくなることも多いです。そういったお悩みを解決するのが上記記事の TIPS です。
その名の通り BEM のキモは Block, Element, Modifier の3つで HTML を説明し管理することです。それができていればデリミタやケースは管理者が必要に応じてコントロールしていいと思います。特に小山田さんの記事ではサイトリニューアルで生まれがちなバージョン違いのパーツの混在を、Block に接頭辞をつけることで共存させるアイデアが紹介されています。単純な操作ですが、バージョンを Modifier 管理に混ぜるよりはるかにメンテナンス性がありますね。小林さんが紹介している Emmet BEM フィルターも煩わしい継承の記述を最小限に抑えてくれるのでいい感じです。
Multilayer CSS
こちらは MCSS という CSS の管理方法を日本語訳した記事です。MCSS ではまず最も再利用可能で抽象的な構造に着目します。それを「ベース」レイヤーとします。次にその再利用可能なパーツがどんな場所に格納されているかを見ます。ベースを格納しているものを「プロジェクト」レイヤーと呼びます。再利用可能なパーツ内の子要素に、MindBEMding な名前付けをしています。また、MCSS は「コスメティック」と呼ばれるレイヤーで OOCSS な名前付けでもって状態の差異を表現するようです。詳しい内容な上記記事をどうぞ。
強調しておきたいのは、BEM と MCSS を比べて Block = ベース、Element = プロジェクト、Modifier = コスメティックなんてことは全くない、ということです。MCSS と BEM はある程度共存できます。ベースとプロジェクト、それぞれに BEM ツリーを構築できます。Block を継承しすぎて冗長になった BEM ツリーは、MCSS によって少し見通しがよくなる可能性があります。本家のブログでBEM から MCSS に移行するサンプルコードが書かれています。Modifier の指定方法が異なるので興味のある方はぜひ御覧ください。
BEM Tools
- BEM ツールに触れてみる - < /gecko >
- BEM ツールに触れてみる(2) - < /gecko >
- BEM ツールに触れてみる(3) - < /gecko >
- BEM ツールに触れてみる(4) - < /gecko >
bem.info で提供されている BEM Tools が紹介されています。貴重な日本語ソースですね。他にも BEM Tools を紹介している日本のブログはありましたが、げこたんさんの方が入力ソースと出力ソースの両方を書いているので良いと思います。ツールと言っても GUI を持ったソフトウェアではなく、コマンドラインから操作するタイプのツールです。使用には Node.js が必要です。Grunt を使われている方ならインストールまでは何ら苦はないと思いますので、ぜひ試してみてはいかかでしょうか。
僕としては定義ファイルの JSON が手編集というのが闇が広がりそうだなーと思うところです。Block や Element をあらかじめ精査して仕様を決定し、その上で一気に初期ファイルをビルドするなどの用途には良いかもしれません。
結局 BEM って
HTML と CSS についての BEM では、フロントエンドの開発手法がフレームワークやプリプロセッサー、ポストプロセッサーの台頭により多様化している昨今、Pure な BEM 道を突き進むのは「今風ではない」のかもしれません。僕はこの小さなブログを BEM 化した程度の経験しかないので、厳格な BEM で起こした大規模なサイトというのは Yandex くらいしか見たことがないですし、BEM 化することで実際にどれくらいメンテナンス性や拡張性が上がったのか具体的に説明しているページを知りませんから、BEM Advent Calendar を立ち上げておきながら BEM ることの本当の恩恵を実感したことがない体たらくです。
何かが良くなったり楽になったりしないと人はなかなか道具を変えません。BEM は全てをいい感じにする魔法の方法論ではありませんから、Pure BEM から MindBEMding へ少しルールを崩していけば、OOCSS との親和性やフレームワークとの連携など少しとっつきやすさが出てくるので、現在取り入れている方法論にうまく混ぜていって BEM の美味しいところだけを啜っていく世の中になるのかもしれないなぁと思います。ただ MindBEMding も混ぜ方を間違えるとただ読みづらくて使いづらいだけになってしまうので、ベター BEM、ベスト MindBEMding なプラクティスがもっと必要だなと思う次第です。
おわりに
二ヶ月ほどの間 BEM のことばかり考えていました。最初に dskd.jp を BEM 化した時には見えなかったことが、BEM Advent Calendar が更新される度に見えるようになってとても勉強になりました。BEM について記事を書いたりや Twitter などで言及していただいた方々、改めて本当にありがとうございました。
P.S なんとかこれをやらずに済みました。
眠すぎて24日目を「サイト構築する際に導入したい!僕が3年間で厳選したCSS命名規則方法論10選!」やりかねない。— 越智 (@o_ti) 2013, 12月 24