CSS Nite LP47「Coder’s High 2016」に参加してきました。
ワントラックで半日ほどずっとセッションを聴くという形でしたので、当初、あまり興味を持てない内容のときは退屈かも…なんて心配していたのですが、聴いてみると全てのセッションで話す内容がとても現実的でピンポイントで、すごくためになるイベントでした。
ただ事前に注意事項にもわざわざ書いてあったのですが、CSS Niteでは会場で打鍵音を出すのが好ましくない傾向があるようで、（実際僕はそれなりに静かめにタイピングしてたつもりだったのですが前の席の人から振り返ってじろっと見られたりしました…）ビビって音を立てないようにキーを叩いていたらタイピングが遅くなってしまい、僕個人のメモはあまり取れていません。
後々公開されるであろうスライドや動画でがっつり復習することにして、とりえあず現時点での記憶とtwitterのタイムラインを頼りにざっくりと箇条書き程度にまとめておこうと思います。twitterを追ったりしてて聴いてない瞬間もあったりするので、理解が十分でない点や、とりあえず単語メモっただけになってる箇所などご容赦ください。
twitterに割と具体的な内容と、達人たちのコメントがガンガン流れているので#cssniteのタグを追うのもかなり楽しめるのではないかと思います。
コーダー白書 2016
コーダーへの事前アンケートを集計した結果をざっくりとお話されました。
サンプル数は男性274人、女性182人（未回答3人）の合計459人
こちらの内容は以下のURLで直接ご覧になれます。
ほうほうと聴いてたのですが一番印象に残ったのはアンケート結果に基づいたペルソナの項。
イラストで表現されていましたが、なんだかすごく納得のイメージでした。
男女それぞれで職業の設定も違ったので一概に言えないのですが男性/会社員の年収が543万、女性/フリーランスの年収が350万とのことで、年収差が悲しいとかつぶやいてる人が居ましたが、税制上の金額として年収350ならむしろフリーとしては結構稼いでるほうなんじゃないの…？と僕は思ったんですけど。みんなもっと稼いでるんでしょうか。
ここからは気になったフレーズとか感想を散文的に。
イマドキのコーダー環境構築
コーディング環境についてのお話
Compass終焉 オワコン
sassも単体で使うことはなくなってきた。タスクランナーでよくね？
sassはプリプロセッサのスタンダードからCSS自体のスタンダードになった感
rubysassかlibsass、どっち？早いのはlibsass?
PostCSSがもっと早い
プラグインでSass同等の機能を追加してくイメージ、拡張してなんぼ
※単純にsassの代替ってことでもない感じで別のセッションでも触れてた
Gulp
gulpfile.jsはGitHubのREADME.mdのコピペで動く
node.js
バージョン違うとモジュールによっては動かなかったりするので、バージョン切り替えのツール使うといい
macだとanyenv ndenv
windows nodist
プロジェクトごとにnodeのバージョンを切り替える
.node-version
.npm-shrinkwrap
とかいくつかの設定ファイルをコピるだけで、プロジェクトメンバーの環境揃えられる
まとめ：イマドキのコーダー環境
1. ndenv (Mac) or nodist (Win)
2. Sass
3. PostCSS
4. gulp
5. 黒い画面
そして、プログラマは怠惰であれに習って、コーダーは怠惰であれ。環境でとことん楽しよう！
—
自分の環境は、コマンドラインからインストールしたものがどういう状態になっているのか正確に把握しているとは言い難いので、どこかでちゃんと理解しておかないと環境構築で行き詰まるなと思いました。
ハマるSVG
SVGの（ドツボにという意味での）ハマる瞬間10選
詳細は後日スライドを参照
気になったものだけメモ
イラレ書き出しの際、レスポンシブにチェックするとwidth heightが入らない
inline SVGにはz-indexきかない
HTMLで囲ってそれに振る感じで対応
chromeの最小フォントサイズ設定が有効の場合、小さくならない
アウトライン化で対応
clip-path
プリフィックスがついているとsafariで効かない
SVGタグの属性を使って対応する
ダイエットして動作軽くするには
・アンカーポイントの数へらす
・座標をなるべく整数値にあわせる
・gzip圧縮 コードの書き方を揃えるなど
sketchのプラグイン SVGOとか便利です
—
SVGは使いどころが微妙に難しかったり、使い勝手もふわっとしてたりで、実務にがっつり全力で使う機会もなかなか無いのですが、個人的には結構この手の話は楽しいなと思います。
本当に利用は必要か？デザイナーにとってのjQueryとJavascriptフレームワーク
jQueryやそのライブラリ、フレームワークなどを使うのは実際どうなのか、っていうセッション
まず結論ありきで
・jQuery含めライブラリやフレームワークは適材適所で活用
・実装内容・規模・学習コストを考えて選択
小規模のWebサイトであればjQueryで問題なし
・使いたくなければ使う必要はない
jQuery3 そろそろ使い始めて大丈夫かな〜と思ってる
通常版とslim版。用途に応じて使い分け
jQueryはどうしてもコードが密結合になりがち。
jQuery以外にも色々とフレームワークはあり。
backbone.js
angular.js
react.js
riot.js
フレームワークを使うメリット
・疎結合によりメンテナンス性が向上
・HTMLとJavaScriptとの差の吸収
・データバインディング
・コンポーネント化しやすさ
どれを選べば良いのか
・どれでもいい
・トレンドが最適解とは言えない
・トレンドは変わる
・スキルと学習コストを考慮
HTML、CSSのコンポーネント化は既に必須の知識
handlebars.js
データバインディング
Vue.js
riot.js
漢は黙ってjQuery
—
結局
・適材適所で活用
・トレンドが最適解とは言えない
あたりなのかなと思いました。
ありきたりだけどケースバイケース。
でも、最低限クリアしているべきレベルってのはありそう。
それを自分が超えられているかは疑問。
「Good bye~~ floats and “clearfix” hacks」これからはFlexboxの時代
KDDIの方がFlexboxの使い方の概要を紹介
司会者の方がなにかプレゼントをくださいと言ったらその場で、「じゃあサーバ（CPI）の使用権1年分を」と即決してじゃんけん大会。負けた。
Flexboxを使ったことがあるひと挙手→8割強
Flexboxのプロパティは実は12個しか無い。それ覚えて頑張ればOK
CMS納品の場合には顧客の更新という問題が常にある
素人が更新してもかっこよく更新できるようにしたい
Flexboxやその他CSSなどを組んだテンプレートセットを用意して、CMSのエディタ画面からボタンひとつでテンプレをまるごと配置できるような仕組みづくりは結構有効な対策
余談：
アメブロ風に大量の改行をする記述法が話題に
僕も前から気になってたけど、皆さんやはり気になってたみたいでタイムラインがざわつく
—
僕はあまり気にせずに使っているけど、一部のバージョンのAndroidやIEでの挙動を大切にしている方が割と多いことが印象的だった
esa.ioのBootstrap利用とCSSリファクタリング
Bootstrapデメリット
・CSSが汚染された状態でスタート
・独自改造する必要有
必要な機能を整理しよう
自分用のmixinライブラリを作ったりとか
ruby-sass libsassは環境にあわせて
やっぱりlibsassが早いので縛りがないならこっち
PostCSSはsassの補助ツールとして使うのがいいのでは
このセッションあまりメモ取れていなかったのでtwitterからスライドの文言を引用
CSSリファクタリングの方針
・独自のコンポーネント化
・コンポーネントの粒度の見直し
・命名の見直し（BEM、MindBEMding）
・レイアウトにFlexboxを使ってみる
GitHubを利用してリファクタリングを進めた
GitHubを利用したリファクタリング
1.GitHubの利点
2.実際の進め方
3.セレクタ命名規則とコンポーネント化
4.脱Compass、Autoprefixerの導入
GitHubの利点プルリクエストを使ったコードレビュー
・部分ごとに改善し、プルリクエスト（PRs）を作成できる
・PRsされたコードに対して直接コメントできる
・やりとりがログとして残る
・Slackにも通知されるため、かんたんな相談はSlackで行う
オワcompass言いたいだけ問題
CSSフレームワークの特徴
メリット
・基本的なUIが揃っている
・CSSの知識がなくてもUIを構築可
・CSSフレームワークが共通言語に
デメリット
・CSSが汚染された状態でスタート
・独自改造する必要有
・古いバージョンをずっと使うことになるかも？
まとめ
・フレームワークを読み込んだだけでは、何も解決しない。ちゃんと使ってこそ意味がある。
・フレームワークを使うなら、敷かれたレールを走る
・ツールは必要に合わせて選定する
・メンテナンスしやすいCSSを書く
・esa.io は Bootstrap を共通言語にして効率よく開発できた
・作り上げたCSSの見直し（清書）も必要
- セレクタ詳細度
- コンポーネント粒度
- CSSの書き方
モダン日本語フォント指定
昨今のシステムフォント事情や游ゴシック問題について紹介
游ゴシックはmac、win共通のフォントっぽいけどウェイトの扱いが違ったり、chromeでの挙動がおかしかったりなど、実際には指定すれば見た目が揃う、というわけではない
游ゴシックのウェイト問題の有効な対処法として@font-faceを用いてオリジナルフォント化する方法を紹介
その方法がめんどくさすぎて、タイムラインでは諦める人が続出。
僕も正直、そこまでやるほど游ゴシックにこだわりは無いよね…とは思いました。
結局スピーカーさんオススメの指定はこうｗ
html {
font-family: sans-serif;
}
まとめ
・Windowsの游ゴシックにはMediumを使おう
・@ font-faceでオリジナルのフォントセットをつくろう
・@ font-faceのlocal()にはChromeのためにフォントファミリー名も併記しよう
Enduring CSS
CSS設計の一つの案であるEnduring CSSを紹介
機能ごとに名前空間で分類して、モジュール化は名前空間単位で行う設計思想
個人的には一番興味深い話だった。
迂闊なこと書いて間違ってたらアレなので、スライド（を引用したツイート）から引用
なぜCSS設計論が必要なのか
・どのようにでも書ける
・知らないスタイルが当たる
・上書き地獄
・チーム間での意思疎通
→ OOCSS, SMACSS, BEM
モジュール化・命名規則・継承的な話で全て解決するか？
・どうモジュールを切ればいいか？
・class名をどうつければいいか？
・複雑になってしまう
Enduring CSS とは
・Ben Frain の著書
・Enduring: 長続きする、永続的な
・設計方法論＋アドバイス集的な内容
ECSSいわく、自分には既存の設計論がマッチしなかった
・複雑になりすぎでは？
・サイトがスケールしたら破綻するのでは？
・パフォーマンス突き詰め過ぎでは？
ECSSの基本的な考え方
・全体で１つとして考えない
・分けて考える
ECSSでは、同じようなものも別物にするのはなぜか？
・その方がわかりやすい
・複雑化を防ぐことができる
名前空間：モジュールを名前空間でグルーピングする
名前空間の分け方例
・CMSで出してるテンプレートが違う
・ここだけWordPressで出してる
・サイト全体で共通
・管理する部署が違う
アセットの分離：名前空間ごとに読み込むCSS、JS、画像類を完全に分離
分離すると何が嬉しい？
・CSS、JS、画像の干渉を防げる
・名前空間単位でまるごと消せる
・どのファイルをいじればいいのか明白
・どこにファイルを置けば良いのか明白
例えば、汎用的な名前にしたとする
・モディファイアを多様化して複雑化
・どこで使われているかわからない
・結果CSSを変更できない
・当然このモジュールのCSSは消せない
・似たのが出たら2をつける？
・使い分けの把握が困難
まとめ
・ECSSは「分けて」考える
・だからいくらでもスケールできる
・管理と名前付けにシンプルさをもとめる
・無理のない管理を実現する
・ミニマムなCSSを目指すものではない
・最高のパフォーマンスは求めていない
ECSSを実際に使ってみてどうだったか
・名前付けに頭を悩ませる事が減った
・怖くてさわれないことを避けられそう
・管理が別れるサイトで特に有効そう
・ビルドをがんばらなければならなさそう
・一人でCSSを管理している場合はあまり活かせないかも
CSSにコメントは必要か
設計思想ありき 補足のために入れることはなくていいと思う
modifierとして、WAI-ARIAを使う選択肢
—
機能単位で名前空間を定義して、その中でモジュール化を行うという考え方は、昨今はNGとされがちなページやデザインカンプごとによるCSSの分類を広義に肯定する考え方のように感じました。
昨今のCSS設計のスタンダードはいかに効率的にコンポーネント化、モジュール化を行うかという視点で洗練されてきており、その手法にはもちろん様々なメリットや理由があり、それはECSSも同様で、一概にどちらが絶対にいいということはなく、与えられた条件に適したものを都度選んで行くことだ大事、ということなのだと思います。
要はケースバイケースと…
フロントエンドからのテクニカルディレクション
フロントエンド周りのテクニカルディレクションについて語ってくれました。
以下箇条書きでメモ
テクニカルディレクションは、向いてる人がやればいいんじゃない
デザイナーが独創的なグリッド作り始めたら黄信号
フロントエンドが広がってる
適材適所で技術を使いましょう的な
対応環境はポケモンGOを基準にすればいい
１タスク１チケットが原則
例えばトップのデザインのスレに下層ページのこととか書く人がどうしてもいる
２ちゃんあたりでは叩かれる行為（スレ違いはダメ？）
チケット管理ツールとチャットの使い分け
・フロー or ストック
・簡単な質問はチャットツールで
・エビデンスがいるような質問はチケット管理で
見積もり
・基本的には正確に見積もれない
・Webアプリだと50画面くらいでざっくり2人月
※状態が50ってことで、純粋に画面数ってことではない。
スケジュール
・十分な開発期間があるか
・デバッグ / 修正などの期間があるか
・遅延した場合はどうするか
小林「普通伸びますよね」
西畑「普通そうですが、伸びません」
・デザイン提供が遅れたらどうするか
西畑「これも伸びません」
追加要件・仕様変更
・追加工数
・追加お見積
この辺は後半になってワイワイと盛り上がってきます
まとめ
・ディレクション次第でプロジェクトは失敗も成功もする
・フロントエンドでできることを増やせば成功率はぐっと上がる
—
理想はこう、でも、だいたいそうはならないようねってオチがちゃんと着くという、とても現実的で参考になるセッションでした。
こういった場でスピーカーをやるようなレベルの方達でも、規模の差こそあれ自分らと同じような追い込まれ方をして、都度対応を迫られてる感じの話聞くと安心します。
とりあえず理想はこうっていうのは頭に置いて、なるべくそれに近づけるように都度頑張るしか無いですよね。
個人的感想
僕は勉強会と言えばWP関連が多くて、いわゆる「クラスタ」の違うイベントに初めて出た気がするのですが、仕切ってる人々も、内容も結構違ってなかなか新鮮でした。
WP界隈にも有名な方がたくさんいらっしゃいますが、恐らくこちらはこちらで同じように有名な方がいらっしゃって、twitterを見てると登壇者には一定のファンらしき人なんかもいて、それを自分が全く知らないのが不思議。あふれる異邦人感。
もちろん僕が知らないだけで、お話聴いてみると当然のようにみなさんすごい方ばかりで、自分がそういう人をよく知らないってことのほうがおかしなことなのか？と感じたりもして。僕は知識を求めるにあたっての広さのようなものが足りないのかもしれないです。
なんというか、Web業界は広そうで狭い、と思いきやパラレルワールドがたくさん存在していて、結果広い、といった気分。
色々と奥が深い。