CSSとわたし、正義と悪、そしてこれから。

この記事は CSS Advent Calendar 2017 16 日目の記事です。

テック的なことを書こうかと思いましたが、これまでの人生を振り返ってきて自分にとっての CSS とは何か、そしてこれからどうやっていくべきかみたいなことを書こうと思います。Qiita に書くのもあれな内容と判断したのでブログの方にしました。

「はじめて公開された」CSS

自分が、個人の制作物以外で「世の中の人に初めて公開された」CSS はこちらになります。

https://github.com/yamanoku/gwe2012/tree/master/css

なんだかよくわからないものばかりになっております。自分で推測しますが、どこかしらのテンプレートから拝借してそのまま置いてみた感じかなと思います。まぁ当時の独学でアレコレやったド素人が書いたものなのでそんなもんです。

美術系の大学出身¹なのですが、一応サイトを作れる人間だったので当時の卒業制作展のサイトを勝手に担当していました。

卒業年が 2008 年なのですが当時は iPhone が出回り始めて、いわゆる「スマートフォン対応」というものを徐々にしていかないといけない時代だったと思います。当時の自分はレスポンシブ対応することまではできなかったなりに、「PC は PC の体験を、SP は SP の体験をすべき」という考えをもとに SP ページを用意して .htaccess でユーザーエージェント判定をして振り分けなんぞやってました。

当時の有名美大の卒業サイトと見比べると月とスッポン、いや比喩することすら失礼にあたる可能性があるくらい出来は微妙なのですが、素人なりに真新しいことは無理にやらず、ちゃんと情報にたどり着ける阻害しないようなスタイル、そして CSS は分けてスタイルも分割するなんていう生意気なことをやっていたんですねぇ（ただし内容はグダグダな感じです）

CSS2 => CSS3

さて、思い出語りから話をガラリと変えてしまいますが、CSS3 というものがこの世に出てからどれくらいが経ったのか皆さまはご存知でしょうか。

調べたところどうやら「CSS2.1」が確定された 2011 年より策定が進んでいる²とのことで、誕生？　から６年ほど経っているようです。

先程紹介させていただきました卒業制作展サイトにも CSS3 Media Queries を使用したり、box-shadow 要素や gradient、border-radius といった要素を使用しておりました。

これまで自分の中で CSS というものはサイトにある要素を「整える」ものという認識でいて（今もそんな感じかとは思いますが）、キッチリとやるために必要なものだと思っていました。

それが CSS3 になって、より多彩な表現の幅を広げてもらえるものになったと思い、当時は画像などで対応せざるを得なかったものを CSS で対応してくれる革新性には驚かされました。

CSS とはこんなにも自由なものなのになったのか！　それはとても素晴らしいことだと当時の私は感嘆しておりました。

プリプロセッサ、ポストプロセッサとの出会い

手書きで CSS を書くことが当たり前だった私が転職先で「えっ素で CSS 書いてるの…マジ…？」と言われるくらいには古いやり方だったようで、双方に驚きがあったようです。

素の CSS を弄る時代はいつの間にか終わっており、代わりに Less、Sass、Stylus といったプリプロセッサ言語で楽に CSS を書ける、管理しやすくすることが出来ることを知ってから、世界はこんなにも広かったのか！　というような気がしました。

中でも Stylus との出会いは特に衝撃的でした。何故かというとインデントで階層管理して、あの煩わしかった{}やコロンも省略可能で記述スピードを爆速にしてくれるのには感動しかありませんでした。

出力された後に調整する「ポストプロセッサ」なる autoprefixer、minify、PostCSS といったものにも触れ、ブラウザごとのバージョンに合わせて、または CSS の機能を拡張してくれるなど、これらもまた私にとっては大変重宝しているものたちでした。

「設計思想」というものがある

これまで CSS についてなんとなくで書いてきた私でしたが、仕事をしたり、インターネットを潜っていると「世の中には CSS 設計思想というものがある」ことを徐々に知りました。

