2016/3月現在の個人的（あるいはテンマド社の）CSS/SCSSコーディングについてのルール

# 目指すこと

* 開発時に「迷う」「考える」部分を極力減らしつつ、できるだけ一貫したCSSを書けるようにする
* 必要最小限のルールセットで、最大限の効果
* 覚えるべきことを必要最小限にする

# 前提

# ルール
### ◎ SASSではなく、SCSSの記法を使う

## 前提
SASSの記法（HAMLっぽいやつ）は使わず、SCSS（よりCSSっぽい記法）のほうを使います。

### SASSではなく、SCSSの記法を使う
単純に学習コストが低いことと、
JSライブラリ付属のCSSやネットで公開されているコードなどを取り込む時もコピペでとり込んだりしやすいからです。

単純に学習コストが低く、JSライブラリ付属のCSSなど、既存のCSSなどもコピペで貼り付ければ済むので、取り込みやすいからです
# 命名規則

## 命名規則
## ◎ IDを使用しない

### IDを使用しない
```scss:BAD  
#main {
  color:red;
}
#main ul{
  color:green;
}
```
```scss:GOOD 
.main{
  color:red;
}
.main-list{
  color:green;
}
```
ID指定でスタイルを書くことはしません。
IDは詳細度（selector's specificity）が高すぎて、他の場所でカスケードしてスタイルを上書きしようとした時`!important`を多発しなくてはいけなくなったり、あれこれと障害になるためです。

他の場所でカスケードしてスタイルを上書きしようとした時に障害になるので、IDは一切使用しません。
## ◎ 初期化/リセット的なことをする部分以外で、タグに対してスタイルを当てない

### 初期化/リセット的なことをする部分以外で、タグに対してスタイル当てない

```scss:BAD  
.some-class ul{
  color:red;
}
ul.some-class li{
  color:red;
}
```
```scss:GOOD 
.some-class-items{
.some-class-list{
  color:red;
}
some-class-list-item{
  color:red;
}
```

面倒でも全部クラスを割り振ります。
例外として、たとえばMarkdownパーサが出力するHTMLなど、クラスの割り当てられない部分で、かつタグにスタイルを指定するのが妥当な部分は除きます。
タグ名でスタイル指定はせず、面倒でも全部クラスを割り振ります。

タグの構造は制作していく中で「あ、やっぱりこっちのがいいかも」って変えることがよくあるので、その際に書き換えが発生しにくくするためです
タグの構造は制作していく途中や、JSとの兼ね合いで変えることがよくあるので、その際に書き換える手間を減らし、HTML構造とCSSによるスタイリングを極力分離しておくためです。

### クラス名はハイフン区切りで全て小文字
例外として、たとえばMarkdownパーサが出力するHTMLなど、クラスの割り当てられない部分で、かつタグにスタイルを指定するのが妥当な部分は除きます。

大文字小文字を両方使って書く前提にすると、必ず大文字小文字のタイプミスでスタイルが当たらなくてうんうん悩む時間が発生するので、大文字は一切使いません。
## ◎ クラス名はハイフン区切りで全て小文字

### JSから使うクラスは「.x-」で始め、CSS側でそのクラスは絶対に使わない
```scss:BAD  
.snakecase_class{
  color:red;
}
.camelCaseClass{
  color:red;
}
.Capital-CLASS{
  color:red;
}
```
```scss:GOOD 
.good-class-definition{
  color:red;
}
```

JSで使っているクラスなので変更に注意が必要、ということを明示するために特別なクラスを指定します。
また、JSでのDOM操作と、CSSでのスタイル指定はできるかぎり切り離しておいたほうがよいので、「.x-」のついたクラスに対してスタイルを当てることは絶対にしないようにします。
後述の「.mode-」のついたクラスでコントロールします。
大文字小文字を両方使って書く前提にすると、必ず大文字小文字のタイプミスでスタイルが当たらなくてうんうん悩む時間が発生するので、基本的に大文字は一切使いません。

## JSで使うIDは「x」で始め、CSS側でそのIDは絶対に使わない
例外として、Angularのアプリを書いていてdirective名とCSSの接頭辞を合わせたい、などの理由で接頭辞のみcamelCaseを使ったりするのはアリです。

っていうかIDをそもそもCSSで書かないので関係ないといえばない。
## ◎ クラスのネストは２段階まで、を基本とする

