Twitter のトレンドを見ると、イラつきを覚えるようになりました。そんなにイラつきを覚えるようなら見なければいいし、そもそも Twitter やめろという話はあります。 
ただ次のツイートにある通り、ある意味で期待通りの報酬を得られる行為で、正直なところ常習化していました。
<blockquote class="twitter-tweet">インターネットでQOLを1番下げる行為は、間違いなく「嫌いな人間/集団/コンテンツを自分から見に行って、嫌なものを見つけて、嫌なのを確認する」事なんだけど、これはある意味で「期待通りの報酬を得られる」行為なので、常習化を招きやすいんだよな。人生には得てはいけない成功体験があるというな。&mdash; rei@生きてるだけで疲労困憊発売延期 (@rei10830349) <a href="https://twitter.com/rei10830349/status/1178553747770753025?ref_src=twsrc%5Etfw">September 30, 2019</a></blockquote>
そのため Twitter のトレンドを見てしまうことが多く、トレンドを見るたびに後悔していました。
<h2>Twitter のトレンドが目に入ってくる</h2>
Twitter のページを見ると自然とトレンドが目に入ってきます。 
普段見ている Twitter の画面は次の通りだと思います。
<img width="800" height="751" src="https://blog-assets.kubosho.com/twitter_home_before.png" alt="CSSを調整する前のTwitterは3カラムになっている" loading="lazy">
左サイドバーにナビゲーションがあって、中央にツイート一覧、そして右サイドバーに Twitter 内の回遊リンク一覧がある構成になっています。
この構成だと右サイドバーの Twitter 内の回遊リンク一覧が目に入ります。 
特にいまどうしてる？というタイトルが付けられた Twitter 内のトレンド一覧が目に入ります。
これは Twitter 側で、トレンドを見てもらうことで Twitter 内を回遊してくれて、結果として追っている KPI を達成できる確率が高まるというデータがあるのでしょう。 
なので一番目に入る位置にトレンドがありますし、トレンドの先頭は広告枠になっているのだと思います。
<h2>Twitter のトレンドを視界から消す</h2>
そんな Twitter のトレンドを視界から消すために、<a href="https://chrome.google.com/webstore/detail/stylus/clngdbkpkpeebahjckkjfobafhncgmne?hl=ja">Stylus</a>を使って、Twitter 側で定義されている CSS を上書きし、Twitter のトレンドを非表示にしました。
<h3>トレンドを削除するときの課題</h3>
Twitter では次のツイートにある通り、React Native for Web を使っています。
<blockquote class="twitter-tweet">If you use Twitter Lite you&#39;re now using a web app rendered by React Native for Web&mdash; Nicolas (@necolas) <a href="https://twitter.com/necolas/status/913877194199359488?ref_src=twsrc%5Etfw">September 29, 2017</a></blockquote>
これは今も変わってなさそうで、HTML に定義されているクラス名はランダムな文字列となっています。 
このためクラス名を元にスタイル定義をすると、将来の変更でスタイルが適用されなくなることが容易に想像できます。
<h4>解決策</h4>
そのため自分が書いた CSS を注入する際 <code>data-*</code> 属性のセレクタに対してスタイル定義をすれば、将来的に壊れにくくなりそうという考えを持ちました。 
それに従って書いた CSS は次の通りです。
<pre class="language-css"><code class="language-css">[data-testid='primaryColumn'] {
 max-width: 600px;
}

[data-testid='sidebarColumn'] {
 display: none;
}
</code></pre>
この CSS を適用した Twitter を見てみましょう。見事に今回の目的である右サイドバーを非表示にできています。
<img width="800" height="751" src="https://blog-assets.kubosho.com/twitter_home_after.png" alt="CSSを調整した後のTwitterは2カラム表示になっている。右サイドバーは非表示になっている" loading="lazy">
<h2>まとめ</h2>
本来なら Twitter を見ないようにしたり、アカウントを削除して何もかも見れなくしたりしたほうが手っ取り早いでしょう。
ただ他サービスのログインに使っていたり、DM でやり取りしている人がいたり、そもそも Twitter に割と依存しがちだったりとやめられない状況です。 
なので今回は妥協案として、右サイドバーを非表示にしました。
Twitter には有料機能でもいいので、トレンドなどを削除する機能を作ってほしいですが、それが叶うことはないでしょう……

Twitterの右サイドバーを非表示にする

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

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

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

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

