なぜsizesで表示サイズを指定できるという間違いがまかりとおるのか

「sizes はグリッドデザインで使うと便利だよ~」というコメントを見かけたのですが、グリッドデザインについて不勉強な私にはなにが便利なのかよくわかりませんでした。ただ、sizes で表示サイズを指定できるという説明だけはちょっと違うんじゃないかなと思ったので、sizes についてまとめてみました。

きっかけ

sizes についていろいろ調べていたとき、次のように説明しているのを見かけました。

「画像を80%で表示したい場合は sizes に80vwを指定してください。」

ソースコードは次のようになります。

これって正しいのかな?と思ったのがこの記事を書くきっかけです。

まずは実験します

sizes 属性が画像の表示サイズを指定できるという説明がおかしいというのは、簡単な実験をすればすぐにわかります。次のようなソースコードを用意します。文字コードは Shift-JIS でもよいのですが、一応 UTF-8 で。ブレイクポイントは480pxと768pxの2ヶ所に設定しました。

リセット用 CSS には normalize.css を使用しました。

無料写真素材は足成さんがとても使いやすいです。3種類用意してください。理由は後述します。フルードイメージ化するので大きさはそのままでも大丈夫です。

今回は Google Chrome の検証ツールを使用しました。

先ほどの HTML ソースを読み込む前に、まずは Chrome のキャッシュを無効化にしておきます。有効なままだとなにかとトラブルのもとです。

検証ツールの右上のこの部分をクリックし、「Settings」を選択します。キーボードの F1 キーでもよいです。

「Settings」→「Preferences」→「Network」とたどってください。「Disable cache (while DevTools is open)」にチェックを入れると、検証ツールを開いている間はキャッシュが無効になります。

機種一覧から「Responsive」、Retina ディスプレイ対応を考えないので DPR は「1.0」を選択します。

DPR が表示されていない場合、ドロップダウンメニューで「Add device pixel ratio」を選んでください。

幅を小さい→大きいへ変化させていきましょう。左クリックでずんずんずんずんと横幅を広げていきます。

478、479、480、481、482・・・。あれれ。切り替わりません。

気になるでしょうが、とりあえずそのままずんずんと幅を広げていってください。601pxで切り替わるはずです。ブレイクポイントを768pxにも設定しましたが、こちらも同様の現象が起こります。961pxで切り替わると思います。

seizes に指定されたvwが画像の表示サイズを指定するだけのものであるなら、ブレイクポイントが600pxや960pxに移動しているのはおかしいはずです。

sizesとは

画像におけるレスポンシブ対応とは、srcset 属性での条件により画像を切り替えることです。今回の例で言えば480wや768wがこれにあたります。これに対し、sizes 属性は基準になる横幅を指定するだけです。

sizes に指定をする場合、vwという単位を使いますが、これは Viewport Width の略であり、描画領域の横幅を意味します。100vwであれば描画領域の100%、50vwなら50%、80vwなら80%です。

次のような srcset があったとします。

ここで描画領域が1000pxで sizes=”100vw” を指定した場合、img_1000.jpg が選択されます。描画領域が1000pxで sizes=”50vw” を指定した場合、描画領域の50%で判定されるので img_500.jpg が選択されます。

今回ブレイクポイントが600pxや960pxに移動してしまいました。簡単な方程式を解いてください。600X0.8=480pxですね。

説明の間違いに気付きにくい訳

この説明の間違いに気付きにくいのにはいくつかの理由があると思います。

見た目では分かりづらい

一般的に srcset を使って画像を振り分ける場合、細かい制御を考えないのであれば次のように記述するかと思います。

このとき用意される画像は、サイズは異なるけど映っているものは同じ画像であるはずです。そうすると、Chrome や Firefox などのテストツールで動作確認を行っても、どのブレイクポイントで画像が切り替わっているかがわかりづらいため、一見すると問題なく動作しているように感じてしまいます。

