Need someone to lead product or development at your software company? I lead product and engineering teams and I'm looking for my next opportunity. Check out my resume and get in touch.


Comments for Height and Width challenged

Excerpt: Could someone tell me why height and width attributes are needed for images? It’s silly to require people to add metadata to HTML when it’s something easily calculated. Read the whole article…

August 5, 2003 9:23 AM

I know diddly about this, but I'll bet it has something to do with making the browser do less work so that it displays the page faster. As broadband becomes a ubiquitous commodity, I'll bet this becomes more and more of a legacy "feature" that never gets removed or replaced.

Dave S.
August 5, 2003 9:31 AM

They used to be required in table-based layouts. The table would dynamically resize as elements were loaded in, causing multiple jarring expansions and shifts of content. If you gave the td's a width and specified the height and width of your image, however, space would be created for the elements before they started rendering and the shifts wouldn't happen. That's why we added them. It would be nice if they were calculated, but that means either downloading every image first and then rendering the table (thus drastically increasing load times) or pulling a few bytes from the header of every image that specify dimensions and rendering based off that, which would require modifications to existing file formats and a years-long cycle waiting for browsers to catch up.

August 5, 2003 9:47 AM

Try surfing the web when connected from a mobile phone or via modem. I frequently do. Trust me, it makes a difference in page-rendering still, as on graphics-intensive sites, the page will still render while the 50+ image-download connections are being done, one by one in the background...

Adam Kalsey
August 5, 2003 9:52 AM

Let me clarify and say that I know all about the attributes and the implications of using or not using them. Height and width also let you stretch a single-pixel transparent image to any dimensions you want, effectively giving you a transparent block of any size using only a single image. So the question is somewhat rhetorical. The point is that these attributes shouldn't be needed at all. It's trivial to calculate the dimensions of any GIF or Jpeg file using only a few bytes of the image. I'd imagine that the same is true of PNG as well.

Dwight Shih
August 5, 2003 10:28 AM

Even in these days of broadband, you don't always want to download images. For example, I like to set the option to only download images from the same site as the page I'm viewing. This insulates me from web bugs when I'm accessing my email via the web. Going back to the dark ages, Netscape Navigator 3(?) had the option to not load images (you then hit a button/menu item to load the images). That alone was enough to make it my browser of choice for many years.

Bill Zeller
August 5, 2003 10:36 AM

I think the problem is that while only a few bytes are needed to calculate the width and height, a separate connection must be opened for each image in order to get those few bytes. So on a page with 20 images, 20 connections would need to be created before the page could be laid out with the proper dimensions. From the HTML 4 spec - "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." (I believe the height and width of a PNG file is stored in bytes 17-24, but don't hold me to that)

August 5, 2003 10:37 AM

I'm a little confused by your entry, Adam, since these attributes are not required but optional. I only use them when I want a smaller version of a photo (thumbnail-like) to appear. In that case, how could the browser know without guidance? Are you thinking of something different?

Adam Kalsey
August 5, 2003 11:01 AM

Bill: The attributes aren't required but are strongly recommended. They are required if you don't want the text to reflow constantly as the images load. Sizing the images that way isn't always the best idea. The whole image still needs to download. It might be better to create separate thumbnail images.

Adam Kalsey
August 5, 2003 11:04 AM

Sometimes it's important to question the way something is done. By challenging conventions, you either validate them or find a better way. There are a lot of good arguments here. Keep them coming. There's got to be a better way to handle this than requiring redundant metadata to be added to the HTML.

clint ecker
August 5, 2003 11:24 AM

It might've been mentioned but I think the biggest advantage is the rendering engine being able to layout the page more completely in its initial passes before the images are actually available/downloaded. The page layout can also be preserves if the images ever disappear or aren't available (offline).

Andrew Clover
August 5, 2003 12:01 PM

Yeah, there are good reasons for pre-specifying image sizes. 20 connections can take a while to do, especially as most browsers won't open that many at once anyway. Table layouts are worst affected by undetermined image sizes, some browsers can end up displaying nothing until the last image is fetched. That doesn't mean you have to stick with height and width *attributes* though. If you've got a lot of images the same size (which is very often the case), make a CSS rule to select them and apply width and height properties in the stylesheet. Cleaner markup, fewer bytes, easier to maintain. Yay!

August 5, 2003 12:14 PM

A. Clover: "If you've got a lot of images the same size (which is very often the case), make a CSS rule to select them and apply width and height properties in the stylesheet." ------- I was about to comment on the same point. I frequently make use of same-size images across an entire web site, and use the same trick above. Don't forget border:0; in the img style rule - that's even more presentational HTML that can be left off. :-)

Chris Hoare
August 5, 2003 12:47 PM

I write web applications like crm and the like; the image size attributes are most usefull for making a large image (normally someones photo) fit into a small space on the page. Which saves storing more than one image in the database ...

