https://github.com/juno/bem-methodology-ja/blob/master/definitions.md
- ddd的な各コンポーネントに対する命名 以下に説明する内容全てのこと
- 検索フォーム、とかロゴ、とか
- ヘッダーを大きくしてね、みたいな風にコミュニケーションする
- アプリケーションの構成要素
- 検索フォームブロック
- 単体のものあればネストされたものもある
- ブロックの中で文脈依存で役割を持つもの
- "検索フォーム" blockの"input" elementと"button" element
-
タブとかリストビューとか
-
コレクション
-
ヘッダーブロックの中にsearch blockとか
-
ネスト
-
こういった構造をbem treeと読んでdom tree的なmarkupで表現可能 jsonとかそういうテンプレートで扱えるから便利ですね (xjstベースのdslでやってるそうで)
-
以上の内容で最も重要な点は、各blockが完全に独立して表現できるということで、ネストした状態で表現が必要なelementとして定義が必須なことと明確に区別するべきである
- ブロックやエレメントはcss的にユニークなクラスを持つ
- cssセレクタにhtml要素などの文脈フリーではないセレクタは含まない(.menu td)
- カスケーディングセレクタを避ける
- ブロックのcssはblock nameと同じ (.menu)
- エレメントは、任意のセパレータで区切られたblock nameとelement name(.menu .menu__item)
- カスケーディングを最小にするために、エレメントのCSSにはブロック名を含める
- ブロックとエレメントは入力データを表現する必要がある
- ブロックはbem treeのどこにでも出現できる
- コレクションとして表現可能、つまり
- idベースのcssクラスを使わない
- 動揺の振る舞いを持つブロックはjs的に動揺に検出される
- 例えばトップメニューとボトムメニューでエレメントは一緒だが見栄えや振る舞いが違う要な場合
- ブロックに対してcssを適切に表現する
- .menu.menu_size_big.menu_type_buttons
- "どこに出現するか"よりは"どのような振る舞い・見栄えを示すか”のほうが重要
- エレメントについても同様に
- .menu__item.menu__item_state_current
- 上でDDDって書いたけど、まさにユニバーサル言語的なことを期待していて、で"メンバーはデータドメインに関して合意を持ち、ブロックやエレメントの命名にはそのドメインを使うべきである" だそうです
- 開発コミュニケーション上の観点では同じ用語を使うようになって便利
- cssの観点では命名規約に則ったdslが使えるようになって便利
- ↓なるほど、これをscssでやるのは結構大変じゃないかなあ
.menu {
__layout {
display: inline;
}
__layout-item {
display: inline-block;
…
}
__item {
_state_current {
font-weight: bold;
}
}
}
- jsでは、クラスセレクタを使う代わりに特殊なヘルパライブラリを使うと良い
- $('menu__item') みたいなのよりは↓みたいなの ま言いたいことはわかる
block('menu').elem('item').click( … );
block('menu').elem('item').setMod('state', 'current');
block('menu').toggleMod('size', 'big', 'small');
- jsを加味した再利用性を考えたい たとえばホバーすると挙動がかわるボタン
- ブロックは自身に対する全てを"知って"いるべき
- 使用している言語全ての技術を用いて見栄えとふるまいを表現する これを多言語主義(multilingualism)と呼ぶ
- つまり、js, css, テンプレート、ドキュメントなど全ての総体をここではブロックと定義したい、という話のようだ