有名どころですと、OOCSS、SMACSS、FLOCSS、BEMなどでしょうか。

設計思想とはいわば、CSS をこういう風に切り分け・管理・拡張すると運用や再利用がし易い設計となるのではないかという考え方をもとにそれぞれのアプローチが提案されています。

自分が業務として体験してきたのは、SMACSS、BEM、そしてECSSです。

当初は BEM を使った設計を全面的に目指そうと考えていたのですが、ECSS が我々の業務内での設計と fix するのではないかと考え、今は ECSS をベースとした設計思想で作成しています。

これまでの経験則として、ファイル数は増えるがもっとも追加や更新のコストを軽減しうるものではないかなと感じています。

CSS は世間で「忌み嫌われている」言語だった

そんなこんなで便利なツールや意味のある設計思想を使って CSS を書くことが楽しくなってきた筆者にとある避けられない事実を突きつけられました。

それは CSS は

• 「明確な解決法もなく」
• 「保守しようにも破綻しかねない」
• 「一番考えるのが煩わしい」

言語ということだったのです。

おいおいそんなこと言うなよ！　こんなにも素晴らしく楽しい世界にそんなことなんて…そう思って私が振り返ってこれまでの CSS を見てあることに気づきました。

「同じように生み出された style.css なのに、よく見ると…ルールや内容が全然違っている…！」

クライアントワークを行う上で、要件や仕様というものが決まっていると、それに準拠するために設定などを見直す必要がでてきます。また、外部の方に制作を依頼するときも少しでも綻びがあるとそこから新たなるルールが発生してこちらがオーバーライドしかけるという事態も起こり得ていたのでした。

加えて運用案件においてもソースコードが誰かしらの手に渡り、制作意図もうまく伝わらぬまま変わり果てた style.css となって残り続けているものもあり、それをメンテナンスしなければならなくなるということもあったそうな（この段落はフィクションです）。

もちろん下準備した我々がそうした事態を考慮できてなかった問題もあるのですが、それにしてもここまで顔が違くなることはあるのか？　多少の設計やプリプロセッサは違えど、何故みんな同じようにできなかったんだ？などかつての思い描いていた何でもできる素晴らしい CSS は一体何処へ…？

もしかしたら CSS を誤解していたかもしれない

そうした失敗への気付きから今一度 CSS についてを考え直していました。

こんな書き方をしてしまえば身も蓋もないのですが、よほど長期運用するサイトであったとしても、万能薬として効く設計思想やプリプロセッサ、そしてそれをもとに得られる、再帰性があり可読性も高く更新しやすい CSS を生み出すということは、まず難しいということです。

これは CSS 自体が悪いものなのか、と考えることもできるのですが、私自身はそうではなく、むしろそうした CSS に合わせられないサイト設計、UI 設計が良くないのでは？ というある種の責任転換みたいな、しかしながらそうしない限り破綻が続くような考えを持つようになりました。

「なんでや！　自由度の高いサイトデザインができなくて何が Web や！」という意見もごもっともだと思います。

ですが、結局のところウェブに残るものとは文化資産に近いそれらだと思っており、そういった文化をメンテもできない冗長性しかないもので管理するのはいかがなものか…とも考えられるのです。

なので、極端ではありますが、現状 CSS との付き合い方はこうするしかないのかなと思っています。

• サイト設計や UI 設計といったものをメンテナンスできて要素を更新するにも容易に対応できるものとした上で、正義の CSS を生み出す
• 新たなクラスをどんどん生み出し、他のセレクタなどに影響を出さないことを前提とした闇鍋のような悪の CSS を生み出す

極端過ぎる。でも結局はどちらかになると思ってます。

ただ、正義の CSS を生み出すために、CSS に対してみんなで優しくしろ、という訳ではないと思っています。

何故かというと、CSS に優しい設計を考える上で、CSS 以外もきちんとどう運用すべきか、どう管理すべきか、どう設計すべきかなどが徹底されて初めて成り立つものだと思っているからです。