August 5, 2003 3:02 PM

But that image then needs to be downloaded in it's entirity -- Diskspace is cheeper than bandwidth, even without concidering the reduced wait for the reader

Lummox JR
August 5, 2003 3:57 PM

One of my longest-running annoyances on the Web has been when people don't put width and height in their images. Nowadays you can use CSS to do that too. Back when I was using older versions of Netscape, it would have to wait for the images to be partially downloaded before it knew their sizes unless you used the attributes, and it wouldn't render that part of the page or anything below until it knew the sizes. So trying to view a badly coded site via a modem connection was a nightmare. Even nowadays, pages appear faster and overall bugginess in the browser is kept to a minimum when you supply basic information like width and height. People with dial-up connections are punished most severely by lazy HTML/CSS, and even with a high-speed link it's a royal pain to have to watch the page readjust itself a hundred times before it can display anything properly. With images it's wise to *always* specify their size one way or another: either use the attributes, or use CSS. Better still is keeping the images (or some of a certain style) to a specific size so you can use a single CSS rule to cover the lot.

Adam Kalsey
August 5, 2003 4:37 PM

So far all the arguments have been based around how current technology works. But if my basic premise is that current technology is flawed, how does that change your arguments? If the way that browsers and Web server interact to display images is the wrong way to do it, what would be better?

Phillip Harrington
August 5, 2003 8:37 PM

Even on fast connections, my browser (IE) usually gives an image a default size of like a 30x30 square, or a big rectangle that outlines the "alt" text. Short answer, yes, it makes rendering faster, and it's still noticable on fast connections.

Phillip Harrington
August 5, 2003 8:41 PM

Agg! People using height and width to resize the big image down to a thumbnail? Bad bad bad! Bad programmers. Bad desingers! You all get a demerit and an F for today! This is much much much worse than not using height and width. Make a thumbnail on the server side (or in your app or something). (Sorry for posting the first time before reading all other posts, with my cookie set it's just too simple!)

Lyle, Lyle - Croc O' Lyle
August 5, 2003 8:46 PM

Adam, you said: "They are required if you don't want the text to reflow constantly as the images load" I see some current constraints: 1. images are separate from HTML markup (and text) 2. A separate connection is required to fetch each file in order to work in parallel. 3. Existing image file compression technology 4. Different devices may handle images and page layout differently (e.g. screen readers, braille output devices, PDAs, web phones, etc.) Here's the logical side of how it works today: A. You have to download the whole image file to determine its layout size and dimensions (because of constraint #3) B. Images can be embedded anywhere in a page/text, so you need to know the layout requirements of the images before you can achieve the final layout of the page. C. You can display text without knowing the layout requirements of embedded images if you don't mind a shifting display as image layout info is acquired. I see a few options: - invent new image compression techniques that allow you to get image dimensions first before downloading the whole file. This has some partial benefits, but doesn't scale to help when there are more images than connections available. - Store image layout info in a separate file (much like folks mentioned doing with CSS), maybe this could be automated, but would likely require some pre-processing by the server which would ideally know something about the display device. - Combine text and images all in one file; basically this is what PDF does. - or just deal with it: either add the dimensions or get used to pages reflowing which isn't that big of a deal. Use a tool to test for improperly sized images in HTML.

Adam Kalsey
August 5, 2003 9:56 PM

You don't need to download an entire image to calculate its dimensions. The dimensions of a GIF are stored in bits 6-9 and the dimensions of a JPG are in bits 163-166.

Andrew Clover
August 6, 2003 12:34 AM

I don't think current tech is 'flawed' as such... it's a basic design problem that if one is to use the integral size of an image, you're going to have to connect to the server for each image to find out the size. I don't see any way around that really. You could theoretically have a web server include the size of an image in an HTTP response header, so that the browser could read the image size using a HEAD request, do the layout and then get the images with GET requests. I don't know if this would really be worth it for the extra connection setup costs though.

Andrew Bowden
August 6, 2003 2:32 AM

It's obvious isn't it? We need height and width so that everyone who has a 600x480 image can scale it down to be viewed at 180x135 without having to open up Photoshop/The Gimp/whatever ;-) Stuff the extra download time! But seriously, is it worth doing all those extra connections to get the image size prior to rendering? on a small site with few images, it's probably not a major issue, but on a big site with a large number of images, then I'd be a lot more cautious.

James N Pope
August 7, 2003 6:14 AM

Maybe the ideal solution would be to have the browser do things in this order: 1) Get page content (XHTML, etc...) 2) Download only enough data from each image to get the dimensions of the image (first X bytes, then close the connection) 3) Render the page using page content layout including the layout information from the images (dimensions) 4) Then, once the page is displayed with the correct layout, and assuming the user wants to display the images at all, the browser should proceed to download the images and display each as it loads Using the above method, the browser should not download the dimensions for images where the "width" and "height" have been specified in the HTML. This lets (CSS-reluctant) web designers still use tricks like a 1px by 1px transparent GIF for spacing techniques...

