<p>12/3（土）に<a href="https://builderscon.io/builderscon/tokyo/2016/session/720e29c6-9b11-46f3-adf4-f6f52e4fcbb9">CSS を破綻させない</a>という内容を<a href="https://builderscon.io/builderscon/tokyo/2016">builderscon tokyo 2016</a>で話しました。</p>
<p>そこで使った発表資料の内容を編集した上で、<a href="http://qiita.com/advent-calendar/2016/css">CSS Advent Calendar 2016</a> 14 日目の記事として公開します。</p>
<h2 id="css-は破綻しやすい">CSS は破綻しやすい</h2>
<p>OOCSS の提唱者 Nicole Sulliban 氏も<a href="http://www.andoh.org/2009/11/web-directions-east-2009-nicole.html">&quot;CSS is too fragile&quot;</a>と 2008 年のイベントで言いました。
なぜ破綻しやすいのか。それは CSS の特性が絡んでいます。</p>
<h2 id="css-の特性">CSS の特性</h2>
<p>CSS の特性としておもに 3 つあります。</p>
<p>はじめに、記述を間違えてもエラーにならないことです。ブラウザで表示確認をおこなって初めて見た目がおかしいことに気づきます。</p>
<p>次に、スタイルが適用される条件としてルールセットを書く順序は関係ありますが、常に関係があるわけではない点です。</p>
<p>ちなみにルールセットは CSS のセレクタ・プロパティ・値の定義をまとめたものです。
分かりやすい図として<a href="http://terkel.jp/archives/2011/09/css-rule-structure/">CSS ルールセット構造図 · terkel.jp</a>内の画像があるので引用します。</p>
<p><img src="//res.cloudinary.com/kubosho/image/upload/v1589722422/css-rule-set_kogfng.png" alt="CSSのルールセットの図"></p>
<p>最後に、ルールセット間で同じプロパティが定義されている場合、順序・詳細度・重要度にもとづいて適用されるスタイルが決定されます。CSS をややこしくしているのはここですが、意識して書かないと容易に破綻します。</p>
<p>ここからは実際に CSS が破綻した例を見ていきます。</p>
<h2 id="css-の破綻">CSS の破綻</h2>
<p>CSS の破綻はいくつか種類があります。これらの要素のうち 2 つ以上が複合して起きていると手がつけられない CSS になります。</p>
<h3 id="スタイルの上書きが複数ある">スタイルの上書きが複数ある</h3>
<p>スタイルの上書きは Bootstrap など CSS フレームワークを使うときに独自の見た目を実現しようとすると起こりがちな問題です。
スタイルの上書きが多くなるとどんな見た目になるのか予測できなくなり破綻します。</p>
<pre><code class="language-css">.button {
  border: 1px solid #ccc;
}

/* ...長いコードの後や別ファイルなど... */

.button {
  border: 1px solid #666;
}

/* ...長いコードの後や別ファイルなど... */

.article .button {
  border: 1px solid #00c;
}</code></pre>
<h3 id="前に書いたセレクタの詳細度が高い">前に書いたセレクタの詳細度が高い</h3>
<p>前に書いたセレクタの詳細度が高くてスタイルが上書きできないことも破綻の一因になります。
先ほどのスタイルの上書きを多くしていると起こりがちな問題です。
これがもたらす結果としては <code>!important</code> の濫用です。</p>
<pre><code class="language-css">/* 詳細度はa=0, b=4, c=0なので0.4.0となる */
.container .form .form-group .form-submit-button {
}

/*
  詳細度はa=0, b=1, c=0なので0.1.0となる
  上書きできない。つらい
*/
.form__submit-button {
}</code></pre>
<h3 id="命名規則がバラバラ">命名規則がバラバラ</h3>
<p>よくあることとして単語の区切りがケバブケース・キャメルケース・スネークケースのようにバラけていると、どの規則に合わせればいいのか分からずいつまでも命名規則が統一されません。</p>
<pre><code class="language-css">.account-login-button {
}

.commentSubmitButton {
}

