Skip to: Navigation | Content | Sidebar | Footer

Weblog Entry

Image Attributes

May 10, 2005

Questioning width and height values for images.

Paraphrased, from the inbox:

height and width attributes 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 width and 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.)

Questionable says:
May 10, 01h

Dave sez, “Given the fixed nature of the pixels that make up the images in question, the two are one and the same on today’s web.” Today’s web may be dominated by GIF, JFIF & PNG, but you’re ignoring the future of vector formats like SVG.

Ezku sez, “There is no set dpi for computer screens.” Yeah. That’s my point.

Dave S. says:
May 10, 01h

Questionable: “Today’s web may be dominated by GIF, JFIF & PNG, but you’re ignoring the future of vector formats like SVG.”

Sure, it’s interesting that Firefox 1.1 is going to support inline SVG, but we’ve got a *long* way to go before anyone will be using it as a substitution for what you’d do with GIF/JPG/PNG today.

May 10, 02h

Sizing information is a good bit more important (and a bit trickier to implement correctly) for vector formats like SVG.

Here’s my take on sizing SVG:

P.S.: Firefox’s SVG support still seems to be pretty broken. Compare how it renders the SVG image here,

with the Adobe Plugin’s rendering.

May 10, 02h

In terms of the page “jumping around,” whilst the images load, it seems to me that specifying image sizes only in CSS could (often, moreso for those on slower connections) suffer from the same problem. Assuming the CSS was not inline. That is, the HTML and images begin to load before the external CSS file containing the image size information can be fetched and applied to the page.

May 10, 02h

“You don’t send a high-res image down the pipe and resize it AFTER the fact.”

This is exactly what I do… at least for one image on the main page of my website. I have written an article about how to do this right:

May 10, 02h

As I see it the pixel height and width of an <img> are information on the same level as the image’s URI. They are facts about the physical entity that is about to be rendered. With no CSS applied this information is important to the renderer. This is information about the content.

When we add the CSS layer we can choose to override the way it’s displayed; change the dimensions, apply different units (such as mm, in, pt), scale (with em, percentage, etc) and so on. Similarly we might choose to prevent the image from showing altogether. These are all presentational considerations.

graste says:
May 10, 02h

Offtopic: Is Operas rendering of the svg okay?

I ask, since I don’t have the Adobe SVG-Plugin installed…

Back to topic: I think the width and height attributes of images are nothing that should be overdone with bloated css. Put it in your stylesheet where it is appropriate - but use html attributes all the time if you want because of the page loading thing… ;)

Oliver says:
May 10, 02h

Images are just a representation of symbols that css/html cannot create. Within a page, say, the background image loads first, and is then duplicated according to its width/height. The browser recognizes that.

However, another type of images - photographs or illustrations - that have a larger dimension, should be treated differently. They should start loading, and as the browser downloads more of the file, more of it should appear (and perhaps give a % of the download process of the image).

May 10, 03h

Just a small code snippet for easier management of the multiple images with different dimensions:

$size = GetImageSize($_SERVER[‘DOCUMENT_ROOT’] . ‘/path_to_image.jpg’);
echo ‘<img src=”/path_to_image.jpg” width=”’ . $size[0] . ‘” height=”’ . $size[1] . ‘” alt=”alt text” />’;

However, instead of attributes, we can place dimensions in inline styles (if one wants to be a purist).

This one should work with Apache/PHP/GD2.x

May 10, 03h

>Offtopic: Is Operas rendering of the svg okay?

Nope, though it’s much better than Firefox’s. Two problems:

1) It’s the wrong size. It should be 20em wide; it’s clearly much smaller.
2) All of the text is missing.

Here’s the fallback GIF image

which gives you a pretty good idea of what it should look like (and is the correct size at the default 1em= 16px).

Tony says:
May 10, 03h

In response to comment 21, here’s an even easier way to dynamically get the image size.

list($width, $height, $type, $attr) = getimagesize($_SERVER[DOCUMENT_ROOT].’/path_to_image.jpg’);
echo ‘<img src=”/path_to_image.jpg” ‘.$attr.’ alt=”alt text” />’;

