レスポンシブデザインに於けるwidth, height属性について

width, height属性と width, heightプロパティの違い

htmlの width height という 属性 と、CSSの width height という プロパティ は文字列こそ同じですが、似て非なるものです。まずその説明をしたいと思います。

属性 というのは html に付随しており、主な書き方は以下の通り。

<img src="画像URL" alt="" width="100" height="100">

一方、プロパティ というのは CSS に付随しており、通常は以下の通り。

img {
  width: 100px;
  height: 100px;
}

この違いなんですけども、htmlのwidth, height属性というのは imgそのものが持つ自身のサイズではなく、imgが収まる領域の指定 です。

imgというのは「画像」ですね。例えばみなさんが画像サイトから取得したものですとか、スマートフォンで自分で撮影した風景や人物など、これらが「画像」です。そしてこれらは自分自身のサイズを持っています。ここで言う「サイズ」というのは「容量(単位 KB, MBなど)」ではなく「寸法(単位 web上では主に px)」のことです。

htmlはcontent、CSSはlayout

htmlというのは文書の意味や定義を司っており、それぞれの要素が「どんな形状」「どんな並び方」であるか、という点は重要ではありません。だとしても、それらを人の目に見える「ページ」として成り立たせるには一定のルールに則って「配置」を行う必要はありますよね。

CSSはhtmlで基本的な配置が行われた「後」に、それらの配置・形状を再構成するためのものです。CSSによってhtmlの根幹である意味や定義が侵されることはありません。

なのでhtmlはcontent(コンテント 内容)、CSSはlayout(レイアウト 設計)とされています。そしてhtmlの width, height属性 もcontentに属し、CSSの width, heightプロパティ もlayoutに属します。

htmlでimgの解釈時に重要となるのは、そのimg要素がどの範囲を占有するのか です。「オリジナルサイズは度外視」という言い方もできなくはない。例えば

<img src="画像URL" alt="" width="200" height="200">

となっていた場合。htmlのwidth, height属性の場合単位は px です。px単位は省略するルールなので width="100px" といった書き方はしませんが、pxという単位が自動適用されます。

ただしこのwidth, height属性は 必ずしもオリジナルサイズと同一とは限りません。というか、オリジナルサイズを記すという義務付けはありません。仮にオリジナル画像が以下のものだとします。

上記の画像をサンプルhtmlにあてはめると以下のような表示になります。

アスペクト比が壊れている という状態です。オリジナルサイズのアスペクト比(縦横比)は 横 : 縦 が 2 : 1 なのに対し、width="200" height="200" という領域は 1 : 1 ですよね。その領域の中にimgそのものを 横いっぱい 縦いっぱい として表示させるのでこういう結果になります。

「私のブログではそんな表示にならない、ちゃんとアスペクト比が正しくなる」という方は、テンプレートの独自CSS(スタイルシート)の助けを借りているから です。テンプレートCSSの中に img {height: auto} の指定があるのでアスペクト比が壊れない。けれども指定が無い場合はアスペクト比が崩壊する、ということになります。

それでも何故このwidth, height属性が欲しいかというと、img要素のsrc取得が終了しなくても事前に表示範囲を確保できるから です。imgというのは通信をしなければその内容を取得できません。けれども通信に先んじて場所取りだけしておける、というのがwidth, height属性の意義なんですね。だからオリジナルサイズは度外視、と。

それに対し、CSSのプロパティの方は画像そのもののサイズを指定しています。もちろんここでも寸法指定を間違えればアスペクト比は崩れますが、それは滅多に起こりません。何故かというのは次章。

height属性にauto値は無い

height="auto" という指定はhtmlでは許可されません。何故なら先程説明したとおり、height属性というのは領域の指定なのですから、「横は200px、縦は自動」という指定では事前確保にならない。何かを参照しなければ割り出せない単位、例えば % なども同様です。何も手がかりの無い状態で領域を確保できるとしたら、%のような相対単位ではなく、絶対単位(他の何かを参照する必要が無い単位)である px でしかありえません。そして height="auto"(高さは自動) では全く意味が無いわけです。結局imgにアクセスして情報を取得しなければ高さが分からない、ということなのですから意味無いですよね。

一方CSSのheightプロパティはauto値が使えます。CSSはimgの情報を取得した後に整形しますので、既に画像それ自体のアスペクト比を知っている状態で行えます。そのため「自動」でも許可されるわけです。

