<a href="http://qiita.com/advent-calendar/2015/bootstrap">Bootstrap Advent Calendar 2015</a> 8日目の記事です。 
ここではBootstrapのテーマの1つである、<a href="http://nico.kubosho.com/">Nico</a>のこれまでとこれからについて書きます。
<h2>これまで</h2>
まずはNicoができてから、現時点の最新バージョンであるv3.3.6-1.1.0までの軌跡を振り返ります。
はじめにNicoを作ったきっかけとしては、現在冬コミに向けて執筆中の<a href="https://github.com/o2project/start-dash-of-site-making">サイト制作のSTART:DASH!!</a>という同人誌です。 
同人誌の目的上、ラブライブ！のアニメにでてきたラブライブ参加者募集サイトを実際に作る必要がでてきました。 
ただ1からCSSを書くのが面倒と感じた自分は、<a href="http://honokak.osaka/">Honoka</a>をforkし、オリジナルのBootstrapテーマを作ることにしました。
このラブライブ参加者募集サイトですが、図1のアニメ画像キャプチャを見て分かるように配色がピンク系となっています。 
配色がピンク系ということは、にこしかいないということで、名前がNicoに決まりました。
しかしHonokaをforkしてできあがったNicoですが、リポジトリーのファイルを見ているうちにいろいろと作業環境を整えたくなりました。 
そのためまずは作業環境を整えました。
<h3>作業しやすくするためのSTART:DASH!!</h3>
主にやったことは3つあります。
1つめは、Gruntをなんとなく気分的にグローバルインストールしたくないと思ったため、<a href="https://github.com/kubosho/Nico/commit/57c244d8b8c898efffb45e5e9977222f0a8f6d41">npmのrun-scriptでラップしました</a>。
2つめは、scssファイルがちゃんとできるか自動で確認したかったので、<a href="https://github.com/kubosho/Nico/blob/743aeb2a8e5e102506432dc450e8f2bc8f0efc06/.travis.yml">Travis CIを導入しました</a>。
3つめは、Travis CI導入に関係していますが、HonokaだったりNicoの公開用ファイルをgh-pagesブランチに上げる際は手動で上げないといけませんでした。 
しかし手動は面倒だと感じたため、<a href="https://github.com/kubosho/Nico/blob/743aeb2a8e5e102506432dc450e8f2bc8f0efc06/.bin/deploy-to-gh-pages.sh">よしなにgh-pagesブランチへpushしてくれるシェルスクリプトを書きました</a>。
<h3>Nico襲来</h3>
これで作業がしやすくなったので、ようやく配色をHonokaからNico仕様にしていきます。 
配色を考える上で真姫・凛・花陽・絵里・希のイメージカラーを入れたいと思い、考えた結果次のような配色になりました。 
<code>danger</code>が紫色になっているのは、希のイメージカラーを入れたいためだったのですが、一応根拠もあります。 
それは、天気予報で特別警報の配色が紫色というところから来ています。
<table>
<thead>
<tr>
<th>名前</th>
<th>カラーコード</th>
<th>色</th>
</tr>
</thead>
<tbody>
<tr>
<td>default</td>
<td>#f3d4df</td>
<td><div style="width: 1em; height: 1em; background-color: #f3d4df;"></div></td>
</tr>
<tr>
<td>inverse</td>
<td>#ff50ac</td>
<td><div style="width: 1em; height: 1em; background-color: #ff50ac;"></div></td>
</tr>
<tr>
<td>primary</td>
<td>#ff50ac</td>
<td><div style="width: 1em; height: 1em; background-color: #ff50ac;"></div></td>
</tr>
<tr>
<td>success</td>
<td>#4caf50</td>
<td><div style="width: 1em; height: 1em; background-color: #4caf50;"></div></td>
</tr>
<tr>
<td>info</td>
<td>#5cfaf9</td>
<td><div style="width: 1em; height: 1em; background-color: #5cfaf9;"></div></td>
</tr>
<tr>
<td>warning</td>
<td>#ff5052</td>
<td><div style="width: 1em; height: 1em; background-color: #ff5052;"></div></td>
</tr>
<tr>
<td>danger</td>
<td>#ac62ff</td>
<td><div style="width: 1em; height: 1em; background-color: #ac62ff;"></div></td>
</tr>
</tbody>
</table>
そして<a href="https://github.com/kubosho/Nico/releases/tag/v3.3.5a">Nico v3.3.5a</a>をリリースという流れになります。
<h3>なんとかしなきゃ！</h3>
リリースした後は、Honokaのバージョン更新に追従していくだけだったのですが、ある時自分の中で事件が起こります。 
それは、<a href="http://coliss.com/articles/build-websites/operation/work/best-templates-for-bootstrap-2015-autumn.html" rel="nofollow">商用利用無料！Bootstrap 3, Bootstrap 4をベースに最近のUIデザインのトレンドを取り入れた新作テーマのまとめ | コリス</a>という記事にHonokaと<a href="https://nkmr6194.github.io/Umi/">Umi</a>は掲載されたのですが、Nicoが掲載されなかったことです。 
最初は自分で使うために作ったとはいえ、せっかく作ったし他の人にも使ってほしいと思った自分にとって、ショックを受けた出来事でした。
この時にはHonokaのサイトからNicoがリンクされていたので見てないということはたぶん無いとは思う（と信じたい）のですが、それでも掲載されなかった理由を考えて、配色的に使いづらさがあったという結論に至りました。
特に<code>info</code>の色が強すぎること、また<code>warning</code>と<code>danger</code>の色が元のBootstrapだったり、Honokaとかけ離れているのが原因だったと思います。 
そのため、<code>v3.3.5-1.0.0</code>より次のような配色にしました。 
基本Honokaを踏襲しつつ、モノクロで見たときに<code>primary</code>より<code>success</code>のほうが色が強くなるよう調整しました。 
また<code>info</code> > <code>warning</code> > <code>danger</code>の順に色が強くなっています。
<table>
<thead>
<tr>
<th>名前</th>
<th>カラーコード</th>
<th>色</th>
</tr>
</thead>
<tbody>
<tr>
<td>default</td>
<td>#f3d4df</td>
<td><div style="width: 1em; height: 1em; background-color: #f3d4df;"></div></td>
</tr>
<tr>
<td>inverse</td>
<td>#ff50ac</td>
<td><div style="width: 1em; height: 1em; background-color: #ff50ac;"></div></td>
</tr>
<tr>
<td>primary</td>
<td>#ff64b1</td>
<td><div style="width: 1em; height: 1em; background-color: #ff64b1;"></div></td>
</tr>
<tr>
<td>success</td>
<td>#0faf20</td>
<td><div style="width: 1em; height: 1em; background-color: #0faf20;"></div></td>
</tr>
<tr>
<td>info</td>
<td>#a27dac</td>
<td><div style="width: 1em; height: 1em; background-color: #a27dac;"></div></td>
</tr>
<tr>
<td>warning</td>
<td>#ff7302</td>
<td><div style="width: 1em; height: 1em; background-color: #ff7302;"></div></td>
</tr>
<tr>
<td>danger</td>
<td>#f45042</td>
<td><div style="width: 1em; height: 1em; background-color: #f45042;"></div></td>
</tr>
</tbody>
</table>
なお<code>default</code>と<code>inverse</code>も色を変えれば使いやすくなるかもしれませんが、これを変えてしまうとNicoがNicoで無くなってしまうため、変える予定は今のところありません。
<h2>これから</h2>
というわけで必要に迫られて作り、いろいろと更新したNicoですが、これからの展望としてはHonokaの変更にできる限り付いていきたいと思います。 
なんだかんだでBootstrapは便利ですし、しばらく廃れないと思うので、このNicoやHonokaを通じてBootstrapがどのように進化していくのかを見ていこうと思います。