The $attr variable automatically stores the width and height values in the ‘width=”x” height=”y”’ form.

May 10, 04h

When the height and width attributes are used to describe the actual dimensions of the image, they are metadata and belong in the markup. If, instead, they are used to alter the rendering size of the image, then they are presentational and such changes belong in the CSS.

trovster says:
May 10, 04h

I use the PHP getimagesize which is useful. I think content images /should/ have height and width attributes. This allows the rendering engine to allow the space needed for the image and stops text (which you might be reading) jumping around when the image finally loads. Not a problem nowadays because of broadband…?…what about content on mobiles…

Also, /should/ you define ‘px’ in the attribute. height=”100px” or leave it out. I think it should be included but Tidy complains about it… What’s people’s take on this?

May 10, 04h

>Also, /should/ you define ‘px’ in the attribute. height=”100px” or leave it out. I think it should be included but Tidy complains about it… What’s people’s take on this?

It’s not a matter of opinion.

The Specification

says that the width and height attributes have type “Length”. The latter is described as

<!ENTITY % Length “CDATA” — nn for pixels or nn% for percentage length —>

So height=”23” or height=”50%” are OK. height=”23px” is not.

Questionable says:
May 10, 04h

PHP Golf?

vprintf( ‘<img src=”’.”{$_SERVER[DOCUMENT_ROOT]}/{$path}”.’” width=”%d” height=”%d” />’, getimagesize($path) );

trovster, the only acceptable values for the width and height attributes in HTML 4 are type Length, which allows bare integers (implying pixels) or an integer followed by % for percentages. There are no other units allowed.

May 10, 07h

I’m in the dimensions-in-tag camp. I mean, ideally, there’d be a way to send the header of each image down the pipe before its contents, but since that’s not under our control, the dimensions should be given in the tag.

This is only broadly related, but I was intrigued Dunstan’s gallery (currently offline, unfortunately) was using style-attribute padding to center images of unusual proportions within their square thumbnail boxes. It’s using CSS to achieve the centered effect, but where there’s more options than simply horizontal and vertical. So those two are defined as classes, and anything else is accomplished with an inline style. (Not sure if any of that makes sense, but I think it’s a similar case of CSS<->HTML crossover)

May 10, 08h

I use the width or height (rarely both together) attribute on IMG in CSS in cases where I want to make sure that the image that is coming from the server doesn’t blow the layout apart because its bigger than expected. Setting one of the attributes causes the image to scale to the correct size (setting both will warp the image if the ratio is not what you expect).

Also it means that if you change the template then you don’t have to go through the HTML files to change the image sizes. And its a good way of reusing images that are in your CMS that may be slightly larger than what you need.

I don’t usually set them on the IMG tag. Not sure why I don’t, I just stopped doing it (I think its because I’ve dealt with one CMS too many that gets the image dimensions wrong and the layout ends up falling apart as a result)

May 10, 10h

Say I have a photo of a flower,
and I scale the image down to 30%
of its original dimensions. Has the
content changed? Disregarding the
detail lost in pixel resampling, it
is still the same photo of the same
flower. It would still be described
by the same 1000 words.

The height and width attributes describe the size of the content, but in HTML-space units, not image-space units. (Then the whole thing is scaled to device-space units and displayed.)

Of course, you don’t notice this normally because on screen by default [1 image pixel = 1 html pixel = 1 screen pixel].

In print you could have [1 image pixel = 0.1 html pixels = 1 print pixel] though, which is why the distinction between image-space pixels and html-space pixels is important.

None of this is presentational, however, because it just describes the image’s *preferred* size. The style sheet is still able to change the image’s size, if for example a particular style requires images to be smaller than the ideal.

Want proof? These attributes are still around in XHTML 1.1 strict, while all the presentational size attributes (as on table cells and divs) have been deprecated.

BOTTOM LINE: Perfectly OK to declare heights and widths for content images.

Joel Anderson says:
May 10, 11h

If the dimensions were specified in CSS and *not* in the HTML, what about the user who has images turned on, but is using a different stylesheet (or no stylesheet at all)? The rendering would default back to the attributes contained intrinsically in the image, and the benefit of specifying any dimensions anywhere would be lost completely!

