画面の向こう側

1. 390pxという現実

iPhone 13のビューポート幅は390px。世界で最も普及しているスマートフォンの一つだ。

PCで見れば完璧なレイアウトが、390pxでは崩れる。たとえばナビゲーションに並ぶ「音声」「画像」「テキスト」のラベルが、テキストの途中で改行される。アイコンとラベルの間で折り返しが起き、UIの意味が分断される。

white-space: nowrapを入れても収まらない。font-sizeを0.85remから0.78remに落としてようやく1行に収まる。0.07remの差——わずか1ピクセル程度の違いに、ユーザーの体験の境界がある。

この境界は、スペックシートには載らない。390pxの画面で指を動かして初めて見える。

2. overflow-x: hidden は解決ではない

モニターページがモバイルで横方向に「うねうね」する。overflow-x: hiddenはhtml/bodyに設定済みだった。

だが、隠しているだけで、はみ出している事実は変わらない。iOS Safariはそれを弾性スクロールで正直に教えてくれる。画面の端に指が触れるたびに、隠された要素の存在が揺れとして伝わる。

本当の修正は、はみ出す要素をなくすことだ。width: 100%とoverflow-wrap: break-wordで根本から対処する。原因を隠す設計と、原因を取り除く設計。レスポンシブ対応に限らず、あらゆる設計の姿勢が問われる場面だ。

3. テーブルが画面を突き破る

特定商取引法に基づく表記ページ。PCでは端正な2カラムテーブルが、モバイルでは「販売価格」セルに100文字超のテキストが入り、テーブルごと画面外にはみ出す。

解決策は、モバイルではth/tdをdisplay: blockに変換すること。テーブルという「器」を解体して、縦に積み直す。情報の構造は一つだが、見せ方はデバイスに応じて変わる。

「情報を変えずに器を変える」——これがレスポンシブの本質だ。伝える内容は同じでも、届け方は受け手に合わせる。

4. キャッシュもレスポンシブに

Service Workerのキャッシュを更新しても、モバイルで見た目が変わらない。CSSを修正したはずなのに、古いスタイルが表示され続ける。

原因は二重キャッシュだった。Service Workerがcache.addAll()でファイルをプリキャッシュするとき、ブラウザのHTTPキャッシュから古いバージョンを取得していた。PCでは問題なくても、モバイルSafariではHTTPキャッシュが長く残る。

fetch(f, { cache: 'reload' })——サーバーから直接取りに行く。この一行が、二重キャッシュの落とし穴を塞ぐ。レスポンシブは画面サイズだけの話ではない。ネットワーク挙動も、デバイスによって異なる。

5. ハンバーガーメニューという翻訳

PCでは5つのナビリンクが横に並ぶ。モバイルでは三本線のアイコンに折りたたむ。同じ情報を、異なる文法で伝える。言語の翻訳と同じ構造だ。

さらに、モニター未登録のユーザーにだけ「モニター」リンクを表示する。画面の向こう側にいる人の状況に応じて、見せるものが変わる。localStorage.getItem('toki-wisetag')——一つの値が、UIの姿を決める。

だが「表示する」だけでは終わらなかった。CSSでdisplay: noneを設定した要素に、JavaScriptでstyle.display = ""と空文字を代入しても、CSSルールが残って表示されない。display = "inline"と明示して初めて、インラインスタイルがCSSを上書きする。「消す」と「見せる」は、対称的な操作ではなかった。

表示できても、配置が問題だった。モニターリンクが現れると、ハンバーガーメニューが中央に押し出された。HTMLの記述順に並ぶflexboxでは、要素の追加がレイアウト全体を揺らす。解決はCSSのorderプロパティだった。モニターリンクにorder: 2、ハンバーガーにorder: 3を指定し、margin-left: autoで右寄せする。HTMLには触れず、CSSだけで配置を制御する。そして0.5remの余白を挟んで、二つの要素は初めて「そこにあるべき場所」に収まった。

レスポンシブとは、画面幅への対応だけではない。ユーザーの文脈への対応でもある。

モニターページの進化は、表示制御だけでは終わらなかった。参加条件にはWiseアカウントの作成、PWAのインストール、アフィリエイトリンクの開示——初めての人には見慣れない概念が並ぶ。ページ内に手順を詰め込めば情報過多になり、省けば離脱を招く。

解決策は、各項目にエッセイへのリンクを添えることだった。「Wiseの始め方」「PWA導入ガイド」「紹介リンクの開示」——それぞれが独立した解説記事として存在し、モニターページからワンクリックで到達できる。ページ自体は簡潔さを保ちつつ、深く知りたい人には道を示す。情報の密度を画面に押し込むのではなく、リンクという「奥行き」で解決する。これもまた、390pxの画面に対する一つのレスポンシブだ。

6. 「うねうね」という声

ユーザーは「横方向にうねうねする」と言った。開発者用語ではない、体感そのままの言葉だ。

DevToolsでは再現しない。iPhoneのSafariで、指で触って初めてわかる現象だった。PCの画面でシミュレーションするだけでは見えない問題がある。レスポンシブ対応の最後の1ピクセルは、実機でしか見つけられない。

画面の向こう側は、エミュレータの中にはいない。実際の指が、実際の画面に触れたときにだけ現れる世界がある。

7. 1000年のレスポンシブ

TokiQRは「1000年残す」プロダクトだ。だが1000年後のデバイスは想像すらできない。

QRコードはVersion 40で最大2953バイト。この制約は1000年変わらない——物理的な規格だから。紙に印刷されたドットの配列は、デジタルの進化とは無関係に存在し続ける。

HTMLとCSSは変わり続ける。だがレスポンシブの思想——「受け手に合わせて姿を変える」——は変わらない。紙に印刷されたQRコードを1000年後の誰かがスキャンするとき、その画面が何インチかは誰にもわからない。だから、どんな画面でも動くように設計する。

それが、1000年のレスポンシブだ。

画面の向こう側にいるのは、スペックではなく人だ。レスポンシブ対応とは、その人に届く形を探すことだ。