CSSコーディングにおける効率化の流れを考える

CSSとの付き合いはもう15年来になろうとしているわけですが、まあ仕事で使っていたわけではないので関わり方はテキトーです。

最初に自分のサイトでCSSを使ったのは2002年頃だったかと思います。それまでタグの属性として打ち込んでいたレイアウト要素が別のファイルで一括管理できるようになったことは、中学生ながら感動した覚えがあります。

成人して久々にサイト作りを、ってなったときにHTML5とCSS3に触れたときはびっくりしましたね。できることがすごく増えてるし、ふわふわしていた住み分けがかなりはっきりしている。あと昔はほとんど使っていなかったセレクタを活用し始めたことでかなり自由も効くようになりました。

一方で、「めんどくせえwwww」って感覚もかなりありました。レイアウト部分を全て任せることでCSSファイルに記述されたコードは膨大になり、同じような記述を何度も繰り返さなければならない。「何度も繰り返す」という作業は私の人生にとって敵なんですよ。だってめんどくさいじゃん。

今回このブログのテーマを作るにあたって、いちから作るのはめんどうだし、別サイトのレイアウト引っ張ってきてちょちょいっとCSS変えようかなー、と思い当たったんですが。色を一括で変えるのに置換処理を走らせるしかないってなんなの?どうなの?と思いまして。もう2016年も暮れかけているし、CSSも変数とか使って動的にさくっと構築できるようになってるでしょー、と考えたわけです。次作るテーマはめちゃくちゃ使い回ししやすいものにしたいですしね。Webクリエイターでない私はテーマを作ることでなくコンテンツを充実させて人の役に立ったり人と知り合ったりすることが目的なわけです。

で、Google先生に聞いてみたらまああった。Sassというのがそれで、またネイティブCSSで変数を使える機能も登場したとかなんとか。

でもそれって最近の話で、これまでどうしてCSSは全て手書きでみんな我慢してきたの?ってふと疑問に思ったわけです。


スポンサーリンク

Sassという革命

CSSで変数を使わせろ!と探して突き当たったのがSassでした。Syntactically Awesome Stylesheetsの略。ざっと見たところこんなことができるらしい。

  • 値に変数が使える
  • セレクタをネストできる
  • 値の計算ができる(しかも単位違いでもOK)
  • ある程度まとまった記述をまとめて使い回しできる(ミックスイン)
  • 複数のSASSファイルに記述したコードをひとつのCSSとして吐ける
  • 条件分岐やループもできる

ふむ。CSSを記述するときに「これができたら…」と思うことがおおよそできる様子です。

2016年にもなってメタ言語でしか効率化できないってなんなの

SassはおよそCSSを触ったことのある人が皆思う「こうだったらいいのに」を実現している仕組みだと思います。しかしながら、あくまでメタ言語で、SassそのものはRubyで動くソフトウェアなんですね。ようは少ない記述でめんどくせぇCSSを吐き出すよ!というツール。そのためにはRubyをインストールしてSassをインストールしてさらにCSSを作るときは都度コンパイラを通さなければならない。Sassを保存すれば自動でターゲットのCSSを更新してくれる機能もあるにせよ、監視コマンドなんて起こしておいたら端末のリソース喰いまくるんじゃないの?やったことないから知らんけど。

つまり、成果物のCSSはやはりめんどくせぇもののままなわけです。

CSSだって言語です。それなのに、これだけITによる様々な生命活動の効率化が行われている2016年で、未だにベタベタに固有値打ち込むしかコーディングする術がないだなんて、どういうことかと。チューリングマシン性や固有値の柔軟性は全ての言語が持つべきというのが私の持論なんですけど、一切ない。なんなの?なめてんの?

DreamwerverとSass

とか苦言を呈しつつも、とりあえずSassを知ったばかりの私はもちろん使ってみたいわけで。で、早速インストールしたはいいものの、どうやってDreamweaverと共存させようか?と立ち止まりました。

私が使っているのはDreamweaver CCで、現在のバージョンは2015です。少し前にマイナーアップデートを行ったとき、「Sassに対応しました!」的なメッセージが出ていたんですけれども、Sassが何か知らなかった私は完全にスルーしてました。

