やまろぐはてな

勉強会レポートとか技術メモとか戯言とか

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

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

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

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

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

github.com

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

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

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

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

CSS2 => CSS3

f:id:cardboarder:20171214231200j:plain

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

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

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

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

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

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

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

f:id:cardboarder:20171214231345j:plain

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

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

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

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

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

f:id:cardboarder:20171214231609j:plain

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

有名どころですと、OOCSSSMACSSFLOCSSBEMなどでしょうか。

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

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

f:id:cardboarder:20171214225459p:plain

当初は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たちをどうやって見直していけばいいか?という部分においてヒントとなりえそうなものがあるので紹介していきます。

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

kojika17.com

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

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

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

stylelintにおける品質維持

f:id:cardboarder:20171215010857p:plain

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

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

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

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

f:id:cardboarder:20171214232901p:plain

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

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

github.com

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

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

github.com

正義のCSSをやっていこう

f:id:cardboarder:20171214233002p:plain

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

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

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

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

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

孔子

*1:今は学部ごと移動して事実上の消滅

*2:https://allabout.co.jp/gm/gc/376450/

*3:もしかしたら最初から破綻を前提とした「純粋悪なCSS」も存在すると思いますが、その場合は闇に葬り去るか完全にリセットした方がいいかもしれません