いろんなデバイスが増えて、検証コストが増大していく中、最先端な方々が検証コストを下げるための色々な手法を考えててるんだけど、実際どうやって自分の業務に組み込んでいくか、ってのが中々難しいなーと感じてた。
この特集の第1章〜3章では、最新技術動向の解説っていうよりは「イマドキの開発のやり方ってこういう背景でこうなってて実際やるならこんな感じ」って感じでコンパクトにまとめられててとても理解しやすかった。し、実際にスタイルガイド作ってみるみたいな話が直近であったので大いに参考にさせてもらった。
特に第3章、まずは仮組みで検証サイクルを回しだすとかは、まだデザインが出来てないワイヤーフレームの段階でスタイルガイド作る時に要素考えすぎなくて済んだりとか、"検証サイクルを回す様子"で挙げられている検証サイクルの順序に改めて反省したりとか。少し下記に引用しますが
コンポーネントの検証サイクルは次の3つの作業から成ります。
- HTMLの作成(修正)
- CSSの編集(修正)
- ブラウザでの検証
この小さなサイクルを守ると同時に、この作業順も順守すべきです。HTMLの作成と修正を必ず最初に行うことが、CSSの書きやすさと検証の正確な予測を可能にします。
まだ何かのスタイルを見た時にCSSでの実装を先に考えてしまうこととかがあって、よりHTMLへの意識を強く持とうと思った次第。
関係ないかもしれないけど、Web制作の勉強を始めたキッカケがブログサービスのカスタマイズだったからか、HTMLの構造を修正して解決するっという感覚が薄い気がする。おんなじような人いるかなー。