### JSとのやりとりは「.mode-」というクラスで行う
* `.g-`で始まる「グローバルなクラス」
* 同一ファイル内にある、同じ接頭辞のクラス

のみネストして上書きできます。

# ファイル分け

## クラスのネストは２段階まで、を基本とする
## ◎ 基本的なディレクトリ構造

## ファイル分け
## ◎ クラス名の接頭辞と、そのクラスの書かれたファイル名を一致させる

### クラス名の接頭辞と、そのクラスの書かれたファイル名を一致させる

どのクラスがどのファイルに書かれているか、が瞬時にわかるようになります。
sourcemapなどに頼る必要が発生したら負けです。

なお、「_x.scss（あるいは_x-hoge.scss）」と「_mode.scss（あるいは_mode-hoge.scss）」は上述のJSとのやりとりで使う予約語的なものなので、作成禁止です。
なお、

* `_x.scss`（あるいは_x-hoge.scss）
* `_mode.scss`（あるいは_mode-hoge.scss）

### SASSの変数名はスネークケースで書く
は後述のJavascriptとの連携に関わる予約語的なものなので、作成禁止です。

単純に、SASSだと「-」（マイナス）が演算子としても機能するので、それとの区別をつけてるため、ハイフンは使いません。
## ◎ ファイルが大きくなった場合は、接頭辞の前の部分をベースにディレクトリ化する

### SASSの変数名も、ファイル名と一致させる

# Javascriptとの連携

## ◎ JSから使うクラスは「.x-」で始め、CSS側でそのクラスは絶対に使わない

JSで使っているクラスなので変更に注意が必要、ということを明示するために特別なクラスを指定します。
また、JSでのDOM操作と、CSSでのスタイル指定はできるかぎり切り離しておいたほうがよいので、「.x-」のついたクラスに対してスタイルを当てることは絶対にしないようにします。
後述の「.mode-」のついたクラスでコントロールします。

## ◎ JSで使うIDは「x」で始めたcamelCaseとし、CSS側でそのIDは絶対に使わない

jsでのDOM操作のためにIDを割り当てる場合は`id="xSomeElement"`というようにxから始まるcamelCaseで指定します。
CSS側ではこのIDに対してスタイルを当てるようなことはしてはいけません。

## ◎ JSとCSSで連携する場合は`.mode-`というクラスを通して行う

要素のアニメーションなどはできる限りCSSのtransitionやanimationで行います。

その際、JS側では`.mode-`と頭についたクラスの追加と削除のみを行い、CSS側ではその`.mode-`と頭についたクラスを使ってアニメーション


# SASS

## ◎ SASSの変数名はスネークケースで書く

SASSだと「-」が演算子としても機能するので、それとの区別をつけるため、ハイフンは使いません。

## ◎ SASSの変数名も、ファイル名と一致させる

唯一の例外として、下記のとおり「$g_」で始まるものだけルールが違います

### SASSのグローバル変数は「_vars.scss」に書き、「$g_」で始める
## ◎ SASSのグローバル変数は「_vars.scss」に書き、「$g_」で始める


## ◎ レスポンシブ対応をmixinで行う

## レスポンシブ対応

今のところ以下のようなコードでやる方向です。

```scss:_mixins.scss
```

※もっとスマートにわかりやすく書ける方法があれば知りたい

# その他
## ◎ `@extend`は出来る限り避ける

## BEMなどを使わない理由
`@extend`は、extend元のスタイルを変更した時に影響する範囲が見えず、意図しない不具合が発生しがちなのでできる限り避けます。

ルールとして過剰に複雑なことと
モジュールのつもりで書いていたものの中のパーツをモジュール化したくなったり、
代わりに、

* 同じスタイルならできるだけ同じクラス名を割り振る
* 似たスタイルならクラスを複数振って上書きして調整する
* extendsしたいようなクラスは`.g-`のクラスとして定義して、ネストさせる

のを推奨です。

`@extend`を活用したSASSライブラリなどを使う場合は除きます。

# その他

## BEMなどを使わない理由

BEMは、画面設計がしっかりできていて、CSSの設計に時間がかけられる場合はよいですが、だいたい自分の作るようなものは日々変化の多いものなので、

* ルールとしてやや複雑すぎる
* っていうかどれがBlockでどれがElementでどれがModifierだとかあれこれ余計な事を考えたくない
* 一つのモジュールのつもりで書いていたものの中のパーツをモジュールとして切り出したくなるとかいった変更をしたくなった時にストレス

といった理由で採用していません。