文書がページとして成り立ち、私たちの目に入るまでにブラウザは レンダリング という作業を行いますが、その段階で一番最初に行われるのがhtmlの解釈(DOM解釈)です。この段階が最も手がかりの無い作業段階であるとも言えます。その段階で手助けになるのがimgに関してはwidth, height属性だよ、だからしっかり書いてくださいよ、と。そういうことですね。

htmlで確保した領域が全デバイスで通用するのか

ページが レスポンシブウェブデザイン である場合。確保領域がずっとそのまま活きるとは限らない、というよりも、活かせるわけがない、という事情があります。

例えばimg領域が W800 H500 として確保されたからといって、デバイスがスマートフォンになれば現役最小機種では画面の横幅が320pxしか無いのですから、横800pxで掲載すること自体が無理。バカ正直に掲載すればそれは ビューポートの超過 という結果を招きます。画面が横にブレてグラグラする状態ですね。これは今もう絶対避けなければいけない。ユーザビリティの最大の敵とも言えます(笑)

そう考えるとhtmlのwidth, height属性はあまり意味に無いもののように思えますよね。実際そんなに意味ないと思います (´・ω・｀)

何故今更Googleが明示を要求するようになったのか。
えっと、Googleは loading属性 というのを作りましたよね。ブラウザによる ネイティブ lazyload のことです。新規属性ですが正規属性になるはずの loading="lazy" という指定。これを利用する場合はhtmlのwidth, height属性が多いに役立ちます。これは領域の指定よりも アスペクト比の事前取得 だと思えば良いです。

結局のところ「アスペクト比を知る」というのが非常に重要で、比率がわかっていれば画面変化に対応できるんですね。width="400" height="200" ならばアスペクト比 2 : 1 ですから、画面サイズが320pxならpaddingを考慮して最大で横300pxだとすれば縦は150px、とアスペクト比に従って割り出すことが可能になります。

個人的にはこの都合に寄せてんじゃないかな、って思うよ (´・ω・｀)
だってこれまでは「レスポンシブデザインならwidth, height属性ってあんま意味ねーや」という感じで流れてきて、Google的には「いやそれでもやっぱ基本ルールなんで、一応、ねぇ？」みたいな感じだったのに(笑)

この「基本ルールに忠実であること」というのはやっぱり重要だな、と改めて感じています。何故なら私たちのweb言語もいずれは古代言語になるはずです。100年とか1000年とか経過した後、1世紀前のweb言語が正しく残っていれば解読が容易じゃないか。「ログを残す」というのは短期であるようで実際はすっごい長い年月にも耐えうるならそれが一番ではないか (´・ｪ・｀)

話を戻します。
lazyloadというのは「ページを表示させる時点では画面外にあるimgの取得をしない」という性質のものですよね。するとこういう問題が起こります ↓

Lazyloadingでページ内スクロールの到達位置がずれる件を解消する方法

正直あんまりおすすめではない (´・ω・｀) すすめない理由は 要素が増える めんどくさい 記事内でstyle属性あるいはstyle要素を必ず使う必要がある pタグ内の画像はどうする(セマンティクス面) こんなところでしょうか。 特に要素が増えてしまう点ですね。無駄なラッパーが増えるというか。 結局は自身の記事内容の管理能力であったり理解力であったりに関わってきますので、html初心者にはおすすめしません。 ...

vanillaice000.blog.fc2.com

lazyloadを利用して画像を掲載すると、ページ内スクロールの頭出しの位置がズレるよ、と。この理屈としては imgの情報を取得しないため、領域自体が無いため です。この場合重要になるのは 高さ です。画像が無く、height属性による領域確保も行われていない場合、何も無い状態、つまり 高さがゼロ なわけですよね。それがページ内移動が行われることによってそのスクロールの途中でスクロール領域内の各画像が表示されて高さが発生し、その結果到達位置がズレる、と。

で、この「lazyloadを利用している場合」というのが特殊ですから、通常のimg掲載、画像のベタ貼りの場合を考えると、やっぱりwidth, height属性の指定が無いと 画面がガクリと下がる という現象が発生します。もちろんPCスペックや通信環境にも左右されますが、いきなり今読んでいる部位がガクっと下に下がって移動してしまう、という現象は珍しくないと思います。みなさん経験おありなんじゃないかと。