「メッセージが出ていたからにはなんらか便利な連携機能があるんだろう」

そう思って調べてみても、読み込めるようになった程度、コードヒントもバグだらけという噂w

しかしタイミングがよかったのか、2017バージョンへのアップデート案内が来たんですね。新機能の説明やBeta版の使用レビューを読んでみると、Sassのコンパイル・自動コンパイルにも対応したという話!

wktkして絶賛アップデート中です。だから今日2本目の記事なんて書いてるわけで。使ってみたら使用感をレビューしようと思います。一番の懸念はSass連携とクイック編集が両立できるのかというところ。できないだろうなあ。Adobe先生ちょっとツメ甘いとこあるし。

CSSカスタムプロパティという答え

もう一つの動きとして、CSSそのものにコーディング効率性を与えようという動きがあります。CSSカスタムプロパティってやつです。これは本当に最近の話みたいで、今年に入ってChromeを皮切りに対応が広がっているとかなんとか。

しかしできることって、「変数が使えるよ!」くらい…。

もともと「変数使いたい!」がSassを知ったきっかけだったりもしたので、そういう意味では需要を満たしてはいますが。とりあえずはSassを使うかな、私は。


スポンサーリンク

なぜCSSの効率化はこんなにも遅いのか

これが一番の疑問です。が、答えは見えています。

CSSコーディングを生業としている人は必ずしもシステム屋とは限らない

Webデザイン業というのはIT業界の中では異色の場所で、そこで働いている人には必ずしもプログラミングやシステム構築の経験があるとは限りません。さらに個人サイトをある程度自分でカスタマイズして作ろう!という方も背景は様々です。

HTMLやCSSは言語ではありながらプログラミング知識が必要というわけでなく、とっつきやすい。だから、他の言語で当たり前な変数や条件分岐、ループという概念を知らなくても身につけることができる。

そのことによる効率化への弊害が二つあります。

  • 新しい概念を身につける敷居の高さ
  • 効率化を行う方法を知らない

私も最初に習得した言語がHTML/CSSだったクチだからわかります。JavaScriptがサイト作成の一般常識になってきた頃のあの感覚です。

変数、条件分岐、ループ、サブルーチン。JavaなりVBなりの言語をひとつ知っていれば当たり前の、その「当たり前」がない。その状態で「当たり前」を持ってこられてもこっちはちんぷんかんぷんなんだよ、という感覚。それが敷居の高さにつながるし、また日々面倒くさいなあという作業がある概念を導入することで劇的に簡単になるということを、単純に知らない。

だから手法の開発は遅れるし、せっかく登場しても浸透しないんだろうなと。

CSSはブラウザに読んでもらわなければならない

あとはこれです。Webサイトというのは誰かに見てもらうことを前提に作られるわけで、それを見る誰かがどんな環境から接続してくるかなんてわかりません。

Webkitが登場して波及したことで環境依存性をさほど考慮しなくてよくなったことはWeb業界で最大の革命だったと思います。昔はIEとネスケ、WindowsとMacで読めるものが全然違ったので、動作確認環境をいちいち宣言しなければならなかったんですよ…。

デバイスこそ多様化していてもそこで働いているエンジンが同一であればある程度の標準化は可能。でもそのエンジンに新機能が追加されたとき、やはり訪問者の環境がアップデートされなければ使うことはできません。

世の中思っているより多いんです。アップデートの仕方を知らない人。病院シス管時代(たしか昨年)、LINEのやり方がわからないととあるユーザの個人的質問を受けたとき、iOSが6で数秒固まりましたからね。もはやノスタルジー。でも世の中、そんなもんなんです。

裏で動いている色んな言語やプロトコルはサーバのアップデートで対応できるから比較的すぐに新しい技術を取り入れることができる。でも一番ユーザ(ブラウザ)に近いHTMLやCSSはそういうわけにいかない。

今後様々な技術が発展し生活に浸透していく中で、最終的に吐き出されユーザが触れるものがHTMLやCSSであり続けるのであれば、その在り方は簡単に仕様を変更できないものとして実装時にあらゆる考慮を盛り込む必要があります。ひとつ言えることは、私はその策定をするメンバーには絶対なりたくないな、です(笑)。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

*