.article .button {
 border: 1px solid #00c;
}
</code></pre>
<h3>前に書いたセレクタの詳細度が高い</h3>
前に書いたセレクタの詳細度が高くてスタイルが上書きできないことも破綻の一因になります。 
先ほどのスタイルの上書きを多くしていると起こりがちな問題です。 
これがもたらす結果としては <code>!important</code> の濫用です。
<pre class="language-css"><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>命名規則がバラバラ</h3>
よくあることとして単語の区切りがケバブケース・キャメルケース・スネークケースのようにバラけていると、どの規則に合わせればいいのか分からずいつまでも命名規則が統一されません。
<pre class="language-css"><code class="language-css">.account-login-button {
}

.commentSubmitButton {
}

.form_submit_button {
}
</code></pre>
<h2>CSS の破綻 まとめ</h2>
ここまで CSS が破綻する理由について書きました。まとめると次のとおりです。
<ul>
<li>詳細度が管理されていない</li>
<li>ルールセットの分割粒度が明確ではない</li>
<li>命名規則が決まっていない</li>
</ul>
<h2>CSS を破綻させない</h2>
ここからは CSS を破綻させないためにはどうすればいいのかを書いていきます。
<h3>詳細度を管理する</h3>
CSS などのファイルを分割するときはファイル内で下へ行くにつれて詳細度が高くなるようにします。またセレクタ定義や ID セレクタを書きすぎないようにするのも重要です。
例を挙げるとフォーム共通のスタイルを適用するときにセレクタを定義しすぎないことです。 
これにより少ないセレクタ定義で適用したスタイルを上書きできて秩序が保つことができます。
<pre class="language-css"><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>ルールセットの分割粒度を明確にする</h3>
スタイルの上書きを減らすためにルールセットの分割粒度を明確にすることも重要です。 
これはさまざまな方法が提案されていて、たとえば<a href="https://github.com/hiloki/flocss">FLOCSS</a>や<a href="https://smacss.com/">SMACSS</a>、<a href="http://ecss.io/">ECSS</a>などがあります。
これは作るものによって適しているものが違うため一概にどれがいいか言えません。 
スタイルを適用したいときにルールセットをどこに置けばいいのかチーム内で迷わないようにするのが重要です。
<h3>命名規則を決める</h3>
命名規則も<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>などさまざまなものがあります。これもチーム内で使う命名規則を一致させることが重要です。
<h2>CSS を破綻させない まとめ</h2>
ここまで CSS の破綻を起こさないためにどうしたらいいか書きました。まとめると次のとおりです。
<ul>
<li>詳細度を管理する</li>
<li>チーム内でルールセットの分割粒度を明確にする</li>
<li>チーム内で命名規則を決める</li>
</ul>
しかしこれらを実践する前により大事なことが 1 つあります。 
それはデザイナーとの認識合わせです。
これは<a href="http://morishitter.hatenablog.com/entry/2016/07/29/204642">デザインの意図を正確に理解した上で書かれた CSS は破綻しない</a>という言葉があります。
デザイナーが作った Sketch や Photoshop のファイルを見て質問や提案をおこない、デザイナーと UI を実装する人で意図の認識を合わせることが重要です。 
もっと言うなら Sketch や Photoshop などで作る以前のプロトタイピングの段階から関わるとお互い意図の認識がしやすくなると思います。 
プロトタイピングツールは<a href="https://www.invisionapp.com/">InVision</a>が代表的です。
これを踏まえてまとめると、チームで議論して良い CSS 設計を考えようになります。
<h2>CSS がすでに破綻している場合は？</h2>
builderscon の Q&#x26;A で「途中から入ったプロジェクトの CSS が破綻していた場合どう改善したらいいのか？」というのがあったのですが、今のところチームで話し合って設計指針を決めて 1 から書き直すしかないと考えています。
<h2>参考資料</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を破綻させない

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

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

<h2>何が起きたか</h2>
<a href="http://jsfiddle.net/bo5rj0b5/4/">http://jsfiddle.net/bo5rj0b5/4/</a>
上記の jsfiddle で CSS の所に書いたように、keyframes に background-image プロパティを指定して、クロスフェード効果で背景画像の表示が切り替わるという動作を期待しました。
Chrome では、期待通りの動作をしたのですが、Firefox と Android Browser ではアニメーションどころか、画像自体が表示されませんでした。
<h2>解決</h2>
<blockquote class="twitter-tweet" lang="ja"><a href="https://twitter.com/o_ti">@o_ti</a> <a href="https://twitter.com/kubosho_">@kubosho_</a> background-image はアニメーション不可能なプロパティでだからではないですか？&mdash; xl1blue (@xl1blue) <a href="https://twitter.com/xl1blue/status/555695483037822977">2015, 1月 15</a></blockquote>
！？
<blockquote class="twitter-tweet" lang="ja"><a href="https://twitter.com/kubosho_">@kubosho_</a> <a href="https://twitter.com/xl1blue">@xl1blue</a> ホントだ。Animatable: no だった。<a href="http://t.co/JopFQtOO5F">http://t.co/JopFQtOO5F</a>&mdash; 越智 (@o_ti) <a href="https://twitter.com/o_ti/status/555696632675594240">2015, 1月 15</a></blockquote>
なん…だと…？
というわけで、background-image は仕様的にはアニメーション不可能なプロパティなのですが、Chrome が仕様に準拠していないという事でした。
というわけで、以下のように書き直しました。
<h2>クロスフェードされるように書き直したコード</h2>
<h3>HTML</h3>
<pre class="language-html"><code class="language-html">&#x3C;div class="test-01">
 &#x3C;img src="http://lorempixel.com/400/200/cats/1" alt="" />
 &#x3C;img src="http://lorempixel.com/400/200/cats/2" alt="" />