width, height属性で領域を作っておけば、仮にページが表示された時に真っ白な余白として出てくるとしても、そこに画像が現れた際に画面ガクリ現象は軽減されます。

Optimize Cumulative Layout Shift

Cumulative Layout Shift (CLS) is a metric that quantifies how often users experience sudden shifts in page content. In this guide, we'll cover optimizing common causes of CLS such as images and iframes without dimensions or dynamic content.

web.dev

英語のページですけれども、動画だけ見てもらえば意味がわかると思います。「画面ガックン」は嫌だよね？という主旨のものです。そしてそのためには width, height属性を書きなさいよ という啓蒙です。

で、私としてもwidth, heith属性を「「書けるなら書く」を推奨します。でも「絶対書くべき」とは言わない。後述。
そしてFC2ブログの新投稿画面の諸問題もやっぱり絡んできますね (´・ω・｀)

「width, height属性追加」という修正作業に関して

絵文字やファビコンなど比較的小さいもの

htmlの定義がどうとかこうとか、というよりも、「画面がガクってなるんだよ！」という事実の方がよほど説得力がありますし、目に見えて「ユーザビリティに害がある」と理解できますよね。

じゃあそこに注目して、絵文字やファビコンなど、15〜20px程度のものはどうか。しかも文章の横に並んでいることが多いこれらについてどうか。

個人的には、「今後はしっかり書くとしても、過去にさかのぼってまで修正しなくても良い」というか、「記事修正に関する最重要課題ではない」というか。だって20px四方程度ならば画面ガックンは起こらないでしょう (´・ω・｀)
テキストが横にあるならなおさら、そのテキストによって高さが発生しているのだらかおよそ起こらない。

lazyload利用者、スクロール対策済の場合

これなんですけどね。先に掲載したブログカードと同じものを再掲します。

Lazyloadingでページ内スクロールの到達位置がずれる件を解消する方法

正直あんまりおすすめではない (´・ω・｀) すすめない理由は 要素が増える めんどくさい 記事内でstyle属性あるいはstyle要素を必ず使う必要がある pタグ内の画像はどうする(セマンティクス面) こんなところでしょうか。 特に要素が増えてしまう点ですね。無駄なラッパーが増えるというか。 結局は自身の記事内容の管理能力であったり理解力であったりに関わってきますので、html初心者にはおすすめしません。 ...

vanillaice000.blog.fc2.com

上記の内容を実行している、という場合はますます修正の意義は小さいというか。
lazyloadのスクロール対策というのは要するに 領域の確保 です。そしてhtmlによるそれよりも更に正確なものです。htmlではなくCSSの方で領域確保を行っている、ということですね。ただしレンダリング段階の手助け・手がかりとしては無効です。そうは言っても通常、閲覧者が目にするページ内容というのは 全てのレンダリングが完了したもの を見ているわけで。要するにCSSなど全て適用された状態を見ているし、その状態を見るのが望ましい。

領域確保はCSSの方で補っているわけなんですが、Googleのテストツールはそこまでは見てくれません。単純にhtmlにwidth, height属性が有るか無いかを見て指摘を行います。実際にはCSSの方で解決させているのにそこまで深く探ってはくれない。Googleの指摘の「理由」が「画面ガックン」にあるとすれば、対策済の場合は要らん世話、要らん指摘と言えなくもないですね。ですから 過剰に気にしてはいけない。何故ならテストツールは完璧ではありえないのだから という感じでしょうか (´・ω・｀)

現にですね、このimgに対し width, height属性 ではなく、width, heightプロパティ で指定した場合でも警告が消えるんですね。これ。

<img src="画像URL" alt="" style="width: 200px; height: 200px;">

こうした場合ですよね。これはhtmlの style属性 の値としてCSSを書いている、という状態で インラインCSS という手法です。これでもテストツールは警告を解除するもよう。

でもちょっと考えてみてください。インラインCSSは昔から非推奨とされている方法 です。何故なら、htmlの途中にインラインCSSがあると、htmlはその作業を一旦中断し、CSSを処理する必要が生じます。それが結局はレンダリングブロック、作業の妨げになりますよ、やりすぎるとページ表示スピードに影響する可能性がありますよ、とされていますしそれは事実。だけれども警告は解除される。さて果たしてどちらが良いのでしょうか (´・ω・｀)

