WP-D Week 2日目 本日はCSSについてでした。
CSSの設計は本当に厄介で、ひとつ案件を終えるたびにああすればよかったこうすればよかったと必ず思います。
現在手を付け始めている案件でもすでに迷いがあったりもして、CSSの第一人者的立場の方たちの話を楽しみにして行きました。
占部紘(Toro_Unit)さん
まずはトロユニさんの愛称で親しまれる占部さんのセッションでした。
色々と興味深い話を聞けましたが、結局それらの知見を自分の業務に落としこむにはやはりいくつかのハードルはあって、今日色々と聞けたからと言ってすぐに自分の業務フローがブラッシュアップされるという性質のものではないように思いました。
「CSSは難しいということにそろそろ人類は気づくべき」なんて冗談めかして言っておられましたが、美しく、理にかなったCSSを書くには、クライアントまで巻き込んでの業務フローから見直す必要があるような気もして、確かにそういう意味ではすごく難しいのではないかと思います。
お話の中で響いたことをいくつか。
構造と見た目を分離
例として上げたのはBootstrapのコンポーネントのボタンなどに関するCSSでしたが、ボタンをボタンたらしめる構造を決める記述と、ボタンの色などの見た目を決める記述は別々のCSSとして整理して、色違いのボタンなどは全て見た目側のCSSのみで記述するとかそういう感じ
コンテナとコンテンツの分離
例えばウィジェットにアバター画像を配置してそれの横幅が200pxであったとして、画像自体を200pxとするのではなく、ウィジェットが200pxで、そこに100%で画像が配置される、という風に、コンテナと、その中のコンテンツの属性は区別をする。
それらの考え方は、モジュール化して再利用する場合に効いてくる。
コンポーネント指向のCSSを
ページ、デザインカンプごとにCSSを作らない。
psdを精査して共通するパーツなどある程度把握して、それらに応じたCSSを書くようにする
セレクタは常に弱く
- IDセレクタとか、それでないとダメだという根拠が無いなら全部クラスにしといたほうがよい。
- .entry-bodyとかの大きな括りから始まるセレクタは強くなる場合が多い。CMSとか触ってるとやりがちだから気をつけて！
CSSは短く
機能に合わせてCSSは分けちゃったほうがいい。個人的には1個のCSSが画面の縦を超えたらもう黃信号だと思ってる。
リファクタリング
やり方がまずいと思ったらほっとかずにリファクタリングを繰り返す。
ドキュメント
ファイルの分割ルールとか、命名規約くらいのドキュメントは常に残しといたほうが良い
それができないなら、SMACSS,FLOCSSなど元々ドキュメントが揃っているものに従う形にする
まとめ
CSSはまだ歴史が浅く、簡単な言語だと思われているふしがあるが、要はやってることはプログラミングのようなものであり、プログラミングの設計ノウハウがきっと役に立つ。そっちの文献等も読むといいかも。
20160418追記 スライド上がってました。
谷拓樹さん
まず、CSSを設計するにあたっての考え方に少し触れ、その後CSSで実現するデザインのいくつかの手法について、具体例とその問題点を話してくれました。
小技の話
まずは横並びのメニューの実装について。
これまではliで組んでfloatが一般的だったけど、これからはflexという選択肢もあるよと。
次にアイキャッチ画像をレスポンシブで見せる際、縦長画像と横長画像などが予想外に交じるとデザイン的にイマイチになる、と言った事象について。
imgを直接置くのではなく、擬似要素などでサイズをコントロールするdivを用意して、それの背景として画像を扱う手法がいい。
その際heightを%で指定すると、親要素の縦が指定されていない構造だと縦サイズを%指定することができないので、縦横比を保って…などのコーディングは不可能。
そこで擬似要素を配置して、その擬似要素のpadding-topに縦として使いたい%を指定する。paddingに%指定した場合、padding位置の上下に関わらず親要素の横幅を基準とした%指定となる仕様になっている。それを利用した手法（一昔前の1ドットのgifを使ったスペーサー的な役目を擬似要素でやる感じ）など。
設計の話
特定の箇所だけ見た目が違うコンポーネントの実装について。例えば基本のボタンが、含まれる親要素によって微妙に背景色だけ違う、なんてとき。
.a .button{…}
なんて組みがちだけど、親要素に依存する書き方はよろしくない。この場合、
.button–a{…}
とか個別にクラスを振って、スタイルを当てていくのが望ましい。
と、されているが、それがめっちゃ多いときなど、親要素に依存した書き方も悪く無いのではないか。
button–a{…}
button–b{…}
button–c{…}
button–d{…}
と、悪戯にクラスを増やすよりは、
.a .button{…}
.b .button{…}
.c .button{…}
.d .button{…}
でもいいんじゃない？という話。
CSS変数
将来的な書き方として、CSS内で変数定義して設定値を使いまわせるようになる。
質問＆座談会
- backgroundでの実装の話。imgで似たようなこと実装できないのか
- object-fitなんてのもあるけど、IEが全く対応しないのはやはり致命的。そもそもの意味合いとして、アイキャッチ画像そのものがコンテンツとしての意味があるかと言えばそれは疑問で、imgとしてなにか意味を持っているのでなければbackgroudでの実装で問題ないと考える
- リファクタリングすべきという話があったが、そのタイミングなどの目安は
- 感覚的には100行とかになってくるともう長く感じる。ぱっと見て何のモジュールかわからないようならもうそれは書き直したほうがいいと思うが、それはもう人による。このコードどっかで見たな、が続いたらもう見なおしたほうがいいかも
- そもそもリファクタリングなんてやってる暇もないし、それでなんとか終わったらその案件にリソース割かないんじゃないかという現実がある
- プロジェクト最後にリファクタリングするのは確かに無理あるかも。もっと前の段階で手を打てればうったほうがいい
- フレームワーク使ってる？
- お二方はあんまり使ってない。ソース参考にする。TPOしだいだと思う
- 記法としてBEMとマルチクラスはどちらが
- BEMで書きつつマルチクラスにしている。再利用についてはそれほど重きを置くのではなくて、結果再利用できたほうがいいよねくらいの感じがいいんじゃ
最近の知見としてECSSなどは記述同士に関係性を持たせない書き方を推奨してる。そのほうが記述が影響しあわないし、要らなくなった記述を捨てやすい - スタイルガイドって作ってる？
- 受注案件ベースだと作ってる暇がない。谷さんは基本自社サービスのブラッシュアップで徐々に作ってはいて、もう少しで公開できそう。ツールにはrailsベースのホログラム？を使っている
- ARIAのステートが変化するようなギミックにスタイルを当てる場合、それ自体を属性セレクタにして書くか、固有のセレクタを用意するか
- 悩ましい
- （自分の質問）BASISなど、フレームワーク使おうとしたらすごくたくさんのクラスがHTMLソース側に必要となるが、HTML側のクラスは簡単にして、CSS側で全て装飾をもたせるか、フレームワーク使ってクラスが膨らむか、で悩むんだけど
- そのフレームワークを作った人間がどういう設計思想で作ったかによるかも
- （その答えに対して司会者のメガネさんが補足質問として）クラスにずらずら書くやり方はあまりよくないと少し前までは言われていたように思うけど、それは現在ではいいということになってるという認識でOK？
- やはり目的次第にはなってくるのでは。このフレームワークは作成者がPHPを見ることが多くて、CSSはCSSで完結して、PHP側でクラスを調整することで色々できるという思想で作ってるんじゃないかと思う。
フレームワークを使う場合は、作った者の思想設計を読み解くくらいの気合が必要なんじゃないか
雑感
最後の「どうしたらCSSが上達するのか」の問いに「もはや精神論」と答えていたのが印象的でした。この道の第一人者と称される人たちでも苦労は絶えないのだろうと。
とにかくひたすら無駄と矛盾をなくしていくことが何より必要なことだとお話聞いてて感じたんですが、それ自体とても難しい作業だと思うので、CSSは厄介だなあと改めて思いました。
あと、ポイントポイントで入るメガネさんの「補足」は、的確に必要な内容を補足してくれて、僕の質問にも補足して追加質問してくれたのですが、僕が言葉足らずで伝わっていなかったまさにそこを聞いてくれてとても助かりました。知人からディレクターとしても優秀だと聞いていたんですが、さもありなんと思いました。
以上、ちょこちょことメモしたものをベースに書き起こしてるので細かい文言等は実際と違うかもしれませんが、意味は取り違えてない…はずだと思うのでご容赦ください。
認識違いなどあればご指摘ください。
今日はこんなところで。