.form_submit_button {
}</code></pre>
<h2 id="css-の破綻-まとめ">CSS の破綻 まとめ</h2>
<p>ここまで CSS が破綻する理由について書きました。まとめると次のとおりです。</p>
<ul>
<li>詳細度が管理されていない</li>
<li>ルールセットの分割粒度が明確ではない</li>
<li>命名規則が決まっていない</li>
</ul>
<h2 id="css-を破綻させない">CSS を破綻させない</h2>
<p>ここからは CSS を破綻させないためにはどうすればいいのかを書いていきます。</p>
<h3 id="詳細度を管理する">詳細度を管理する</h3>
<p>CSS などのファイルを分割するときはファイル内で下へ行くにつれて詳細度が高くなるようにします。またセレクタ定義や ID セレクタを書きすぎないようにするのも重要です。</p>
<p>例を挙げるとフォーム共通のスタイルを適用するときにセレクタを定義しすぎないことです。
これにより少ないセレクタ定義で適用したスタイルを上書きできて秩序が保つことができます。</p>
<pre><code class="language-css">/* 詳細度はa=0, b=2, c=0なので0.2.0となる */
.form .form-button {
  margin: 0;
}

/* ... */

/*
  詳細度はa=0, b=2, c=0なので0.2.0となる
  記述の順序が後なので値が上書きされる
*/
.comment-form .form-button {
  /* 上書きできる */
  margin: 10px auto;
}</code></pre>
<h3 id="ルールセットの分割粒度を明確にする">ルールセットの分割粒度を明確にする</h3>
<p>スタイルの上書きを減らすためにルールセットの分割粒度を明確にすることも重要です。
これはさまざまな方法が提案されていて、たとえば<a href="https://github.com/hiloki/flocss">FLOCSS</a>や<a href="https://smacss.com/">SMACSS</a>、<a href="http://ecss.io/">ECSS</a>などがあります。</p>
<p>これは作るものによって適しているものが違うため一概にどれがいいか言えません。
スタイルを適用したいときにルールセットをどこに置けばいいのかチーム内で迷わないようにするのが重要です。</p>
<h3 id="命名規則を決める">命名規則を決める</h3>
<p>命名規則も<a href="http://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/">MindBEMding</a>や<a href="http://ecss.io/chapter5.html#h-H2_1">ECSS</a>、<a href="https://smacss.com/book/categorizing">SMACSS</a>などさまざまなものがあります。これもチーム内で使う命名規則を一致させることが重要です。</p>
<h2 id="css-を破綻させない-まとめ">CSS を破綻させない まとめ</h2>
<p>ここまで CSS の破綻を起こさないためにどうしたらいいか書きました。まとめると次のとおりです。</p>
<ul>
<li>詳細度を管理する</li>
<li>チーム内でルールセットの分割粒度を明確にする</li>
<li>チーム内で命名規則を決める</li>
</ul>
<p>しかしこれらを実践する前により大事なことが 1 つあります。
それは<strong>デザイナーとの認識合わせ</strong>です。</p>
<p>これは<a href="http://morishitter.hatenablog.com/entry/2016/07/29/204642">デザインの意図を正確に理解した上で書かれた CSS は破綻しない</a>という言葉があります。</p>
<p>デザイナーが作った Sketch や Photoshop のファイルを見て質問や提案をおこない、デザイナーと UI を実装する人で意図の認識を合わせることが重要です。
もっと言うなら Sketch や Photoshop などで作る以前のプロトタイピングの段階から関わるとお互い意図の認識がしやすくなると思います。
プロトタイピングツールは<a href="https://www.invisionapp.com/">InVision</a>が代表的です。</p>
<p>これを踏まえてまとめると、<strong>チームで議論して良い CSS 設計を考えよう</strong>になります。</p>
<h2 id="css-がすでに破綻している場合は？">CSS がすでに破綻している場合は？</h2>
<p>builderscon の Q&amp;A で「途中から入ったプロジェクトの CSS が破綻していた場合どう改善したらいいのか？」というのがあったのですが、今のところチームで話し合って設計指針を決めて 1 から書き直すしかないと考えています。</p>
<h2 id="参考資料">参考資料</h2>
<ul>
<li><a href="http://dskd.jp/archives/54.html">僕は CSS を見殺しにした - dskd</a></li>
<li><a href="https://app.codegrid.net/entry/2016-ecss-1">Enduring CSS の設計思想 - ECSS が目指す設計 | CodeGrid</a></li>
<li><a href="https://app.codegrid.net/entry/smacss-1">SMACSS による CSS の設計 - ベースとレイアウト | CodeGrid</a></li>
<li><a href="http://qiita.com/BYODKM/items/b8f545453f656270212a">破綻しにくい CSS 設計の法則 15 - Qiita</a></li>
<li><a href="http://qiita.com/BYODKM/items/8c777db2d89f4e830c93">CSS が破綻する 4 つの理由 - Qiita</a></li>
</ul>


