width 属性と height 属性の話

いや、もう激しく今更な話なんですが。

自分も未だに迷信に引きずられて width 属性と height 属性を記述し続けてるんだけど、実際に世間一般はどうなんだろ。古めのブラウザの爲には、記述しておいた方が良いかも知れませんが。 の古いブラウザって、どこらへんのブラウザには当てはまるのかなあ。ばっさり切り捨てて記述をしていない人って結構いるのかしらんとか思った。

img 要素の width 属性と height 属性って、あくまでユーザーエージェントのレンダリングのための情報だと自分は認識している。

The height and width attributes give user agents an idea of the size of an image or object so that they may reserve space for it and continue rendering the document while waiting for the image data.

height属性とwidth属性は、ユーザエージェントに対して画像やオブジェクトの大きさに関する概念を知らせるので、ユーザエージェントは画像やオブジェクトに割り当てる空間を予約し、そのデータが届くのを待っている間も文書のレンダリングを継続できる。

そう言った意味では、最近のブラウザが width 属性と height 属性の情報がなくてもシームレスに描画出来るんであれば、とくに記述しなくても良いんだろうな。

この記事についての情報

似た内容の記事

この記事に対するトラックバック

トラックバックURL: http://www.lucky-bag.com/mt/mt-tb.cgi/134

Comments

やまざき said:

手書きでタグを打ち込む場合は(基本)記述していませんでしたが、ブラウザが描画する際に height, width の指定があるとそれだけパフォーマンスが遅くなるというような記述(*1)をどこかで見て以来、今度は意識的に書かないようになりました。

(*1)記述がなければブラウザは単に表示するけど、記述があると画像の描画と同時に高さ、幅を読み込む形で描画するため若干のパフォーマンスの劣化が起きるというような内容だったと思います。

e-luck said:

記述してあることで、描画のパフォーマンスが落ちるってのは初めて聞きました。

そうか、携帯(非フルブラウザ)なんかは画面サイズに合わせて画像が縮小されたりするんで、逆に記述しない方が良い感じもするし、仰る通りなのかも知れないっすね。

参考になりました。

Bar said:

>記述がなければブラウザは単に表示するけど、記述がある
>と画像の描画と同時に高さ、幅を読み込む形で描画するた
>め若干のパフォーマンスの劣化が起きるというような内容
>だったと思います。

どこの都市伝説ですか?

最終的にレンダリングするまでには高さ・幅を取得して再計
算しなければならないわけですから、ぜんぜんつじつまがあ
わないと思いますが…。

>そうか、携帯(非フルブラウザ)なんかは画面サイズに合わ
>せて画像が縮小されたりするんで、逆に記述しない方が良
>い感じもするし、

勝手に縮小する端末はレアだし、
記述してもどのみち無視されるだけだから
パフォーマンスには関係ないですよ。

e-luck said:

>勝手に縮小する端末はレアだし、
>記述してもどのみち無視されるだけだから
>パフォーマンスには関係ないですよ。

あ、そうなんですか。
ちなみに自分が使ってる AU の W31S で自サイトを見た時の話でした。
一般的な風に言ってしまった僕がいけなかったですね。

やまざき said:

> どこの都市伝説ですか?

2004年8月号の Web Designing です。ブラウザ毎の描画スピードを計測した結果、指定ある、なしで描画スピードに変化があったとありました。

ただ、その理由までは書かれていなかったので単純にコードの量が軽減され転送スピードに変化があったのかもしれません。

不正確な情報でしたね、失礼しました。

補足ですが、↑の検証データは1ページ内に画像を100枚レイアウトして、とあるのでブラウザのレンダリングの際に起きるパフォーマンスではなく、転送量による変化かなぁというような気もします。

酔兎 said:

e-luckさん。はじめまして。

ここ数年でこなしている案件で、コテコテのテーブルレイアウトをCSSに部分的に対応するというものが多いのですが、その時、ロゴや装飾画像などのリサイズを伴う場合が多々あります。
そんな時、img要素のwidth属性とheight属性は邪魔になるだけなので、すべて削除するようにしています。もちろん新規でページを作成する場合も後々のメンテナンスを考えてwidth属性とheight属性はは記述しません。

個人的な意見としては、折角レイアウトの情報をCSSにまとめ上げているのに、img要素に実数値が記述されているのが、なんとなく気持ち悪いんですよね。。

あと、画像が表示されない(しない)場合のalt属性の挙動も注目してます。
手前味噌ですが、こんな感じです。
http://www.doburoku.com/do-blog/2005_02_01_do-blog_archive.html#id110748249885729992

ていうか、単純にマークアップのときに面倒くさいんですよねw
で、クライアントに突っ込まれた場合に↑のようなことで理論武装しておけば、やり直しをしなくてすむというオチです。

e-luck said:

酔兎 さん、はじめまして。
なるほど、画像のリサイズという作業が発生した時は、確かに煩わしいかもしれませんね。しかも、それが複数ページにまたがっていたら尚更かも。
XHTML2.0 で img 要素自体無くなる予定ですが、実際ブラウザでサポートされるのなんかまだまだ先の話でしょうし、当分は img 要素のお世話になるかと思うんで、自分も記述するのは止めてみようかなぁ。

幸之介 said:

思いきり時機を逸していますが、コメントします。

width/heightを記述しておけば、ブラウザはhtmlとcssさえ読み込み終えれば、あらゆる描画すべき要素の位置と大きさを確定できます。逆に、これらを記述しない場合、各imgソースの少なくともヘッダを取得しなければ、各画像の大きさが決まりません。

ブラウザが一度に取得しに行くリクエスト数は一般に4つなどに限られていますから、文書内に多くの画像がある場合、通信上のリクエストレスポンス遅延と画像転送時間分だけ、最終的なレイアウトの決定が遅れることになります。

レイアウトに依存しないコンテンツであれば問題ないと思いますが、たいていの場合、これでいちばんユーザーが影響を受けるのは、「ブラウザがhtml(とcss)だけ読み終えた時点でユーザーは本文テキストを読み始めたが、ヘッダなどの画像が読み込まれるに従ってレイアウトが微調整されていき、ユーザーはいま読んでいた場所がわからなくなり、結局、画像が全部読み込まれるまで待たなければならない」というシーンではないでしょうか。

width/height不要派の方は、このような事態に遭遇したことがないのかな?といつも疑問に思っています。もちろん、htmlのメンテナンス性やレイアウト情報の集約という点では劣るかもしれませんが、少なくとも天秤にかける材料としては、読み込み完了までの時間を基準にした Web Designing のテストは的外れであると思います。完了に至るまでのレンダリングの挙動が問題なのです。