August 7, 2003 1:09 PM

Andrew: I could be wrong, but I don't think an HTTP HEAD request will return the *dimensions* of an image, though it will return the *file size* ("Content-Length").

Mark Paschal
August 7, 2003 9:26 PM

Sounds like Andrew means a new header that does include the image size. Doing the same thing with a "Range" GET to get only those bits 6-9 and 163-166 would have the advantage of (usually) working purely on the browser end.

August 7, 2003 9:52 PM

ok, so first off, as someone mentioned different rendering engines display images differently before they are fuly downloaded, and this allows a site to be formatted correctly before the images are downloaded. A bonus of this of course is that page formatting may still be retained even if the links to the images are broken, which can and does happen. Really there isn't all that much NEED for height and width in your img tags. But it can still make pages render quicker and better

August 14, 2003 5:19 PM

There's no other way to do it. You wither have to look at each image file to see it's dimensions (yes, most image formats provide dimensions towards the beginning of the file, uncompressed) or you have to use meta data whether it be in one single file, at the server, in the html, etc. There's simply no other way to do it no matter how creative you want to get. Providing dimensions in the HTML is generally a good idea because it is easy and the rendering speed normally makes up for the insignificantly larger file size.

Jo Cit
December 16, 2004 8:06 PM

The HEIGHT and WIDTH attributes are (a) optional, and (b) VERY useful. If you don't like them, don't use them. You miss out on a feature that improves usability for your readers. In fact, you are sacrificing their usability for yours. How very kind of you. But hey, it's your choice. The HTML standard never demands that you give that information. But these pieces of information are very useful. Suppose you have a page with a table in it, and in the first column of that table is an image. The width of the table, and the positions of all elements in the other columns (in ALL rows, not just the one with the image), is determined by the width of the image - which means the browser has to get (at least some of) the image before laying out that table. (By the way, you can use these to cause an image to be stretched, too. It's not only to duplicate what's in the image file already.) Perhaps what we need is a feature at the authoring stage: Zip through every HTML file, find every IMG tag, if it doesn't have dimensions add them, if it has different dimensions mention it (maybe the image has changed). This means that the information is there for the browser, but you as the author don't have to worry about it. Tell you what: If you're interested, I will WRITE you a program to do the job. The effort involved will be well spent, justifying a perfectly good feature. :)

December 10, 2005 7:24 PM

Did anyone found the program to add dimentions to height and width as mentioned in this comments? I would be very interested in getting such script, thanks

Paul D
June 4, 2006 6:40 AM

I like AK's idea of "how can we make the technology better". It's surprisingly hard to think laterally or differently! Now about Andrew Clover's suggestion of a new header tag with information about the dimensions of images in the page -- the header could (by the order of image data, or a tag or something that describes the image purpose: bug, background, header) give hints on which images to download first for an even smoother user experience. And you would not need an extra HEAD request to get it, because a normal request retrieves the html header first, and the information would then be available for rendering Nice!

June 13, 2006 10:20 PM

There is Carrick Image Tagger, but it is very old software.

June 17, 2006 4:16 PM

If anybody finds a good piece of recent software, post it for all, please.

This discussion has been closed.

Recently Written

Domain expertise in Product Management (Nov 16)
When you're hiring software product managers, hire for product management skills. Looking for domain experts will reduce the pool of people you can hire and might just be worse for your product.
Strategy Means Saying No (Oct 27)
An oft-overlooked aspect of strategy is to define what you are not doing. There are lots of adjacent problems you can attack. Strategy means defining which ones you will ignore.
Understanding vision, strategy, and execution (Oct 24)
Vision is what you're trying to do. Strategy is broad strokes on how you'll get there. Execution is the tasks you complete to complete the strategy.
How to advance your Product Market Fit KPI (Oct 21)
Finding the gaps in your product that will unlock the next round of growth.
Developer Relations as Developer Success (Oct 19)
Outreach, marketing, and developer evangelism are a part of Developer Relations. But the companies that are most successful with developers spend most of their time on something else.
Developer Experience Principle 6: Easy to Maintain (Oct 17)
Keeping your product Easy to Maintain will improve the lives of your team and your customers. It will help keep your docs up to date. Your SDKs and APIs will be released in sync. Your tooling and overall experience will shine.
Developer Experience Principle 5: Easy to Trust (Oct 9)
A developer building part of their business on your product needs to believe that you're going to do the right thing for them and their customers.
Developer Experience Principle 4: Easy to Get Help (Oct 8)
The faster you can unblock a stuck developer, the better their experience will be.


What I'm Reading


Adam Kalsey

+1 916 600 2497


Public Key

© 1999-2020 Adam Kalsey.