And I wonder, too, in many installations where images are content and can change on a daily basis, why would I want to be modifying my CSS all the time, too? Simpler, in this case also, to put that information into the HTML.

AkaxakA says:
May 10, 11h

Your arguments seem to point to just leaving out all height and width values alltogether.

The metadata is in the image itself and rendering (+ downloading) of the image and the page are generally much faster than they used to be.

I think I’ve made my mind up about just leaving height and width out.

anders says:
May 10, 11h

you have to specify the width and height in the tag if the page uses anchors at all. otherwise, the jumping around actually breaks anchor links. without the width and height specified, the browser (firefox at least, probably others too) loads the html with only minimal space set aside for each image, then it scrolls to the specified anchor, then, as images load, the page is reflowed but it doesn’t re-scroll to the right place and the user ends up somewhere on the page other than where the link was supposed to take them to.

Mario says:
May 10, 11h

It strikes me that this is important meta-data for accessibility concerns also, though I may be wrong. I would imagine that it is not uncommon for even blind people to want to print images, and the height and width would help them determine whether or not to print them. I’ve never used a screen-reader, though.

Johan says:
May 10, 11h

The image tag … From an esthetic point of view I really find it annoying that there is this standardised image icon that appears before the totall image has loaded. It still remarkable that the dimensions of DIVs SPANS TABLEs etc. are nowardays defined with CSS… except the IMG tag still keeps its inline height and width attributes.

hink says:
May 10, 12h

This article got me thinking about the future of semantic markup for images. It seems like the xhtml2 spec, the object tag seems to provide a method to define dimensions in a param element. Being (ostensibly) a layperson, I am left to assume that, though UA’s certainly must be able to correctly render an image without this info, it is important enough to leave some wiggle room for the future.

Questionable says:
May 10, 12h

Image dimensions are not metadata. If someone in the W3 had thought about this long enough, they would have realized that *aspect ratios* are metadata for images, and pixel dimensions are purely presentational. Think about an image of a ruler, created at 72dpi, then displayed on a 96dpi monitor.

In Safari & Firefox, at least, image dimensions specified in CSS can be used to override those in the HTML element’s attributes. That way, I can say that this 423-pixel wide image should actually be displayed (or printed) accurately at 6 inches wide.

May 10, 12h

As you have stated, I think the question comes down more to presentational vs. content.

Presentationally, it does make a difference in how the page appears when loading, jumping around and what-not. In my mind, it doesn’t matter where they’re defined in this context, but they should be defined somewhere.

When it comes to content, I think of a photo album as an example (there are plenty of examples of images as content). A photo album usually contains images as both landscape and as portrait. Thus, the dimensions change. Would I want to define CSS classes for every possible ratio of image size I may use throughout my site? It depends on your site, but I think the typical answer would be “no.” Having them defined in CSS would restrict the design/content manager too much (unless you *want* them to be restricted).

So, I think the best place for them, to satisfy both cases, is in the HTML as attributes.

May 10, 12h

The height and width attributes of an img are *not* presentational; they describe the content in the tag only.

These values cannot always be read from the image, because it’s certainly possible to have an image whose height and width do not equal the number of actual pixels in the image.

Dave S. says:
May 10, 12h

“*aspect ratios* are metadata for images, and pixel dimensions are purely presentational”

Nice try. Given the fixed nature of the pixels that make up the images in question, the two are one and the same on today’s web. You don’t send a high-res image down the pipe and resize it AFTER the fact.

Ezku says:
May 10, 12h


There is no set dpi for computer screens. You can prove this for yourself by changing your screen resolution. Notice how the image still fills (or is at least supposed to fill) the whole screen? There we go. Different dpi.

There is no dpi, there are just pixels. These pixels may be LARGE or really, really small - you have no control over it. A 423-pixel wide image will render 423 pixels wide, if not for some tampering by either the client or the web-guy.

I approve of defining width and height attributes for content images. Mostly it doesn’t matter, but it can’t hurt either, can it?

(I received a “Fatal error: Call to undefined function: encodeit() in /home/mezzoblu/public_html/articles/comments/preview/index.php(20) : regexp code on line 1” when I tried to use backticks in my comment. You aware of this? :)