CSSを破綻させない

<p>CSS は、書くのが怖いと自分は感じます。</p>
<p>例えば、ある程度運用したサービスやアプリとなると、自分が変更した点が思いもよらぬところに反映されてしまい「しまった」と思った事はあると思います。</p>
<p>とはいえ、運用していく上で、何も変更しないというのはありえません。なので、そういった恐怖からなるべく解放されるために自分が心がけている事を書いていきます。</p>
<h2 id="コメントを書く">コメントを書く</h2>
<p>自分の場合は、そのセレクタがどこで使われているかという情報を書く事が非常に多いです。例としては以下のような感じです。</p>
<pre><code class="language-sass">//------------------------------------------------------------------------
//    Common: サイト上部のヘッダー
//------------------------------------------------------------------------
.prefix-global-header {
  background: #000;
}</code></pre>
<p>このようにする事で区切りが分かりやすくなると思っています。また、ルールセットがどう書かれているかが、より頭の中に入ってくると自分は感じています。</p>
<p>ちなみに上記の区切りは、Sass や LESS でしか使えない(コメントアウトに <code>//</code> を使っているため)ので、CSS でも区切りを付けたい場合は、<a href="https://github.com/csswizardry/inuit.css">inuit.css</a>の以下の区切りが良いなと自分は感じています。</p>
<pre><code class="language-css">/*------------------------------------*\
    はうはう
\*------------------------------------*/</code></pre>
<h2 id="class-名や-id-名を意味のある名前にする">class 名や id 名を意味のある名前にする</h2>
<p>極端な例ですが、以下のように「要素名をそのまま繰り返しただけの class 名」というのは意味が無いと思います(以下の例では、いっそ要素型セレクタでスタイル指定したほうがいいのではと思います)。</p>
<p><a class="jsbin-embed" href="http://jsbin.com/vibejoqaka/4/embed?html,css,output">JS Bin</a><script src="http://static.jsbin.com/js/embed.js"></script></p>
<p>では、自分はどのように名付けるかという話ですが、今は<a href="http://blog.kubosho.com/entry/2014/12/09/valhalla-gate-css-architecture">神獄のヴァルハラゲートの CSS 設計</a>でも書いたように、MindBEMding を使った命名にするかなという感じです。</p>
<p>例えば <code>.header</code> としているところなら、<code>.prefix-global-header</code> になるかもしれないですし <code>.prefix-top-header</code> になるかもしれません。</p>
<h2 id="important-を使う時は注意深く使う"><code>!important</code> を使う時は注意深く使う</h2>
<p>CSS を書いていく上で、どうしても <code>!important</code> を使いたくなる時があると思います。そんな時は <code>!important</code> を使わないように CSS を書き直すよりも <code>!important</code> を使ったほうが、時間がかからなかったり複雑にならない可能性が高いと感じています。</p>
<p>とはいえ、<code>!important</code> は乱用するものではありません。改修に時間がかからなそうだったり複雑にならなそうであれば、使わないほうが良いです。</p>
<p>なお自分が <code>!important</code> を使う時は、なぜ <code>!important</code> を使うのかというコメントを絶対書いています。それは以下の理由です。</p>
<ul>
<li>意味が書いてない <code>!important</code> は消すのが怖いため<ul>
<li>消したらどこかに悪影響が出るのではという恐怖が生まれる</li>
</ul>
</li>
<li>将来 CSS を書き直した時に消せるようになるかもしれないため<ul>
<li>上記でも書いたように、なるべく使わないようにしたい</li>
</ul>
</li>
</ul>
<h2 id="style-属性を使う時は注意深く使う">style 属性を使う時は注意深く使う</h2>
<p><code>!important</code> と同じく、乱用すべきものではないですが、かといって、ある機能に関するページが 10 ページくらいあったとして、そのうち 1 ページでしか使わない(かつスタイルを適用させたいところも少ない)となると、CSS ファイル内でスタイル指定をするよりも、style 属性でスタイル指定をしたほうが、時間がかからなかったり複雑にならない可能性が高いと感じています。</p>
<p>それ以外では、style 属性を使わないほうが良いと思います。</p>
<h2 id="最後に">最後に</h2>
<p>ここまで、CSS を書く際に心がけている事を書いてきましたが、こういう心がけは以下の思いから心がけようとしています。</p>
<p><a href="https://twitter.com/kubosho_/status/569730148536164352">ドキュメント残しておかないと、身軽になれないし、あとは気をつけていても病気とか事故にあって長期離脱という可能性は 0 ではないので、そうなった時に引き継いだ人が積むし、自分への恨みが起こると思うので、ドキュメントは出来るだけ残しておきたいと自分は考えている。</a></p>


編集しやすいCSSにするために自分が心がけている事

<p><a href="http://www.adventar.org/calendars/337">CSS Architecture Advent Calendar 2014</a> 9 日目の記事になります。</p>
<p><a href="http://grani.jp/product/valhalla-gate/">神獄のヴァルハラゲート</a>の CSS 設計方法について振り返りつつ、こうしているということや、上手くいったところ、改善したいところを書いていこうと思います。</p>
<h2 id="アプリの規模">アプリの規模</h2>
<p>ASP.NET MVC を使っていて、View 側は Razor テンプレートを使っているのですが、Razor のファイルを検索してみると以下の量となります。</p>
<pre><code class="language-zsh">find ./ -name &quot;*.cshtml&quot; | wc -l
    1674</code></pre>
<p>実際には、これにフィーチャーフォン向けのファイルや、部分的な View ファイルも含まれています。</p>
<p>なので、実際 CSS を適用しているファイルの量は、この検索結果よりは格段に減りますが、それでも、約 600 ファイルはあると思います。</p>
<p>ちなみに、今年のはじめに同僚の<a href="https://twitter.com/mayuki">@mayuki</a>が、<a href="https://speakerdeck.com/mayuki/sosiyarugemufalsehurontoendotoasp-dot-net-mvc-lite">ソーシャルゲームのフロントエンドと ASP.NET MVC (Lite)</a>というタイトルで、<a href="http://partake.in/events/a531c0be-e8dd-46fe-a73c-e51d8ad7a69b">めとべや東京#3 (Room metro Tokyo #3)</a>にて発表したのですが、そこには「View 数は 400 超」と書いてあるので、1 年間の運用で約 200 ファイル増えたことになります。</p>
<h2 id="対応端末、ブラウザー">対応端末、ブラウザー</h2>
<p>スマートフォンでは、以下の環境でアクセスされることを想定して対応しています。</p>
<h3 id="os">OS</h3>
<ul>
<li>iOS 6 or later</li>
<li>Android 2.3.x<ul>
<li>重要な機能だったら、Android 2.2.x にも対応することも…</li>
</ul>
</li>
<li>Android 4.0 or later</li>
</ul>
<h3 id="ブラウザー">ブラウザー</h3>
<ul>
<li>iOS<ul>
<li>Safari</li>
<li>WebView</li>
</ul>
</li>
<li>Android<ul>
<li>Android Browser</li>
<li>Google Chrome</li>
<li><a href="https://gist.github.com/uupaa/b25c9cf47bbeedea5a7f">S Browser</a></li>
</ul>
</li>
</ul>
<p>iOS 6 や Android 2 系はそろそろ対応端末から外したいなと思っています。来年の今頃は対応しなくて良くなってたらいいですね。</p>
<h2 id="命名規則">命名規則</h2>
<p><a href="https://en.bem.info/method/naming-convention/">BEM</a>を採用しています。ただし、セレクタの命名規則は以下のように変えています。</p>
<pre><code class="language-css">[prefix]-[block]_[element]-[[Modifier-Key]-[Modifiler-Value]] {
  // property: value;
}</code></pre>
<p><a href="http://geckotang.tumblr.com/post/104065014321/css">今年のネーミングルール #CSS 設計 - &lt; /gecko &gt;</a>とだいたい同じですが、以下の点が異なります。</p>
<ul>
<li>Block と Element の区切り文字は「_(アンダースコア)」</li>
<li>複数の単語を連結する場合は「-(ハイフン)」を使う</li>
<li>Modifier は CamelCase を使う。例は以下の通り<ul>
<li>foo-Bar-Baz ([block]-[Modifier-Key]-[Modifier-Value])</li>
<li>foo<em>bar-Baz ([block]</em>[element]-[Modifier-Value])</li>
</ul>
</li>
<li>prefix は、共通で使うルールセットはプロジェクトのコードネーム、各機能のみで使うルールセットはその機能名を使う<ul>
<li>ガチャなら prefix は<code>gacha</code>という感じ</li>
</ul>
</li>
</ul>
<p>あとは、<a href="https://github.com/hiloki/flocss#mindbemding">hiloki/flocss</a>の MindBEMding の章にあるように、JavaScript で操作されるような「状態」を表すような Modifier については、SMACSS の State パターンの命名のように、<code>is-*</code>プレフィックスを付けて<code>.is-active</code>という感じにしています。</p>
<p><code>.is-active</code>には直接スタイル指定をすることを禁止しています。</p>
<pre><code class="language-sass">// これはOK
.block_element.is-active {
  display: block;
}

// これはNG
.is-active {
  display: block;
}
</code></pre>
<h3 id="良いところ">良いところ</h3>
<ul>
<li><code>--</code>や<code>__</code>という区切り文字より、セレクタ名が醜くならない(個人の主観です)</li>
</ul>
<p>あとは構造が分かりやすいだったり、class 名が衝突するということが少ないという、BEM や MindBEMding を採用した人ならだいたい感じることでしょうか。</p>
<h3 id="改善したいところ">改善したいところ</h3>
<ul>
<li>prefix のところで世代管理をしなかったのは間違いだった<ul>
<li><a href="http://geckotang.tumblr.com/post/104065014321/css">今年のネーミングルール #CSS 設計 - &lt; /gecko &gt;</a>を読んで気づいた…</li>
<li>古いセレクタ名と、上記の命名規則を適用したセレクタ名が混ざっていて、辛くなることがある</li>
</ul>
</li>
<li>Modifier を使っている class 名で、Modifier-Key がない class 名というのは、分かりにくいのではと思った<ul>
<li>この章を書いて気づいた…</li>
</ul>
</li>
</ul>
<h2 id="ディレクトリ構成">ディレクトリ構成</h2>
<p><a href="https://github.com/hiloki/flocss">hiloki/flocss</a> に基本は準拠しています。「基本は」と書いたのは以下のディレクトリ名を自分の好みで変えているからです。</p>
<ul>
<li>foundation -&gt; base</li>
<li>object/project -&gt; object/page</li>
</ul>
<h2 id="使っている-css-プリプロセッサーやライブラリー">使っている CSS プリプロセッサーやライブラリー</h2>
<ul>
<li>LESS</li>
<li>Normalize.css</li>
</ul>
<p>LESS な理由ですが、<a href="https://speakerdeck.com/mayuki/sosiyarugemufalsehurontoendotoasp-dot-net-mvc-lite?slide=7">ソーシャルゲームのフロントエンドと ASP.NET MVC (Lite)</a>の 7 ページにも書いてあるように、Visual Studio との相性が良かった(新規ファイル作成時に*.less 形式でのみファイルが作れた)ことが要因です。</p>
<p>とはいえ、MSDN Blogs の<a href="http://blogs.msdn.com/b/webdev/archive/2014/02/25/announcing-new-web-features-in-visual-studio-2013-update-2-ctp2.aspx">Announcing new Web Features in Visual Studio 2013 Update 2 CTP2</a>にも書かれているように、Visual Studio 2013 Update 2(ちなみに今は Update 4 が最新)から公式に Sass(*.scss 形式)のファイルも新規作成できるようになったので、Visual Studio ユーザーでも好みで LESS か Sass かを選べるようになったと言えます。</p>
<p>ライブラリーは Normalize.css くらいしか使っていないです。これはやはり同僚の@mayuki が入社したての頃に、汎用 class をゴリッと書いてくれたので、ライブラリーを使う理由があまり無くなったという感じです。</p>
<h2 id="css-プリプロセッサーの機能について">CSS プリプロセッサーの機能について</h2>
<h3 id="extend">extend</h3>
<p><a href="https://github.com/hiloki/flocss#css%E3%83%97%E3%83%AA%E3%83%97%E3%83%AD%E3%82%BB%E3%83%83%E3%82%B5%E3%81%AEextend">CSS プリプロセッサの Extend - hiloki/flocss</a>に書かれているように、モジュールで完結する extend は許容し、それ以外は禁止しています。むやみに extend を多用すると、どこにそのルールセットが書かれているか分からなくなり破綻する、というのが大きな理由です。</p>
<h3 id="ルールセットの入れ子">ルールセットの入れ子</h3>
<p>CSS プリプロセッサーのほとんど(全て？)はルールセットの入れ子がおこなえますが、入れ子の深さは二段階までと定めています。具体例としては以下のコードです。</p>
<pre><code class="language-sass">.foo {
    border: 1px solid #003760;
    color: #000;
    background: rgba(0, 0, 0, 0.5);

    .nest-01 {
        font-weight: bold;

        .nest-02 {
            color: #f00;
        }
    }
}</code></pre>
<p>なぜ、二段階までに抑えているのかというと、制限がなかった場合、出力後の CSS のセレクタ部分がとても長くなってしまう可能性があるということが挙げられます。</p>
<p>具体例を書くと、以下のような LESS のコードがあったとします。</p>
<pre><code class="language-sass">// Uuuugly!
.foo {
    .nest-01 {
        .nest-02 {
            .nest-03 {
                .nest-04 {
                    .nest-05 {
                        color: #333;
                    }
                }
            }
        }
    }
}</code></pre>
<p>上記のコードを CSS にコンパイルした場合、以下のようになるでしょう。非常に長くて醜いです。</p>
<pre><code class="language-css">.foo .nest-01 .nest-02 .nest-03 .nest-04 .nest-05 {
  color: #333;
}</code></pre>
<p>また、実際に挙動を確かめられていないですが、多くのサイトで「ブラウザーのセレクターの解釈として、右から左に解釈される」と書かれています。</p>
<p>とすると、上記の CSS は「.nest-05 -&gt; .nest-04 -&gt; .nest-03 -&gt; .nest-02 -&gt; .nest-01 -&gt; .foo」と解釈されることになります。「.nest-01 -&gt; .foo」という構造よりも解釈に時間がかかりそうです。</p>
<p>ちなみに、古い記事(2011 年)ですが、<a href="http://developers.linecorp.com/blog/?p=178">CSS セレクタによる高速化、実際のところ « LINE Engineers&#39; Blog</a>に実際の計測結果が掲載されており、そこには以下のように書かれています。</p>
<blockquote>
・スタイルを当てる要素にはできるだけclass又はIDを指定する<br>
・子孫セレクタは重いのできるだけ減らす<br>
という施策に一定の効果はあるようですが、その効果が如実に現れるのはHTML、CSSのコードが非常に大きいページに限られるようです。<br>
そのなかでも、子孫セレクタを減らす施策よりも、スタイルを当てる要素にはできるだけclass名を指定する施策のほうが、効果があるようです。
</blockquote>

<p>ということで、MindBEMding の考え方を適用し、ある Block の中でスタイルを当てたい要素には、.block_element だったり、.block_element-Key-Value という感じで class 名を指定し、スタイルを適用しています。</p>
<h2 id="まとめ">まとめ</h2>
<p>ソーシャルゲームというのは、最初から機能が数十種類あったり、View のファイル数が数百ファイルを超えるということは珍しくないと思います。</p>
<p>そんな中で、CSS を書く上での指針がないと、時間が経つにつれ運用が苦痛になってきます。</p>
<p>例えば新しい人が入ってきたり、自分に何かあって他の人が一時的にプロジェクトに入ってきた場合、CSS を書く上での指針が無いと、どのように CSS を書いていけばいいのか、理解に時間がかかることになります。</p>
<p>なので、CSS を書く上での指針を定め、かつ、それを GitHub の Wiki など、プロジェクトのメンバーが目に入る場所に残しておくのが重要と、自分は考えています。</p>
<p>明日は、<a href="http://www.adventar.org/users/9">越智</a>さんです。</p>
<h2 id="記事内で紹介した-github-のリポジトリや記事">記事内で紹介した GitHub のリポジトリや記事</h2>
<ul>
<li><a href="https://github.com/hiloki/flocss">hiloki/flocss</a></li>
<li><a href="https://speakerdeck.com/mayuki/sosiyarugemufalsehurontoendotoasp-dot-net-mvc-lite">ソーシャルゲームのフロントエンドと ASP.NET MVC (Lite)</a></li>
<li><a href="http://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/">MindBEMding – getting your head ’round BEM syntax – CSS Wizardry – CSS, OOCSS, front-end architecture, performance and more, by Harry Roberts</a></li>
<li><a href="http://blogs.msdn.com/b/webdev/archive/2014/02/25/announcing-new-web-features-in-visual-studio-2013-update-2-ctp2.aspx">Announcing new Web Features in Visual Studio 2013 Update 2 CTP2 - .NET Web Development and Tools Blog - Site Home - MSDN Blogs</a></li>
<li><a href="http://developers.linecorp.com/blog/?p=178">CSS セレクタによる高速化、実際のところ « LINE Engineers&#39; Blog</a></li>
</ul>


学ぶ、考える、書き出す。

CSSの記事一覧

CSSを破綻させない

編集しやすいCSSにするために自分が心がけている事

神獄のヴァルハラゲートのCSS設計