だから世間で忌み嫌われている CSS は、自由度が高すぎるがゆえに「なんでもしてくれる床上手な処女」のような空想上のものとどこかで錯覚しているのかもしれません。CSS もほかの言語と変わらぬきちんと運用されないと破綻されるものと一緒なのです。

CSS を見直すヒントたち

そんな CSS たちをどうやって見直していけばいいか？　という部分においてヒントとなりえそうなものがあるので紹介していきます。

宣言ブロックは慎重に精査する

宣言ブロックの CSS 設計 | Web Design KOJIKA17

kojika さんのブログでも述べられていたように、CSS においてプロパティや値を管理する宣言ブロックについてはあまり意識していなかったようにも思えます。

たしかにどこかで !important を入れてしまうとそれをオーバーライドするために元あった宣言ブロックのルールが破綻してしまいかねないことや、汎用的に使いこなしたいのに width 指定やテキスト方向などが変更できないものなど、想定していたものと別の形になってしまうことがあります。

こうした事態を避けるためにもデザインの確認やある程度余白を意識した宣言を書くようにしないといけません。割とタグに直接書く悪習はなかなか治らないので、そこで左右されないように大元をも見直すことも大事かと思われます。

stylelint における品質維持

JavaScript の構文チェックに使用される eslint という Lint ツールがあるのですが、それの CSS 版 Lint ツールに「Stylelint」というものがあります。

CSS を綺麗に整形できているか？　統一化された書き方ができているかという面で有用なのですが、他にも「!important を使っていないか？」「階層を深くしすぎていないか？」「プロパティが重複していないか？」などの宣言ブロック関連のチェックをしてくれるものもあります。

標準の Lint ルールが割とすぐに使える（エラーも少なめ）なところもあるので、必要な部分を徐々に継ぎ足して、ルールをもった可読性のある CSS を実現させましょう。

コンポーネント指向におけるパーツごとでの管理

正義の CSS を生み出す上で、私の中での１つの解として考えているのがコンポーネント管理です。 レイアウト、ページ、パーツという単位で切り分けそれらを組み合わせる…いわゆるアトミックデザインのそれに当たりますが、とにかく範囲をぶつ切りして影響範囲を減らしていく過程というのは必要なのだと思いました。

そういう意味では Nuxt.js というプロダクトがまさに適応しうるのでは？　と考えております。CSS に関しては style scoped が使用できるので、より閉鎖的に他とバッティングすることもなくセレクタの命名問題点も解消できるかもしれません。

ただ、問題点を解消できる参入しやすいプロダクトだと思うのですが、まだまだ汎用的に使用するには有用な情報が少ないので、「まだ」確実な一手とはなってないかと思います。ですが参考にしうること（ディレクトリ構成など）は多いと思います。

他にも React を Vue ライクにする one-loader というプロダクトもあるみたいです。

https://github.com/digitalie/one-loader

正義の CSS をやっていこう

上記３点の他にも解決しうるものは探せば出てくると思うのですが、それをこれからすぐにやり始める・導入するというのもなかなか難しいことのように思えます。何故ならこれからの CSS を失敗しないようにしても、これまでのものを無かったこと・解決したことにはならないからです。贖罪とはならないのです。

私自身も数多くの「悪の CSS」を生み出し続けてきました。生み出してきたものを無かったことにすることはできませんが、彼らをもう一度、正しい方へと導いていくことはできるかもしれません。そのためにも何故こういう状態になっているのか・どうすればまとめられるのかを見直していくことが必要になります。

ですが、かつては皆が信じてやまなかった「正義の CSS」として作られていたはずのものであるならば、実現しようとしていた正義の片鱗のようなものがどこかにあるはずです。そこを頼りにかつての正義（もしくは新たな希望）を取り戻しに行くことはできるかもしれません。³

最後にこの言葉をもって終わりとしたいと思います。ご覧いただきありがとうございました。

悪に報いるには正義をもってし、善に報いるには善をもってせよ。

孔子