小さい画面で大きい画像から一部を切り抜いたものを表示させる「アートディレクション」の場合、見た目にかなりの違いが出るのでブレイクポイントがズレていればすぐにわかったはずです。先ほどわざわざ3種類の画像を用意して実験を行ったのはこのためです。

実際に80%の大きさで表示されることがある

いくら見た目では分かりづらいとはいっても、実際に80%で表示されていなければ異常に気付けたはずです。にもかかわらず見逃してしまった理由は、実際に80%で表示されるパターンがあるからです。

先ほどのソースコードで画像をフルードイメージ化している部分を見てください。

ネットで調べてみると、ほとんどのサイトでは max-width を使っています。試しに width と max-width を置き換えて動作を確認してみてください。max-width で100%化した場合、sizes に80vwを指定すると表示まで80%になってしまいます。

以前記事にしましたが、画像のフルードイメージ化は width・max-width のどちらを使っても行うことができます。どっちを使っても動作は同じです。

ところが、sizes 属性に関する動作についてのみ width と max-width で挙動が異なります。目的があってビューポートの80%で画像を振り分けるのではなく、純粋に振り分け後の画像を80%で表示したいのであれば、sizes に80vwを指定せずに次のようにするべきです。

いずれ各種ブラウザが対応してくれる可能性があり神経質にならなくてもよいのかもしれませんが、Firefox の検証ツールでも同様の現象が起きることを考えると、画像のフルードイメージ化には width を使用したほう無難であると言えます。

一応レスポンシブ対応の目的を果たしている

アートディレクションの場合には成立しませんが、複数サイズの画像を用意するレスポンシブ対応だった場合、意図したブレイクポイントではないものの、画面の小さなモバイルにはサイズの小さな画像をダウンロードさせて通信量を軽減する、という当初の目的を達成できてしまっています。

画面の小さなモバイルにも大きなサイズの画像をダウンロードさせていた場合、実機で動作確認していれば通信量の多さで気付けたかもしれません。ところが同画像複数サイズ系レスポンシブだった場合、多少ブレイクポイントがズレていてもモバイルに対しては通信量が軽減されることにかわりはなく、実機で検証を行っていても気が付かなかったのだと思います。

みんなそこまで作り込んでいない(暴言

今回画像のレスポンシブ対応についてネットでずいぶん調べたのですが、基本的な sizes の使い方にとどまるばかりで、「こうやって使うとこんなに便利なんだよ~」というサンプルにたどり着けませんでした。グリッドレイアウトに使えそうだというコメントをいくつか見かけたのですが、グリッドレイアウトについて不勉強な私にはよくわかりません。分かり次第追記ということで。

それはともかく、画像のレスポンシブ対応については最悪でもフルードイメージ、複数サイズの画像による srcset までやっておけばとりあえずは大丈夫なわけで、複数サイズの画像を用意するだけでもかなりの手間になります。

これに加えて、記事も書かなければならない、ほかの部分のデザインもレスポンシブ対応しなければならないなど、やらなければいけないことは山積みになっており、sizes の細かい使い方にまで手が回らないのではないかと推測しています。知ってる人、教えてください。

「役に立った」と思ったら、記事のシェアをお願いします。

スポンサーリンク

Comment

コメント認証制です。反映されるまで時間が掛かる場合があります。
URLの記入はhttpのhを抜いて下さい(宣伝対策です)。
連続でコメントするとスパム扱いになる場合があります。
しばらく待ってからコメントしてください。

CAPTCHA


Si prega di attivare i Javascript! / Please turn on Javascript!

Javaskripta ko calu karem! / Bitte schalten Sie Javascript!

S'il vous plaît activer Javascript! / Por favor, active Javascript!

Qing dakai JavaScript! / Qing dakai JavaScript!

Пожалуйста включите JavaScript! / Silakan aktifkan Javascript!

TOP