# SassとかScssだとか、CSSプリプロセッサでBEMるときのはまりどころ

- リンク: https://torounit.com/blog/scss%e3%81%a8%e3%81%8bcss%e3%83%97%e3%83%aa%e3%83%97%e3%83%ad%e3%82%bb%e3%83%83%e3%82%b5%e3%81%a7bem%e3%82%8b%e3%81%a8%e3%81%8d%e3%81%ae%e3%81%af%e3%81%be%e3%82%8a%e3%81%a9%e3%81%93%e3%82%8d/
- 公開日: 2014-04-23T09:30:39+09:00
- 作成者: Toro\_Unit

すっかりBEM道を邁進中の今日のこの頃ですが、ちょっとSCSSでやったときのはまりごと。

別に、[https://gist.github.com/juno/6182957](https://gist.github.com/juno/6182957)
でも言及されているとおり、全てのセレクタをBEMにする必要はないのですが、BEMってない
CSSを同時に使うには、ちょっと注意が必要です。

たとえば

    ```decode:true
    .hoge {

    	p {
    		margin: 1em;
    	}

    	&__piyo {
    		margin: 0;
    	}
    }
    ```

こんなやつ。

    ```decode:true
    .hoge {

    	p {
    		margin: 1em;
    	}

    	.piyo {
    		margin: 0;
    	}
    }
    ```

とCSSと書くのと、同じノリで書くと痛い目に見ます。
 NO BEM であれば、`.hoge p.piyo`
のmarginは0なのですが、 BEMった場合、`.hoge p`のほうが、BEMったセレクタの`.hoge__piyo`
より優先度が高くなってしまいます。結果、先ほどのpのmarginは1emとなります。なので、
BEMなCSSを書くのを結構強制されがちです。

CSSのオーバーライドがしづらくなるわけですね。

WordPressやら、CMSの本文部分のCSSを書くときにちょっと面倒なコトになりそうです。

その代わり、破綻しにくいCSSを作りやすいかもしれません。
 SMACSSで言うところのbase
の設計が大変にはなったり、かといってbaseにごりごり書きすぎると、モジュール周りで
marginやらpaddingのリセットをいっぱい書く羽目になったり。

難しいですね。CSS。