&#x3C;/div>
</code></pre>
<h3>CSS</h3>
<pre class="language-css"><code class="language-css">.test-01 img:first-child {
 -webkit-animation: crossfade 5s linear 0s infinite alternate;
 animation: crossfade 5s linear 0s infinite alternate;
}

@-webkit-keyframes crossfade {
 0% {
 opacity: 1;
 }
 100% {
 opacity: 0;
 }
}
@keyframes crossfade {
 0% {
 opacity: 1;
 }
 100% {
 opacity: 0;
 }
}
</code></pre>
<a href="http://jsfiddle.net/bo5rj0b5/7/">確認用の jsfiddle はこちら。</a>

background-image はアニメーション出来ない(問題と解決のコード付き)

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

// これはNG
.is-active {
 display: block;
}

</code></pre>
<h3>良いところ</h3>
<ul>
<li><code>--</code>や<code>__</code>という区切り文字より、セレクタ名が醜くならない(個人の主観です)</li>
</ul>
あとは構造が分かりやすいだったり、class 名が衝突するということが少ないという、BEM や MindBEMding を採用した人ならだいたい感じることでしょうか。
<h3>改善したいところ</h3>
<ul>
<li>prefix のところで世代管理をしなかったのは間違いだった
<ul>
<li><a href="http://geckotang.tumblr.com/post/104065014321/css">今年のネーミングルール #CSS 設計 - &#x3C; /gecko ></a>を読んで気づいた…</li>
<li>古いセレクタ名と、上記の命名規則を適用したセレクタ名が混ざっていて、辛くなることがある</li>
</ul>
</li>
<li>Modifier を使っている class 名で、Modifier-Key がない class 名というのは、分かりにくいのではと思った
<ul>
<li>この章を書いて気づいた…</li>
</ul>
</li>
</ul>
<h2>ディレクトリ構成</h2>
<a href="https://github.com/hiloki/flocss">hiloki/flocss</a> に基本は準拠しています。「基本は」と書いたのは以下のディレクトリ名を自分の好みで変えているからです。
<ul>
<li>foundation -> base</li>
<li>object/project -> object/page</li>
</ul>
<h2>使っている CSS プリプロセッサーやライブラリー</h2>
<ul>
<li>LESS</li>
<li>Normalize.css</li>
</ul>
LESS な理由ですが、<a href="https://speakerdeck.com/mayuki/sosiyarugemufalsehurontoendotoasp-dot-net-mvc-lite?slide=7">ソーシャルゲームのフロントエンドと ASP.NET MVC (Lite)</a>の 7 ページにも書いてあるように、Visual Studio との相性が良かった(新規ファイル作成時に*.less 形式でのみファイルが作れた)ことが要因です。
とはいえ、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 かを選べるようになったと言えます。
ライブラリーは Normalize.css くらいしか使っていないです。これはやはり同僚の@mayuki が入社したての頃に、汎用 class をゴリッと書いてくれたので、ライブラリーを使う理由があまり無くなったという感じです。
<h2>CSS プリプロセッサーの機能について</h2>
<h3>extend</h3>
<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 を多用すると、どこにそのルールセットが書かれているか分からなくなり破綻する、というのが大きな理由です。
<h3>ルールセットの入れ子</h3>
CSS プリプロセッサーのほとんど(全て？)はルールセットの入れ子がおこなえますが、入れ子の深さは二段階までと定めています。具体例としては以下のコードです。
<pre class="language-sass"><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>
なぜ、二段階までに抑えているのかというと、制限がなかった場合、出力後の CSS のセレクタ部分がとても長くなってしまう可能性があるということが挙げられます。
具体例を書くと、以下のような LESS のコードがあったとします。
<pre class="language-sass"><code class="language-sass">// Uuuugly!
.foo {
 .nest-01 {
 .nest-02 {
 .nest-03 {
 .nest-04 {
 .nest-05 {
 color: #333;
 }
 }
 }
 }
 }
}
</code></pre>
上記のコードを CSS にコンパイルした場合、以下のようになるでしょう。非常に長くて醜いです。
<pre class="language-css"><code class="language-css">.foo .nest-01 .nest-02 .nest-03 .nest-04 .nest-05 {
 color: #333;
}
</code></pre>
また、実際に挙動を確かめられていないですが、多くのサイトで「ブラウザーのセレクターの解釈として、右から左に解釈される」と書かれています。
とすると、上記の CSS は「.nest-05 -> .nest-04 -> .nest-03 -> .nest-02 -> .nest-01 -> .foo」と解釈されることになります。「.nest-01 -> .foo」という構造よりも解釈に時間がかかりそうです。
ちなみに、古い記事(2011 年)ですが、<a href="http://developers.linecorp.com/blog/?p=178">CSS セレクタによる高速化、実際のところ « LINE Engineers' Blog</a>に実際の計測結果が掲載されており、そこには以下のように書かれています。
<blockquote>
・スタイルを当てる要素にはできるだけclass又はIDを指定する 
・子孫セレクタは重いのできるだけ減らす 
という施策に一定の効果はあるようですが、その効果が如実に現れるのはHTML、CSSのコードが非常に大きいページに限られるようです。 
そのなかでも、子孫セレクタを減らす施策よりも、スタイルを当てる要素にはできるだけclass名を指定する施策のほうが、効果があるようです。
</blockquote>
ということで、MindBEMding の考え方を適用し、ある Block の中でスタイルを当てたい要素には、.block_element だったり、.block_element-Key-Value という感じで class 名を指定し、スタイルを適用しています。
<h2>まとめ</h2>
ソーシャルゲームというのは、最初から機能が数十種類あったり、View のファイル数が数百ファイルを超えるということは珍しくないと思います。
そんな中で、CSS を書く上での指針がないと、時間が経つにつれ運用が苦痛になってきます。
例えば新しい人が入ってきたり、自分に何かあって他の人が一時的にプロジェクトに入ってきた場合、CSS を書く上での指針が無いと、どのように CSS を書いていけばいいのか、理解に時間がかかることになります。
なので、CSS を書く上での指針を定め、かつ、それを GitHub の Wiki など、プロジェクトのメンバーが目に入る場所に残しておくのが重要と、自分は考えています。
明日は、<a href="http://www.adventar.org/users/9">越智</a>さんです。
<h2>記事内で紹介した 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' Blog</a></li>
</ul>

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