style属性の利用というのは制限ができないんですね。これを禁じられたら現在のwebが崩壊するといっても過言でない。style属性の有効な利用法というのは主にJavaScriptによるボックモデル変更ではないかと思います。slideToggleとか。DOM構築は終えた後、ブラウザが指示に従って実行する系ですね。style属性でdisplayをblockからnoneに、あるいはその逆とか。

style属性に対してテストツールはうかつに警告ってできないですよね。たとえその度合いが過剰だとしても恐らく警告は出されないと思います。

また話逸れ気味ですが、第三lazyloadを導入しており、かつスクロール対策構文を書いている、という方は、恐らく焦点は「dataURIへのwidth, height属性をどうしたら？」とかそんなところだろうと思いますが、やったところであまり意味はないです。それでも修正したいという場合は表示予定の画像の実寸を入れてください。dataURLは1px四方程度うの正方形ですが、そちらではなく画像のオリジナルサイズです。

テストの得点を気にするから対策、というのなら「そんなの別にしなくて良いじゃない」とお答えしますが、「こういう作業が楽しいのです」という場合は反対しません。寧ろ応援します。楽しめることならどんどんやったら良い ('0')/
「面倒だなぁ、辛いなぁ」と感じる場合はやらなくて良いよ。うん、やらなくて良いです (´・ω・｀)
あくまでも個人的には(笑)

新投稿画面でwidth, height属性が自動出力されない

これなんだけれど。数週か数ヶ月か前にある方からこの事実を聞きまして、運営に問い合わせを行いました。返答としては簡単に言うと「高さの大きい画像を掲載した際に投稿画面のレイアウトや操作自体に影響することがある、という質問や苦情が多数届き、その対策として現在はwidth, height属性を書き出さないよう修正を行った」ということです。

この状況というのが実際にどんなものなのか私の方では確認できていませんのでなんとも言えませんが、ともかく苦情に対する対策を行い、結果苦情内容については解消された、ということですから、私の方からはこれ以上追求するまい、としました。

ただ新投稿画面のツールを利用して画像を掲載する、ということはつまり画像ベタ貼り(特に対策は入れない)ということですから、画面ガックンは発生する、ということになります。ですからなんとか抜本的修正を行い、解消ののちはしっかりwidth, height属性を書き出す、というシステムに調整して頂きたいなぁ、と思っています。

でないと新投稿画面利用者さんはバックグラウンドの状態を知らないというか、気にしないというか、私としても「新投稿画面デフォで使うなら裏(html)を気にするな」と言ってますし、ともかくユーザビリティに明らかに害が出るものについてはちゃんと整えておく、というのがベストだと思います。それが何らかの属性によるもの、だとかそういうことよりもユーザーがそのことに気が付かないぐらいの仕上がりになると良いなぁ、と思います。

「FC2ブログで画像掲載すると何故か画面が…」と言われるのではなく「他のブログだと画面がガクってなるけどFC2はならないんだよねぇ」の方が良いでしょう。どう考えても(笑)

まとめ

えっと、ブログカードのブックマークレット方、ファビコン部位に修正を入れました。気になる方は差し替えを行ってください。ただしファビコン部位だけです。OGP画像の方は、アスペクト比が一定ではないこと、他者ページから取得できる情報には限りがあることから、width, heightはつけていません。表示領域はCSSの方で取ってありますが、どうしても警告が気になって仕方が無い、という場合はOGP画像にアクセスしてその都度実寸を書き込むしかないですね (´・ω・｀)

あるいは表示サイズは100px四方固定なので、width, heightともに100としておくか。この場合は歪んだ画像をCSSで再修正する、とか変な格好になりますがとりあえずテストには合格できると思います。でもこの方法が良いとは言えない。テストに合格させること「だけ」を目的とする方法。そういうのはあまりおすすめしない ^^;

最後に愚痴。
やっぱ辛いわー！エスケープしたブラケットが編集時に非エスケープに変換されちゃうの！
これ以前はならなかったはず。こうなるとコード掲載する人少なくなってしまう。だって誤字を見つけて一文字でも修正したら、エスケープコード全部書き直しだもん。辛いってさすがに(笑)

伝えることは伝えましたので運営さんなんとか調整お願いします (´・ｪ・｀)