DevTools+PerfectPixelで爆速コーディング

投稿日
投稿者
嶌田 喬行
カテゴリー
CSS, HTML

ネコメシでは週に１回、持ち回り制で勉強会を開催しています。各々が気になっているトピックについてスライドを作って、30分～1時間くらいの発表を行います。

先日の勉強会にて、コーディング作業高速化について発表したので、その内容を公開します。拙速が大事ということで、スライド貼っ付けただけで、説明もなにもなしですが…。

スライドに説明文を追記しました (2019-07-18 22:04)

スライド

https://speakerdeck.com/tsmd/devtools-plus-perfectpixeldebao-su-kodeingu

内容

Chrome DevTools と PerfectPixel という Chrome 拡張機能を使って、爆速で HTML/CSS のコーディングをするご提案です。

コーディングを２倍速にしよう！　という思い付きで検討した手法です。計測していませんが、ほんとうに倍速くらいになると思います。

やり方は次のとおり。

  1. HTML はふつうにコーディング
  2. PerfectPixel 拡張機能を使って、ブラウザ画面にデザインカンプをかぶせる
  3. DevTools 上で生 CSS を編集する

生 CSS というところがポイントです。プリプロセッサを使いません。

PerfectPixel は、ブラウザ上に画像をオーバーレイ表示できる拡張機能です。デザインカンプをかぶせて表示して、コーディング結果とデザインカンプのズレを確認する用途で使ったことのある人も多いでしょう。

拡張機能のダウンロードは以下から。

PerfectPixel

Chrome DevTools は、どなたも知っている開発者ツールです。とても高機能です。HTML コーディングの文脈では、DOM ツリーを見たり、HTML や CSS を一時的に編集して結果を見る用途に使われています。

リロードすると、編集した内容は消えてしまう……と思いがちですが、実はローカルファイルを直接編集できるのです。Workspaces 機能を使います。

今回ご紹介する手法は、PerfectPixel と、DevTools の Workspaces 機能を組み合わせたら、とんでもないことが起こるのでは……？　と思い編み出した手法です。

勉強会ではデモを披露しました。

モタついてしまったので、もっとクールに演出できるよう準備すればよかった。

これまでのワークフローと、これからのワークフローのビフォーアフターを説明します。まずは、これまでのワークフローの説明です。

コーディングを始めるにあたり、まずデザインカンプを見ながら、HTML の構造を考えます。

どのような文書構造にしようか？　どの単位でモジュール化しようか？　などと考えています。

（スライドの小さい矢印は、直接の作業対象ではないが、参照していることを意味しています。）

次に、その考えを HTML に落としていきます。HTML はレイアウトや CSS に依存して書き方を変えなくてはいけません。したがって、書かれる CSS を予測して HTML を書く作業を行います。

CSS を書く時が大変です。次のような内容を相互にスイッチングしながら次々にこなしていく必要があります。

  • HTML を参照しながら CSS に相対するセレクタを記述する
  • カンプからマージン、文字サイズ、行高やカラーコード等を計測する
  • 計測した値をまじえ、スタイルを記述する
  • 結果をブラウザで確認し、表示が正しいかどうかを確認する
  • カンプとの表示ズレを検証する
  • CSS を修正する

これまでのワークフローの問題点は、スイッチングコストと手戻りのリスクです。

先に紹介した通り、CSS を書く際のスイッチングコストがハンパではありません。作業環境のディスプレイを大きくするとか、Live Edit 的な外部の仕組みを使ってコストを削減するよう努めてはいましたが、それでも無視できないくらいの無駄が生じていました。

次に、DevTools と PerfectPixel を使ったワークフローの説明です。

カンプを見て HTML を書くところまでは共通です。

ここまで共通です。CSS を予測しながら HTML を書かないといけないことには変わりありません。

ここはここで、何とかしたいんですけどね……。別の機会に譲ります。

提案するワークフローが効いてくるのは、次の CSS を書く作業です。

おや……？

（ピカーーーーッ！！）

まぶしい～！

ブラウザ、カンプ、HTML、CSS が一体となりました。ブラウザ上にカンプを表示し、DevTools を使って CSS の編集をする、というシンプルなフローになったのです。

この手法の何よりのメリットは、スイッチングが起こらないことです（ゼロは言い過ぎかもしれません）。

作業対象の HTML も、目標となるカンプも、すでにそこにあります。そもそもブラウザ上で動いているから、ブラウザで確認する必要もありません。

必然的に手戻りは起こらないのです。

