<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="//images.ctfassets.net/jkycobgkkwnp/1Cv9mWDmGdDMsRXxN0APHM/49f657b2b89b9a9d19d18e0297656b06/css-rule-set.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_bar-Baz ([block]_[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>
<p>・スタイルを当てる要素にはできるだけclass又はIDを指定する</p>
</blockquote>
<blockquote>
<p>・子孫セレクタは重いのできるだけ減らす</p>
</blockquote>
<blockquote>
<p>という施策に一定の効果はあるようですが、その効果が如実に現れるのはHTML、CSSのコードが非常に大きいページに限られるようです。</p>
</blockquote>
<blockquote>
<p>そのなかでも、子孫セレクタを減らす施策よりも、スタイルを当てる要素にはできるだけclass名を指定する施策のほうが、効果があるようです。</p>
</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の記事一覧