<h2>やりたかったこと</h2>
<pre class="language-html"><code class="language-html">&#x3C;table>
 &#x3C;colgroup span="1" style="padding:10px; background:#66c; color:#fff; text-align: center;" />
 &#x3C;tbody>
 &#x3C;tr>
 &#x3C;td>10&#x3C;/td>
 &#x3C;td>foo&#x3C;/td>
 &#x3C;/tr>
 &#x3C;tr>
 &#x3C;td>20&#x3C;/td>
 &#x3C;td>bar&#x3C;/td>
 &#x3C;/tr>
 &#x3C;tr>
 &#x3C;td>30&#x3C;/td>
 &#x3C;td>baz&#x3C;/td>
 &#x3C;/tr>
 &#x3C;/tbody>
&#x3C;/table>
</code></pre>
という HTML を書いた際に、縦 1 列目に padding, background, color, text-align の指定が適用される想定でした。
<h2>問題</h2>
<a href="http://jsbin.com/xaleva/4/edit?html,output">上記の HTML を書いた JS Bin</a>を見ると分かるように、background の指定以外は適用されていません。なぜ？
<h2>分かったこと</h2>
<a href="http://www.w3.org/TR/CSS21/tables.html#columns">W3C の CSS 2.1 の仕様書内にある Tables 17.3 Columns</a>を見ると分かるのですが、table-column や table-column-group のプロパティが指定されている要素(col 要素と colgroup 要素)には、下記 4 つのプロパティのみ指定できるようです。
<ul>
<li>border
<ul>
<li>table 要素に<code>border-collapse: collapse;</code>が指定されている時のみ適用される</li>
</ul>
</li>
<li>background</li>
<li>width</li>
<li>visibility</li>
</ul>
<h2>まとめ</h2>
自分が適用したかったスタイルは colgroup 要素や col 要素では適用できないことが分かったので、colgroup 要素や col 要素は使わないことにしました。
その代わりに、縦 1 列目に class を指定して、その class に適用したかったスタイルを指定することにしました。

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

CSSの記事一覧