仕組みはとても単純です。

  1. 開発者は DevTools に対してスタイルの編集をする
  2. DevTools に与えた変更が、ブラウザ画面に即座に反映される
  3. DevTools はローカルファイルに変更を保存する（Workspaces 機能の恩恵のぶぶん）

多くの現場が Sass などのプリプロセッサを使っています。このフローに Sass を組み込めるのでしょうか？

制約はありますが、使えます。Sass に限らず、Stylus や LESS などのプリプロセッサでも同様です。

CSS を直接編集していたときとは違って、DevTools は CSS ファイルではなく Sass のファイル（スライド上は style.scss）です。

Sass コンパイラの watch 機能（変更監視機能）によって、自動的に CSS ファイルに出力されます。DevTools は CSS ファイルの変化を検知し、ブラウザに即座に変更が反映されます。実際は、コンパイルの時間だけ多少のディレイはあります。

この環境の作り方の説明です。

  1. PerfectPixel をインストール する
  2. 開発中のページを開く
  3. DevTools を開き、Workspace を設定する
    • Sources タブ → Filesystem パネル → Add folder to workspace
    • ドキュメントルートにあたるフォルダを選ぶ
    • 読み書き権限を求められるので、許可する

Sass に適用するときには、いくつか注意が必要です。

  • Source map の出力が必要です。ブラウザが読み込んでいる CSS から、元の Sass ファイルが辿れる必要があるためです。Source map の出力設定はどのツールにもあるはずです。

  • Sass ファイルに Workspaces 経由でアクセスできるようにする必要があります。つまり、Sass ファイルにも URL ベースでアクセスできる必要があります。言い換えてもわかりにくいですね…。

  • すこし手痛い制約として、DevTools の Elements タブ上で行われた変更は、Sass ファイルへ反映されません。Source タブでスタイルを編集する必要があります。メリットがずいぶん薄れてしまいますね。でも、Elements タブからスタイル宣言の該当箇所に直接ジャンプできます。それだけでも十分大きなメリットです。

ところで、

HTML から CSS のセレクタを抽出する作業って、面倒くさくないですか？

Sass などのプリプロセッサは、ネストで書くことで作業のわずらわしさは軽減されていますが、それでもわたしは面倒です。

そこで、この作業を楽にするツールを作りました！ CSS Scaffolder です。

試しに、以下のコードを HTML 欄に入力して「Process」ボタンを押してみてください。

<button class="Button">
  <span class="Button__inner">
    <span class="Button__icon">
      <img src="" alt="">
    </span>
    <span class="Button__label">
      OK
    </span<
  </span>
</button>

似たようなツールは既出なので、あっそう、って感じかもしれません。もうちっと有用に・使いやすくチューニングしていくつもりです。

もうひとつ補足です。

DevTools でマルチカーソルが使えるって知っていましたか？

Sublime Text が最初に実装し恋する開発者が続出し、各エディタに爆発的に普及したあの機能です。実は DevTools のソースエディタにも実装されています。

Sources タブの中で Ctrl/Cmd+D を使ってみてください。戻すときは Ctrl/Cmd+U です。

Alt/Option+ドラッグでマルチカーソルの選択なんかもできます。

おわり。

考察

既存ツールの組み合わせに気づいたという話なので、すでに実践されている方もいることでしょう。

スライド中にも触れていますが、プレーンな CSS を書くと最大のメリットを得られる手法です。Sass などのプリプロセッサを使う現場が主流でしょうから、惜しいところです。

ですが、これを理由に Sass 脱却に踏み切る選択肢も、十分にアリと考えています。脱却を後押しする状況が整ってきているのも理由のひとつです。

  • CSS カスタムプロパティ（いわゆる変数）が IE, Edge を除くブラウザで実装されている
  • BEM で書いていれば、CSS ネストの有難みはそんなに無い
  • ファイル分割はネイティブ @import ルールでも可能

ファイル分割によるパフォーマンス低下の懸念は、デプロイ前に、PostCSS を使って @import ルールをガッチャンコすれば解決です。

Sass 利用モチベーションのひとつである、ミックスインが使えないのはちょっとアレですね～。よいソリューション求む。

社内からの情報

Zeplin を使うとより良いワークフローが築けるのでは？　とのアイデアが出ました！　Zeplin のデスクトップアプリは、デザインカンプを独立した半透明ウィンドウとして表示できる機能があり、PerfectPixel の代替となりうる。さらに Zeplin 側の機能として、要素に当てるべき CSS コードを提示してくれるので、さらなる時短につながりそう。

なるほど試してみたい！

みなさんも、ぜひお試しください。