Nicoのこれまでとこれから

少し主語を大きく書いてしまいましたが、<code>*.css</code> と <code>gruntfile.js</code> についての話です。
「<a href="http://0-9.sakura.ne.jp/pub/kbkz_tech/start.html">CSS に死を！</a>」と言われたり、「<a href="http://mizchi.hatenablog.com/entry/2014/12/28/160715">CSS 勉強するのはだるい</a>」と言われたりしますが、これらを見ていると「Grunt がつらい」という話と共通項があると感じました。
<h2>どちらも設定ファイルである</h2>
自分の考えとして前提を書くと「<code>*.css</code> と <code>gruntfile.js</code> はそれぞれ「どのような見た目にするか」「どのようなタスクを実行するか」を定義するための設定ファイルである」という考えです。
その前提のもと、設定ファイルであるという利点と欠点をこれから書いていきます。
<h3>利点</h3>
<h4>少ない行数の時の見やすさ</h4>
<code>*.css</code> や <code>*gruntfile.js</code> は 200-250 行くらいまでなら、ソースコードの全体が少ない時間で把握でき、何をしているものなのかすぐに分かると思います。
<h4>敷居の低さ</h4>
CSS・Grunt ともに、ブログや Qiita などに上がっているソースコードをコピペしてくれば、なんとなくそれっぽい見た目になったり、タスクが実行できるようになると思います。
<h3>欠点</h3>
<h4>破綻しやすい</h4>
CSS はすぐに、無計画にルールセットを増やしたことによるファイルサイズの肥大化、スタイルの思いもよらぬ上書き (それに伴う !important 地獄)、必要ないルールセットの放置などが発生します。
Grunt も、無計画にタスクを増やしたことによるファイルサイズの肥大化、必要ないタスクの放置が発生しやすいと感じます。
ファイルサイズの肥大化については、CSS・Grunt ともにファイルを分割すれば良いという話ですが、CSS は @import を使うと CSS ファイルの読み込みが並列でおこなわれないため、全ての CSS ファイルを読み込むための時間がかかってしまう問題を抱えています。
また、Grunt も loadTasks() を使えば別ファイルに分割したタスクを読み込むことはできます。しかし、定義されているタスクの一覧性が悪くなるということと、読み込んだタスクが何をやっているのかを見るのが若干面倒という問題を抱えています。
<h4>手法が複数ある</h4>
CSS は MindBEMding だったり、SUIT CSS だったり、セレクタの設計手法が複数あります。
また、画像置換の手法についても、昔ながらの <code>text-indent: -9999px;</code> とする手法から、<a href="http://www.zeldman.com/2012/03/01/replacing-the-9999px-hack-new-image-replacement/"><code>text-indent</code> <code>white-space</code> <code>overflow</code> を組み合わせる手法</a>、<a href="http://nicolasgallagher.com/css-image-replacement-with-pseudo-elements/">擬似要素を使う手法</a>など複数あります。
Grunt も例えば Sass を CSS にコンパイルしたいといった時に、<a href="https://github.com/gruntjs/grunt-contrib-sass">gruntjs/grunt-contrib-sass</a> を使えば良いのか、<a href="https://github.com/sindresorhus/grunt-sass">sindresorhus/grunt-sass</a> を使えば良いのか、分からなくなると思います。
複数ある手法から最適解を求めたいところですが、そこに至るまでの時間が長くなりがちで、それがだるさに繋がるのかなと思います。
<h2>CSS が gulp から学べる点はなんなのか？</h2>
と、書いてみたものの、特に思い浮かばないので、ここは任せました。