Questionable says:
May 10, 12h

Joel B. sez, “The height and width attributes of an img are *not* presentational; they describe the content in the tag only.” But the content of an image does not depend (necessarily) upon its bounding dimensions. Say I have a photo of a flower, and I scale the image down to 30% of its original dimensions. Has the content changed? Disregarding the detail lost in pixel resampling, it is still the same photo of the same flower. It would still be described by the same 1000 words.

However, as I tried to point out before with my ruler analogy, if an image’s content *does* depend upon the dimensions, then specifying those dimensions in pixels results in an inaccurate presentation, due to variance in monitor or printer resolution. CSS is therefore the *only* way to accurately present such images.

May 11, 01h

Well, my two cents:

Only use “src” and “alt” attributes when juggling with “img” elements. If you really want to specify image dimensions, use CSS rules to address this (e.g. “#gallery img { width: 100px; height: 100px; }”) or use a “style” attribute specifiying “width” and “height” for each image (just like you would use the “width” and “height” attributes). And it’s no problem if anybody disables CSS (is it?).

Anne says:
May 11, 02h

Last time the consensus was that they are representing metadata:

That they are implemented to be equivalent (and specified that way) to their CSS counterparts is merely a leftover - although still needed - from the presentational web.

Sander says:
May 11, 02h

How often does one not replace an image with another?

It’s strange for me to hear from the creator of csszengarden - THE project that shows one can redesign websites without touching the markup “that’s the power of css” to leave img hight and width’s in the markup, thus having to redefine the values everytime an image is replaced. It creates a lot more hassle without final benefit (the end result - when the page is loaded - is the same)

if the width and height are metadata, what is the difference of them to size=3 for fonts or border=2 (they describe the border for the element or the size of the text - so metadata). In my view that’s just a way to right a wrong argument.

Therefore on semantic and mainanance reasons (in addition to the arguments voiced in the article) I gues is why I not put them in the markup (or css for that matter).

Jon says:
May 11, 04h

I am not convinced that the web browser should be used to display images in any other size than what it actually is in. I would say no to resizing in the browser for any normal page.

Dan says:
May 11, 05h

Using PHP to dynamically spit the dimensions is a great idea (one I’ve used myself), but scripting can’t be the answer to the question of whether or not the attrib’s should be in the markup or in the CSS as anon proposed in #31. Scripting is a convenience method… not a universal solution to the problem as not everybody uses it, and those who do use varying implementations. As previously stated (and aside from the question of whether the images we’re talking about constitute content or presentation), width and height attrib’s are still in XHTML 1.1 for a good reason… they’re necessary.

Questionable says:
May 11, 08h

Paul: “A monitor is made up of pixels, it can’t represent a unit smaller than that for any resolution so there’s no point doing anything other than using pixels.”

So, if I’m going to display an image containing some map data, and I want to display a legend, instead of saying, “map scale: 1cm = 1km,” I should say, “map scale: 1:100000 pixels?” I believe there is a point in using units other than pixels.

Paul, again: “Pages loading over a slow connection look much better if the UA knows what space to leave.”

I recall David Hyatt stating that Safari doesn’t even begin to render a page until any external CSS has been downloaded.

May 11, 09h

Jon: This isn’t necessarily resizing — it’s just telling the browser what amount of space to leave.

As for comments like #36, I think it’s important to make a distinction here between persistent images (that corporate logo in the corner) and one-time content images. In the first case, dimensions in the style sheet are perfectly appropriate.

But in the second? Surely it’s ludicrous to declare a unique class in your global stylesheet for every different dimension of image you’ve ever pasted into your weblog! If it’s going to be inline anyways, whether it’s inline as height=”x” or inline as style=”height:x” doesn’t really matter much.

But I think using the old-school attributes seems a lot more concise and logical than cracking open a style-attribute for its own sake.

anon says:
May 11, 12h

It’s not ok to include image dimensions in the tag.

I disagree that managing these properties via css is unmanageable as some of the posters would have you believe.

If manageability is the problem why not address that and build a script that lifts all img dimensions from any xhtml file, assigns (auto or user supplied) classnames, and recasts the html without img dimension attributes, importing the associated css file.

Can you say that the utility provided by such a script makes seperation of presentation workable again? The reality of course being that you’ve built a button that casts the html in either direction?

adam says:
May 11, 12h

The point about having multiple classes to display different sized images is the most telling.

On a relatively small site, CSS for image dimensions maybe a possibility.

When looking at large content sites, however you template at some point someone will want to include a different sized image, allowing for this is almost impossible, let alone unmanageable.

Is it not best to let a CMS handle the image height and width attributes in situations such as this?

May 11, 12h

I’m in the attributes in the img tag camp also. My site has user galleries made up of thumbnails generated automatically and resized to fit a maximum 100x100 size. Saying that these attributes should be in the CSS would mean everytime someone uploaded an image I’d have to change the CSS automatically. It’s far easier and nicer to put them in the img tag. 1) PHP can do this automicatally for each image I show. 2) Pages loading over a slow connection look much better if the UA knows what space to leave.

