iPhone Duoの外側ディスプレイは、ピクセル密度3で382 x 578 CSSピクセルです。最初の実機チェックで気づいたのは、ウェブサイトがディスプレイを満たしていないという事実でした。右側にはコンテンツの隣に背景色の帯が走り、左には暗い余白が残りました。ディスプレイは小さく、余白はすべて無駄な面積です。
原因は自前のCSSのバグではありません。Safariは、カメラが置かれているDuoの右側表示ゾーンを禁止領域として扱います。つまり382ピクセルのデバイス幅レイアウトでは、ページはそこに描画できません。右の帯はまさにこの禁止領域です。他のウェブサイトでも同じ挙動を確認しました。Safariの仕様であり、ページ側の欠陥ではありません。
さらにアドレスバーが、サイトの幕の色の一部を拾いました。これもSafari 26の挙動です。ブラウザはページから色をサンプリングしてバーに適用します。この二つが重なり、小さなディスプレイからさらに領域を奪いました。
なぜviewportトリックが必要か
全面表示への道は、慣例的なルールへの意図的な違反から始まります。デバイス幅のmetaタグの代わりに、460ピクセルの固定レイアウト幅を設定します:
<meta name="viewport" content="width=460, initial-scale=1, viewport-fit=cover">
Safariはページを460ピクセル幅でレンダリングし、382ピクセル幅の視野へ縮小します。この縮小は構想の一部です。レイアウトが視野より広いため、ページは右端の禁止領域の下まで描画します。ディスプレイは完全に満たされます。
この状態をJavaScriptで強制することはできません。visualViewportオブジェクトは読み取り用のインターフェースで、スケーリングの値は読み取り専用です。ズームしたければmetaタグで宣言するしかありません。
修正の中身
固定viewport metaだけでは足りません。それが生む二番目の結果へ、改修の残りが対応します。レイアウト幅460と視野382は78ピクセルずれます。この78ピクセルはパン領域です。対策なしでは指で横にずらせてしまい、そこにあるものはタップできません。四つの作業面を文書化しました:
- 全面バンド: viewport単位で動くバンドはレイアウト幅に揃えなければなりません。DuoではSafariがこの単位を、周囲のコンテナと異なる形で解決します。そのためJavaScriptでレイアウト幅をCSS変数に入れ、すべてのバンドをそれに換算します。実機での測定:変更前は幕バンドが382ピクセルで走り、セクションは460で組まれていました。変更後はレイアウトに追従します。
- アドレスバー: Safari 26は固定された全面要素から色をサンプリングし、バーに適用します。不透明な要素が端に張り付いている限り、バーはどんな色でも残ります。該当する要素が二つありました。構造オーバーレイとエフェクトのキャンバスです。両方とも固定からセクション基準に変えました。その後バーは再び折りたたまれました。
- ダイアログとメニュー: すべてのダイアログ、メニュー、ライトボックスは幅をレイアウト幅ではなく視野に合わせ、視野に揃えて配置します。変更前はダイアログの半分がパン領域に達し、そこにはタッチイベントが届きません。メニュー項目もライトボックスの操作も、テストに一切報告されないまま反応しなくなっていました。
- 横ずれ: パン領域に描き込むレイヤーは、ページがずらせる感覚を作ります。ゴールドレインのエフェクトキャンバスはセクション基準で、視野幅に固定して動きます。
意識的に受け入れたSafariの特性が一つあります。ネイティブのダイアログのフォーカス手順が、開くときにページ先頭をパン領域へスクロールします。ダイアログをモーダルメソッドで開くのをやめ、独自のスクロールロックを持つ通常レイヤーとして開くことも、修正の一部です。
なぜ小さな問題ではないのか
このディスプレイに五日かけました。修正が長引いたからではなく、落とし穴が隠れていたからです。ヘッドレスブラウザのテストは緑で通ります。Chromiumはviewport単位をレイアウト幅に対して解決し、パン領域を知らないからです。実機でしか起きないエラーは、そこには見えません。すべての修正を本物のDuoで先に検証しました。
外側ディスプレイに向き合う理由もあります。私たち自身もDuoを使っており、日常では大半の時間閉じたままです。つまり外側ディスプレイが、ウェブサイトとの最初の接点になることが多い。そこで余白を見せることは、第一印象を手放すことです。
どんな障害パターンがあるか
文書化して修正した障害パターンはこれらです:
- 右の帯: Safariは右の表示ゾーンをページコンテンツに対して封鎖します。修正:460の固定レイアウト幅を持つviewport meta。縮小時にページは禁止領域の下へ描画します。
- ページが横にずれる: レイアウト幅が視野より大きいとパン領域が生まれます。修正:死んだ帯にコンテンツを置かない。ダイアログとエフェクトは視野幅に固定。
- メニューがタップできない: ダイアログがレイアウトビューポートで中央揃えになり、パン領域に達します。そこにはタッチイベントが届きません。修正:ダイアログを視野に固定。
- アドレスバーの変色: Safari 26は端にある固定の全面要素から色をサンプリングします。修正:端に不透明な固定全面要素を置かない。
Duo外側ディスプレイに関するよくある質問
iPhone Duoの外側ディスプレイは何CSSピクセルですか?
閉じた状態でピクセル密度3の382 x 578 CSSピクセルです。開いた状態では、ウェブサイトは761ピクセル幅以上でデスクトップ版を使います。
382ピクセル向けにサイトを作り直す必要がありますか?
モバイル表示は残り、補完されます。固定viewport metaがスケーリングを担い、記事の四つの作業面がその結果を受け止めます。固定の全面要素もviewport基準のバンドもなければ、作業は少なくなります。開いたDuoは761ピクセル幅以上でデスクトップ版、縦持ちでは626ピクセル幅です。
なぜテストではこのエラーが見えないのですか?
Chromium系のテストはviewport単位をレイアウト幅に対して解決し、レイアウトと視野の間のパン領域を知りません。エラーは実機にしか存在しません。Duoを持っていれば実機で検証してください。なければブラウザのオーバーライドでスケーリングを模擬できますが、単位の解決方法は別途確認が必要です。
既存サイトの適応にはいくらかかりますか?
構造によります。全面要素が少なくダイアログが中央揃えのサイトなら一日で適応します。固定エフェクトレイヤー、独自のダイアログシステム、viewport基準のバンドがあるサイトは、実機テスト込みで二〜三日かかります。私たちのサイトは後者で、ディスプレイの挙動をゼロから文書化する必要があったため五日かかりました。その調査は完了しており、適応を阻むものはありません。







iPhone Duo: 9:16だけではもう画面を埋められない
マーケティングにおけるAI:最新の数字