なぜ CSS や Grunt はつらいと言われるのか

MindBEMding の Modifier を定義する際、単一のクラスセレクタで書く方法と、複数のクラスセレクタで書く方法があると思います。
実際の HTML で示すと以下のような感じです。
<h2>複数クラス</h2>
<pre class="language-html"><code class="language-html">&#x3C;table class="mod-table-01 mod-table-01--line-color-green">
 &#x3C;tr>
 &#x3C;th>foo&#x3C;/th>
 &#x3C;th>bar&#x3C;/th>
 &#x3C;/tr>
 &#x3C;tr>
 &#x3C;td>baz&#x3C;/td>
 &#x3C;td>foobar&#x3C;/td>
 &#x3C;/tr>
&#x3C;/table>
</code></pre>
<h2>単一クラス</h2>
<pre class="language-html"><code class="language-html">&#x3C;table class="mod-table-02--line-color-green">
 &#x3C;tr>
 &#x3C;th>foo&#x3C;/th>
 &#x3C;th>bar&#x3C;/th>
 &#x3C;/tr>
 &#x3C;tr>
 &#x3C;td>baz&#x3C;/td>
 &#x3C;td>foobar&#x3C;/td>
 &#x3C;/tr>
&#x3C;/table>
</code></pre>
<code>multiple class</code> とコメントで書かれているほうでは、クラス名は <code>mod-table-01</code> と <code>mod-table-01--line-color-green</code> の二つが指定されています。
<code>single class</code> とコメントで書かれているほうでは、クラス名は <code>mod-table-02--line-color-green</code> のみ指定されています。
上記の HTML に対し、CSS でルールセットを書く場合は以下のようになると思います。
<h2>複数クラス</h2>
<pre class="language-css"><code class="language-css">.mod-table-01 {
 border: 1px solid black;
 border-collapse: collapse;
 margin: 10px auto;
}
.mod-table-01--line-color-green {
 border: 1px solid green; 
}
</code></pre>
<h2>単一クラス</h2>
<pre class="language-css"><code class="language-css">.mod-table-02,
.mod-table-02--line-color-green {
 border: 1px solid black;
 border-collapse: collapse;
 margin: 10px auto;
}
.mod-table-02--line-color-green {
 border: 1px solid green; 
}
</code></pre>
この二つの指定方法のうち、果たしてどちらが良いのかというのを考えたので、以下に利点と欠点を書いていきます。
<h2>HTML に単一のクラス名を指定する際の利点と欠点</h2>
<h3>利点</h3>
複数のクラスを指定するより、若干簡潔になる
MindBEMding の考えでセレクタに名前を付けた場合は名前が長くなりがちです。複数のクラス名を指定した場合は、上記で示した HTML の例を見ると分かるように冗長感が否めません。
その一方、単一のクラス名で指定した場合は、HTML 側の指定は複数のクラス名指定より、簡潔になります。
<h3>欠点</h3>
スタイル定義が複雑になる
下記の JSFiddle の例を見ると分かるのですが、単一のクラス名を指定するほうが、複数のクラス名を指定するより、スタイル定義が複雑になっています。
<iframe width="100%" height="300" src="//jsfiddle.net/aempn99y/2/embedded/result,html,css" allowfullscreen="allowfullscreen" frameborder="0"></iframe>
これは例えば、後からプロジェクトに入ってきた人が CSS ファイルで定義されている内容を見た時に、理解を妨げる原因になるのではという考えがあります。
CSS のファイルサイズが大きくなりがち
<a href="http://www.luft.co.jp/cgi/str_counter.php">文字数 カウント（文字バイト数チェック）</a>で測ると分かるのですが、単一のクラス名を HTML 側で指定してスタイル定義をしていく場合、複数のクラス名を HTML 側で指定するより、CSS のファイルサイズが大きくなります。
<h2>HTML に複数のクラス名を指定する際の利点と欠点</h2>
<h3>利点</h3>
スタイル定義の見通しが良くなる
再び先ほどの JSFiddle の例を引っ張り出しますが、複数のクラス名を指定する場合、単一のクラス名を指定するより CSS のルールセット定義が簡潔になっています。
<iframe width="100%" height="300" src="//jsfiddle.net/aempn99y/2/embedded/result,html,css" allowfullscreen="allowfullscreen" frameborder="0"></iframe>
<h3>欠点</h3>
HTML 上でのクラス名の指定が単一のクラスを指定するより若干冗長になる
単一のクラス名を定義する時は HTML では <code>prefix-table-01--line-color-green</code> とだけ class 属性の値に書けばよかったですが、複数のクラスを定義する場合は <code>prefix-table-01 prefix-table-01--line-color-green</code> と若干冗長になります。
<h2>結果どちらを使ったほうが良いのか</h2>
単一のクラス名を指定するほうは HTML 側が少し簡潔になりますが、複数のクラス名を指定するのと比べ CSS 側が複雑になりがちというのは先ほど書いたとおりです。
その複雑になりがちというのが自分ではあまり許容できなかったので、複数のクラス名を HTML の class 属性の値として指定して、スタイル定義をしていくのが良いかなと思いました。
<h2>他の参考記事</h2>
マルチクラス設計について物申している記事もあるので、よかったらこちらも参考にしてみてください。
<a href="http://morishitter.hatenablog.com/entry/2014/11/28/004234">CSSプリプロセッサーの<code>extend</code>の悪いところ - morishitter blog</a>

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

タグ「CSS」の記事一覧