細かすぎるけど伝わってほしい私的BEMプラクティス30（ぐらい）

BEMのいいところは、それが何者なのかが明白ということに尽きる。とある要素を見たときに、そのスタイルがどこに書かれているのか、何を表しているのかがクラス名を見ればわかる。手を入れる際も、どこに追記すればよいのか、どれくらいの影響を及ぼすのかの大部分が推測できる。 レスポンシブ・デザインと相性がいいとか、流行りのコンポーネント指向と相性がいいなど、BEMの良さは他にもいくつか挙げられるけど、決定的なのは明瞭さであると思う。 BEMを使いはじめてかれこれ３，４年くらい経った。その間に色々な命名規則や設計思想が登場してきたけれども、今のところは浮気する程の魅力を他に感じることもなくBEM一筋でやってきている。ただし実践するにつけて、より明瞭で破綻しづらい設計を実現するために、様々な制約やガイドを設けてやってきたので、「もともとのBEM」からは多少なり離れているかもしれない。 ただし、それはBEM

[securecat]

人のプラクティス読むの面白い

[masuP]

ほぼほぼ同じ。違うところは “ユーティリティクラスを許容しない”,"エレメント名に迷ったら __1 __2", "SCSSを使う", "@import はアルファベット順", "スタイルを当てる主体に注目する（ブロック内ブロック編）"

[itouhiro]

「BEMとはBlock、Element、Modifierの略語。HTMLのclass命名ルールでCSS設計」「CSSにはDRY原則をあてはめない。ブロックは３タイプ。モノを表す特徴的な単語を含めて名付け。１ブロック１SCSSファイル。５重くらいdivで囲んでいい」

[x-shinohara]

“HTML構造上の入れ子関係があっても、常にブロック直下のエレメントであるように書く。 ”

[oki448jp]

細かすぎるけど伝わってほしい私的BEMプラクティス30（ぐらい）

[bundai223]

BEM 旧ブログからのリンクで飛んできたが旧ブログのBEM記事と言っていることが変わっている部分があるので注意。

[ginpei]

たしか信頼できる人たちが良いと言っていたので良いもののはずだ。

[tsuki-rs]

共感できる部分もあるけど、仲良くなれないかも。

[yoruaki]

“スタイルを当てる主体に注目する”同意。

[toblog]

キャメルケース避けてハイフン使ってたんだけど次から使おうかな。やっぱキャメルケースが分かりやすいよね。

[efcl]

Sass + BEMのプラクティス

[l-_-ll]

Block, Element, Modifier

[H7kayama]

BEMを初めて知りました

[wdr_s]

参考になる。細かいところは違うけど、みんな似たようなところに行き着いている気がする。

[pykgg476]

“@at-root”

[nunulk]

む、なるほど… / "&__element の書き方をしない"

[kanflu]

「ハイフン始まりのモディファイア」を使うとセレクタの詳細度が上がってしまうのでは。

[neotag]

"ユーティリティクラスを許容しない" だけが踏ん切りつかないが、ほかは全部首が外れるほど同意した。 / 最近は PostCSS だった。

[sakaki0214]

ふむふむ

[anton072]

他人のルールに乗っかる主義

[sigwyg]

概ね同意。一点付け加えるなら、比較的変更が面倒なHTMLにこそ拘るべき

[o_ti]

最高だぜ〜〜

[winterfall]

いろんな箇所で参考になります。取り入れていきたい

[hinashiki]

参考程度に。

[sumithsonian]

現場感あって、いいプラクティス。

[sho_yamane]

勉強になった

[edamame55]

ハイフンをあまり使いたくないので参考になります。

[RATCHO]

プロジェクトメンバーのために

[nibushibu]

このモディファイアの書き方いいな

[hirorock]

bem