I also don’t understand why using pixels for presenting them is wrong. JPG etc are stored as pixels no matter the DPI, the DPI just controls how many of these pixels should fit into a particular space. A monitor is made up of pixels, it can’t represent a unit smaller than that for any resolution so there’s no point doing anything other than using pixels.

Just my opinion anyways :)

John says:
May 12, 01h

As an interesting side note… nowhere does it specify that the unit of measurement for images MUST be pixels… which opens up some interesting ideas. As long ago as 2002, I was demonstrating re-sizable icons as an accessibility feature, by declaring the image dimensions in ems. For a complete overview along with samples see:

While not appropriate all of the time, it IS a vote for continuing to declare height and width dimsneions in your source code (as I do).

Just for though…

paul says:
May 12, 03h

Maybe we should all be like Jakob Nielson ( )
Images are the devil! :D

I think that this topic delves to deeply into the erroneous world of web development.
People who commit to one method or another in any form of web design will be a dissapointed developer. I think the answer is “Both-em”

A good example is, who uses an image rotator on the homepage. It is beneficial to leave those width and height callouts in the HTML for that reason. Also any image that is in the html, it would make sense to call it out there…and it seems more sense to me if the image resides in the css as a background image that it would be better to have those callouts there…seems logical.

I think that as a rule of thumb it should be in the css, as you can deploy it to various pages with one css class….If you have an image littered here and there throughout your html documents, you now have to go 1 by 1 to each call out….have fun man. I know y’all are smarter than that though ;D

SugarKane says:
May 12, 04h

I leave them out of my site and keep them in the CSS. It’s an image based site (so it is pointless to cater for “images-off” browsers) and secondly becuase images come in only two sizes on my site and even then within separate divs on separate pages. So, for example, all images within “#container” have one dimension and all those within “#thumbs” have another.

Makes my life a lot easier.

If you are able to do it due to having standard image sizes then why not?

May 12, 06h

I’m in the no-attributes camp for a number of reasons (and not just because I work for W3C)

Firstly, many image formats, including most vector formats, don’t have a concept of size. It’s up to the presentation engine such as CSS to display them in a given area. The size that the presentation engine uses may be different depending on the media/stylesheet (screen, handheld, etc) or the type of machine the browser is running on.

Secondly, in the case where the image content really does have an intrinsic size (such as JPG/GIF/PNG) then there is no point duplicating it in markup. This makes it difficult to dynamically generate images (a server may send a scaled-down image to a mobile phone - why should I change the markup for that? I might not even control the markup… I just serve the images).

Thirdly, following on from the last one, suppose I want to replace the images used a page. If I have to change the markup as well, then it’s pretty clear that I have not separated my content from presentation (and I understand that the image is content).

Finally, it’s conceivable that with the way display technology is improving that we’ll stop thinking in pixels in the near future. OSX Tiger already includes a resolution independent display engine (turned off at the moment), and most engines already do subpixel rendering. Combine this with formats that either don’t have pixel dimensions (eg SVG, Flash, PDF) or are raster formats that are designed to be rendered at multiple (or any) resolutions (eg JPEG2000) then specifying width and height on the image element is somewhat limiting.

