And when the dimensions aren't defined, then progressively encoded JPEGs don't offer an advantage either, because with both progressive and non-progressive images, browsers reserve space for images as soon as their size is known, i.e. when the file header is received.

Agreed. But would you say that progressive jpegs don't offer a visual advantage in this case? Imagine if a photo has a caption below it: baseline starts rendering far away from the caption, but with progressive we'll get the caption in the correct place without a big gap between the caption and where the photo is rendering. In the case of baseline, the photo will draw to "meet" the caption.

Or in the HTML.

Preferably in the HTML.

Unless width="" and height="" have been deprecated on <img> overnight.

Different use cases IMO. If it's a single image of variable size, use width and height. If there are a bunch of images, all the same size (thumbnails for instance), use CSS.

If you specify width and height explicitly, certain browsers will have issues resizing them (if you set max-width: 100%, Chrome will squish a larger image horizontally but leave the height as it was, IE will scale it proportionally).

I think that's because Chrome treats width= and height= as if they were CSS. (have a look at the inspector on an element with width and height specified in the HTML)

That makes sense (thank you, don't know why I didn't realize that myself), but if I override that with css height: auto; , the browser no longer reserves space for the image while loading it... quite unfortunate.

Maybe you should submit a WebKit (or possibly Chromium if this is Chrome-specific) bug for this.

Why do you say Preferably in the HTML? Just curious. I vaguely recall there was a reason.

Because it has been the standard way for a long time.

And because it allows browsers to make room for the image and avoid reflowing.