なぜウェブは Pixel Perfect を追求すべきではないのか

We’re always optimizing for whatever’s most important to us right now

Pixel Perfect が本当に重要なときだけそれを気にすべきであり、そうでなければ往々にして双方にとって損な結果になる。

この問題には、根本的な原因が2つあると思う。

なぜ平面デザインはウェブにそのまま当てはめられないのか

平面デザインは通常、固定されたサイズとレイアウトを前提にしており、視点がまったく異なる。フォントも pt のような固定サイズを使って組版・設計することが多い。

しかしウェブは本質的に、さまざまなインタラクションとサイズを持っている。

フォントサイズやフォントファミリーも、ユーザーの設定の影響を受ける。（よほど諦めて文字を画像として出力するのでない限り）

いったん Pixel Perfect の発想を持つと、製品に反映されるのは特定のサイズ向けの最適化であって、複数のデバイスに適応するための最適化ではなくなる。

たとえば CSS Grid の auto-fill と auto-fit を使って、「画面（またはコンテナ）の幅を埋める」レイアウトを実現するには、こんな書き方ができる。

ある状況では、特にワイドスクリーンの利点を活かしたいときに、この種の UI はとても有用だ。

しかしこのような UI は、デザインカンプの中で明確に定義するのが難しい。とりわけ、ウェブ UI 出身ではないデザイナーにとってはなおさらだ。ここで Pixel Perfect を追い求めると、むしろユーザー体験としてより良い選択肢をそのまま捨ててしまうことになる。

テーブル設計は大きなテーマだ。僕は以前の記事で書いたことがあるが、ウェブでテーブルを設計するにはいくつか注意すべき点がある。たとえば、

一般的に、文字は左揃え、数字は右揃えにする
数字が変動する場合は、別途 font-variant-numeric: tabular-nums を追加することで（フォントが対応していれば）、数字の変化によって幅が揺れ続けるのを防げる

こうした細部は、デザイナーが理解しておらず、開発者も気づかなければ、実装されないままになる可能性がある。

CSS における vh/vw は実はとても便利な単位だが、Pixel Perfect の発想に縛られていると、最後は手早く済ませるために固定値をそのまま書き込むだけになってしまうかもしれない。

iOS Safari では、アドレスバーをどこに表示するか選べるし、iOS 12 以降にはいわゆる Safe Area を利用したり、レイアウト効果に活かしたりできる。こうした場合、あらゆるデバイスを一つひとつ列挙するのは、開発にも設計にも大きな負担となる。

双方が何を目的としているのかを知る必要がある。デザイン側は、デザインカンプの UI を完璧に再現したいと考えている。一方、開発側は、保守しやすく、自適応的な方法で UI 要件を満たしたいと考えている。

僕たちが本当に欲しいのはデザインシステムだ。いくつかの余白、間隔、フォントサイズのルールさえ定義しておけば、さまざまなデバイスに適用できる。

RWD は今もなお有効であり続けている。CSS はますます進化していて、10年前と比べれば、これをきちんと実現するのはずっと簡単になった。

最近、僕は Design Engineer の jhey の X をよく追っている。現在は Shopify で Design Engineer を務めており、以前は Vercel や Google にいた。

彼の CSS はまさに達人級で、多くの UI アニメーションやインタラクションは、CSS の動向を長く追い、さらに創造性を持っていなければ実現できない。まさに彼が CSS に精通しているからこそ、ウェブ上で生き生きとした表現を作れるのだ。

僕は、理想的な UI デザイナー（ウェブにおいて）は、少なくとも CSS に精通しているべきだと思う。ただ、台湾ではこれを実現するのは難しいかもしれない。

前職では、かなりウェブ UI に詳しいデザイナーたちと一緒に仕事ができた。CSS を書くのは確かに面倒だったが、とても面白く、貴重な経験だった。