Of course, practical issues such as having elements on the page move around while the image loads are definitely a concern. That’s a tough one, but not much different to having the stylesheet apply after some of the page has been loaded.

Rob Foxx says:
May 13, 07h

IMHO, images fall into two categories - content and design. If an image is part of the content of the page, the height and width attributes are just as relevant as the title attribute in an abbr tag elsewhere in that content, for example, and you wouldn’t go putting *that* in a css file.

If the image forms part of the design then its attributes arguably belong in your style sheet.

May 13, 10h

I thought about something. When you don’t specify the size, you aren’t taking the risk of typing wrong either. If you specify a wrong number, the image would look ugly in most browsers. If you don’t specify at all, it is always the right size.

Will I specify? I guess it depends. If it’s content images, I don’t see the big need to specify it, it’s not like the layout brokes if it doesn’t find the images and then doesn’t render an empty space at the same size as the image, where the image was supposed to be. But if it was a layout image, I would probably do it.

May 13, 11h

Crap, how did I manage to miss this article?

There is no doubt in my mind that the width and height attributes are presentational. They just are. It’s the pixel smell that gives them away.

The only problem is that currently there is no other mechanism to convey the size of the image prior it being rendered on the page. Anne mentioned it, the metadata.

Which is kind of a showstopper in some situations.

So, If you specify your image dimensions in CSS, you’re stuck with inflexbility. If you specify them using width/height attributes, you do sinful things in the structural markup book.

Pick you poison.

The rules of thumb, IMHO, should be:

* If you can get away with fixed image size on the page, don’t use width/height attributes.

* If you need flexibility and each image may have its own size (for instance, if part of your page contains server-generated markup with images, where you don’t even know what the size of the image will be at any given moment), use them and don’t sweat it.

Ingo Chao says:
May 14, 06h

Without height and width set, we saw pages that break in one browser, not in the other, or just in some ‘older’ versions, only on a slow connection or on a fast one too, depending on the cache settings, if its viewed on a local file or live, and depending on the OS at least. Maintaining a page, tweaking here and there, and the process recycles.
The most designers here are totally aware of it and can easily work around it. Takes seconds for them – when they see it.
The beginner is lost, wondering why only some visitors say that his fine positioned navbar on the right is jumpin up and down (due to an image on the left top, as we know, hidden among other things without any disturbance).
Omitting the metadata in this case leads to problems. As if there wasn’t enough. Why not being pragmatic.

chrisfarms says:
May 14, 12h

Think you hit it on the head:

For layout and presentational images spec the height/width in CSS (in fact try and use a background image since the <img> should not be viewed without a stylesheet)..

and if your image is content then the height/width are MORE THAN welcome as data.

[that xhtml2 link was intresting]

May 16, 01h

As I’ve stated on several occasions before the img element is one of the “replaced elements” using the markup method to define the dimensions with the attributes; width and height does not actually relate to the image itself.

It addresses the override window space you are allowing a specific object to fill in this case the image thus the markup solution is totally divorced from the image hence why the CSS solution is preferable.

Whether in the real-world it is preferable is debatable under some obscure circumstances.

Adam says:
May 16, 03h

Interesting article, a good read.

I’ve written up some comments in reply to your post.

Cpe says:
May 29, 09h

The PHP code posted above to determine the image size is BAD. GetImageSize is not a cheap function and has no guarenteed Big-O completion time. Having PHP check the image size during processing is going to put a lot of extra load on your server that isn’t necessary. Now, if you have a static cache set up that saves your PHP output as flat HTML, you’re fine.

John says:
January 05, 22h

Using PHP to dynamically spit the dimensions is a great idea (one I’ve used myself), but scripting can’t be the answer to the question of whether or not the attrib’s should be in the markup or in the CSS as anon proposed in #31. Scripting is a convenience method… not a universal solution to the problem as not everybody uses it, and those who do use varying implementations

Kate says:
January 20, 00h

Image dimensions are not metadata. If someone in the W3 had thought about this long enough, they would have realized that *aspect ratios* are metadata for images, and pixel dimensions are purely presentational. Think about an image of a ruler, created at 72dpi, then displayed on a 96dpi monitor.