# Astroの図版を自分のサイズで描かせ、タップで拡大できるようにする — 固有幅・ネイティブダイアログ・@2x
> Astroでwidth:100%が256pxのスクリーンショットをぼかしていた理由と、ネイティブダイアログでスマートフォンでも図版が読めるようになるまで。設計を正したのは7つの計測でした。
- Source: https://oharu121.com/ja/blog/astro-figure-intrinsic-width-native-dialog-2x-density/
- Published: 2026-08-15T09:17:03+09:00
- Tags: Astro, CSS, Web API
---
## はじめに
このサイト自身の目次サイドバーのスクリーンショットを記事に入れたところ、ひどい見た目で返ってきました。サイドバーは細長い UI ですが、記事の中では本文カラムいっぱいの幅まで引き伸ばされ、中の文字がにじむほどぼやけ、他の内容を画面外へ押し出すほど縦に伸びていました。それを眺めているうちに、もう半分の問題にも気づきます。どの図版も大きくする手段がないのです。読者がもっとよく見たいと思っても、できるのはページ全体をピンチズームすることだけでした。
そのスクリーンショットはリリース 1 本分のあいだ公開され続け、誰からも指摘されていませんでした。撮影そのものにも問題はありません。**ぼやけの原因は、サイト上のすべての図版に適用されていた 1 つの CSS 宣言でした**。そして被害が出るのは、細い図版だけだったのです。
ぼやけの修正は、結果的に小さい方の話でした。より大きな発見は同じコンポーネントの反対側にありました。**引き伸ばされたことが一度もなく、そのため問題なく見えていた図版こそ、誰にも読めていなかった**のです。本記事ではその両方と、途中で明らかに正しいと思えたのに計測すると間違っていた 7 つの設計判断を扱います。
## 1 つの宣言がすべての図版をカラム幅まで引き伸ばしていた
このサイトの図版はすべて 1 つのコンポーネントを通ります。そのコンポーネントには、包んだ相手が何であれ適用される規則が 1 つだけありました。
```css title="src/components/article/Figure.astro"
.frame :global(svg),
.frame :global(img) {
display: block;
width: 100%;
height: auto;
}
```
蓄積された記事の大半では、これは表に出ません。イラストの幅は 1,100 から 1,774 ピクセルで、本文カラムは 662 ピクセルなので、**この規則は縮小しか起こさず、それには何のコストもありません**。問題のサイドバーのスクリーンショットは**幅 256 ピクセル・高さ 836 ピクセル**だったため、同じ規則が 2.48 倍に引き伸ばし、662 × 2,161 にしてしまいました。
興味深いのは、ブラウザに与えられていた材料の方です。Astro は元ファイルから `srcset` を生成しますが、256 ピクセルの元ファイルからは候補が 1 つしか出てきません。
```html
```
**つまりブラウザは 256 ピクセル分の画像をダウンロードし、CSS から 662 ピクセル分のレイアウトを埋めるよう指示され、それ以上大きいものを取りに行く先を持っていなかったわけです。**私が見ていたノート PC はデバイスピクセル比が 2 だったので、実際の必要量は 1,324 デバイスピクセル、それを埋めていた実データは 256 ピクセルでした。
*Figure — StretchedRaster: 同じファイルを 2 つの規則で描いた場合。棒は描画幅で、その下の一行が、くっきり見えるかどうかを決める数字です。*
**リポジトリの中にこれを見張っているものは何もありませんでした。**ロケール間チェックは、英語で参照されている図版が日本語と繁体字中国語でも参照されていることを確かめますが、ファイル自体は見ません。フィットチェックは各図版をブラウザで描画してラベルが枠からはみ出していないかを測りますが、対象は SVG コンポーネントだけです。翻訳されたテキストを持つのがそちらだからです。**ラスターには専用のチェックがなく、引き伸ばされたスクリーンショットと本番の間に立っていたのは、誰かが気づくかどうかだけでした。**
## サイズを宣言せず、導出する
修正はバグより小さいものでした。Astro は処理したすべての画像に `width` と `height` 属性を出力します。ビルド時にファイルの実寸を知っているからです。CSS の幅を `auto` にすれば、ブラウザはその数字を使います。
```css title="src/components/article/Figure.astro"
.frame :global(img) {
display: block;
margin-inline: auto;
width: auto;
max-width: 100%;
max-height: 56rem;
height: auto;
}
```
もう一つの案はコンポーネントに `width` プロパティを持たせることでしたが、私はそれを見送りました。このブログは記事ごとに 1 つのフォルダを持ち、その中に 3 つのロケールファイルが入ります。つまりマークアップ側の幅は 3 回書かれ、素材と手作業で同期を取り続けなければならない数字になり、整合性チェッカーにもそれを取り締まる規則を足す必要が出てきます。`width: auto` なら**サイズが記録される場所はファイルだけ**になり、ファイルを差し替えればレイアウトもついてきます。
最初に間違えたのは高さの上限でした。エージェントの初期値は `min(48rem, 85svh)` で、図版がウィンドウより高くなるべきではないという理屈でした。高さ 724 ピクセルのブラウザウィンドウで測ると、幅 256 のスクリーンショットは **188 × 615** に抑え込まれます。リサンプリングを直したばかりの画像を、もう一度リサンプリングしたわけです。**可視区域に追従する上限は、「決して引き伸ばさない」を「常にリサイズする」に戻してしまいます。**現在の値は一律 `56rem` で、蓄積された記事のうち最も高い 836 ピクセルの図版を素通しし、それでいて異常な書き出しは捕まえます。
最後の一点は見た目の問題です。幅 224 ピクセルのスクリーンショットが 662 ピクセルの枠線付きの箱の中央に置かれていると、それ自体が間違いに見えます。そこで枠はラスターに合わせて縮みます。コンポーネントは中身をスロット経由で受け取るため、包んだ相手が写真なのか図版なのかをサーバー側では判断できません。判定は CSS で行います。
```css title="src/components/article/Figure.astro"
.figure:has(.frame img) .frame {
width: fit-content;
max-width: 100%;
margin-inline: auto;
}
```
## `@2x` — `width: auto` には「密」と「大」の区別がつかないから
固有幅からサイズを決めても、1 つだけ解決しない問題が残ります。**2 倍密度で 224 ピクセルとして表示されるつもりの 448 ピクセルのファイルは、CSS から見れば、448 ピクセルで表示されたい 448 ピクセルの絵と区別がつきません。**合図はどこか別の場所から来る必要があり、いちばん安上がりな置き場所はファイル名です。`@2x.webp` という名前のラスターは意図した表示サイズの 2 倍で保存されており、コンポーネントが `zoom: 0.5` で半分にします。
この規則の中の 2 点は、推論ではなく計測で見つかりました。そしてどちらも無言で壊れる種類のものです。
セレクタは 2 通りにマッチする必要があります。`astro build` はファイル名の語幹をそのままアセット名に書き込み、`/_astro/sidebar-rail@2x.HASH.webp` を生成します。しかし開発サーバーは違います。パスをクエリパラメータに載せたエンドポイント経由で画像を配信するため、**`@` はパーセントエンコードされて `%402x` になります。**生の形だけにマッチする規則は本番では動き、ローカルでは何もしません。取り得る中で最悪の組み合わせです。実際に最初はそう書かれていて、**それが見つかったのは、ブラウザ上の数字が動かなかったからでした。**
2 つの上限は `zoom` の下で異なる振る舞いをします。片方だけが 2 倍にされているのはそのためです。
| 宣言 | 実際に効く位置 |
| --- | --- |
| `max-height: 56rem` | 画面上の 448 ピクセル。絶対長は要素自身の半分になったピクセルで解釈されるため、上限は書いてある値の半分の位置に来ます。 |
| `max-width: 100%` | 枠の実寸幅。パーセントは包含ブロックに対して解決され、そちらは zoom されていないため、書いてあるとおりの意味になります。 |
最初の試みは両方を 2 倍にしていました。**両者は同じようには振る舞わず、その代償として画像が狭めた枠から 70 ピクセルはみ出しました。**規則が動くようになってから、元のスクリーンショットを 2 倍解像度で撮り直してもらいました。現在は 448 × 1,672 で、224 × 836 で描画され、必要な 448 デバイスピクセルを 448 の実データで埋めています。
## 問題なく見えていた図版こそ読めていなかった
ここまでがサイズの話で、深刻な影響を受けたファイルはちょうど 1 つでした。もう半分の作業は、エージェントが「実際に縮小されている図版にだけ拡大の操作を出す」という案を出したところから始まります。すでに原寸で表示されているものを拡大しても読者には何も約束できない、という理屈でした。
私はそれを却下しました。**図版は原寸で表示されていても、中の文字が小さすぎて読めないことがあります**。そしてそれはスクリーンショットと同じくらい、いやそれ以上に図版に当てはまります。決め手になった計算を示しておく価値があります。記事の残りが乗っている数字だからです。
このリポジトリの図版はすべて 800 単位の `viewBox` 上で作図され、他のすべてと同じ 662 ピクセルの枠に描画されます。デスクトップでの倍率は 0.795 です。390 ピクセルのスマートフォンでは枠の幅は 324 ピクセルになり、倍率は 0.405 になります。実際に使われているラベルサイズを通してみると、こうなります。
| 作図時の `font-size` | 使用箇所 | デスクトップ（0.795 倍） | スマートフォン（0.405 倍） |
| --- | --- | --- | --- |
| `9px` | 20 | 7.2 CSSピクセル | **3.6 CSSピクセル** |
| `10px` | 136 | 8.0 CSSピクセル | **4.1 CSSピクセル** |
| `11px` | 135 | 8.7 CSSピクセル | **4.5 CSSピクセル** |
| `13px` | 78 | 10.3 CSSピクセル | **5.3 CSSピクセル** |
図版はこのサイトで最も丁寧に作られているものですが、スマートフォンではそのラベルが 3.5 から 5 ピクセルほどの高さで描かれています。**「縮小されているか」を条件にした判定は、まさにその図版から操作を隠していたはずです。図版は縮小されないからです。**図版は拡大縮小されるのであって、読めなくしているのはその拡大縮小の方です。
そこで拡大の挙動はすべてに適用されることになりました。ラスターも図版も、どの可視区域でも開きます。**この判断こそが、ぼやけたスクリーンショット 1 枚の修正を、サイト上の 86 個すべての図版に、3 言語すべてで及ぶ変更に変えたものでした。**
*Figure — ScaleCollapse: 同じ図版が求められる各サイズで並んでいます。いちばん右のカードが「開くと戻ってくる状態」で、記事の残りはそこへ辿り着くまでの話です。*
## ダイアログに必要だったのは 1 つではなく 2 つの規則
パターン自体はサイトにすでにありました。検索モーダルは `showModal()` で開くネイティブの `