height values for images.
Paraphrased, from the inbox:
widthattributes no longer apply to images, I suspect. How then do my images render? They seem to automatically size. Is it based strictly on their original size, or should I be defining my attributes in my CSS?
Good question. I still set these particular attributes in my HTML, for both historical and practical reasons.
It used to be, before we were building table-less layouts and offloading all presentation to the CSS, that defining an image included things like turning off the border (darn 2px, blue-bordered linked image default!), specifying ALT text, and defining the width and height values. The latter were important because, as a page loaded, the space for an image needed to be set in advance. Without width and height, the image dimensions weren’t known until the image was entirely loaded. Small spaces were left for each image by default, but a page would jump around disconcertingly as it resized to fit the images as they loaded. This was particularly annoying given the image slicing and dicing that table-based layout forced, so specifying the dimensions alleviated the problem nicely.
(Interesting side note — Safari 2 seems to have an entirely new way of loading in larger images. [30k or more? I’m not sure what the threshold is, but it applies even to background images defined in CSS. Clear your cache and hit up Stopdesign for an example, see the header image.] Whether they’re interlaced or progressive or not [who interlaces images anymore?] it appears that the image is loaded in progressive chunks, which appears to ‘slide’ in the image. It looks like a Flash transition of an image, starting out squished up at the top, and expanding to fill the regular image dimension. Hard to describe, a little disorienting at first, but neat to see in action once you get used to this new method.)
Now, that’s the historical reason which, while in some contexts may still be relevant, generally isn’t a trick we need anymore. So why not offload these presentational
height values to the CSS? I don’t believe they belong there.
First of all, there’s the practical management issue. If you have a series of images that are all precisely the same dimensions, then defining a single class to control those is easy. If you have a few dozen that come in wildly varying dimensions, setting a unique class for each makes less sense. In many realistic scenarios, you have to account for images you won’t know the dimensions of ahead of time. So the CSS route doesn’t make sense, given that a) you may have hundreds of images to define separately, and b) you can’t define them when they’re not known.
Secondly, image dimensions are presentational values, so it might make sense they belong in the CSS… but they’re also metadata about the image itself. Very important metadata. I wouldn’t go so far as to call them “content”, but consider that the size of an image is as important to its final presentation as the colour of the pixels. If you can successfully make an argument for an image being an item of content, surely this metadata is more important than the sometime sacrifice-able presentation CSS affords. (Dimitri Glazkov recently explored the difference between presentational and content images.) So, if the dimensions are specifically bound to the photo, can they peacefully exist in the CSS (which may or may not be present in the final rendering of the page)?
Actually, the question put forth was more direct — why bother specifying attributes at all, whether in HTML or CSS? The image comes with built-in dimensions, the browser will know how to render the image. It seems almost pointless to bother specifying them, since that metadata already exists in another form.
Which seems theoretically true, but for just one little problem — the way the page loads before the image is placed. Since we’re talking about content images here, and not the hundreds of tiny GIFs that would previously made up a sliced and diced site, it’s a pretty small problem nowadays. Although given the rise of RSS, you may have noticed the same thing I have — the resizing problem is far more obvious when a content image is embedded in a news feed, and the accompanying HTML doesn’t include image dimensions. Since RSS aggregators typically display a feed as plain text with minimal decoration, it’s more obvious given the sparse surroundings. Specifying image attributes alleviates this, the same as it did in ‘97.
Ultimately I don’t think specifying attributes in CSS is wrong, I just see plenty of reason to continue doing as I’ve always done on this point.
(Sharp readers will notice that my second argument for keeping image dimensions out of CSS is invalidated by the later conclusion that this data exists elsewhere; however, this still leaves the first, and more relevant point: management is difficult, if not impossible. I’ll continue to specify attributes in my HTML unless a really good comment on this article convinces me otherwise.)