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.

Height and Width challenged

Freshness Warning
This blog post is over 17 years old. It's possible that the information you read below isn't current and the links no longer work.

Could someone tell me why height and width attributes are needed for images? Non-graphic browsers don’t use them, and graphic browsers should be smart enough to figure out the size on their own. The first few bytes of common image formats contain the image’s size, so the browser doesn’t even need to download the whole image.

It’s silly to require people to add metadata to HTML when that metadata is something easily calculated by the computer. That’s what we have computers for: to reduce the amount of manual work. Most authoring tools can automatically add the attributes, but the work’s still be done on the wrong end. This shouldn’t be an authoring function, it should be a rendering function.

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.

These are the last 15 comments. Read all 32 comments here.

This discussion has been closed.

Recently Written

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.
Developer Experience Principle 3: Easy to Build (Oct 5)
A product makes it Easy to Build by focusing on productivity for developers building real-world applications.
How to understand your product and your market (Sep 30)
A customer development question you can ask to find out who your product is best for and why they'll love it.
Developer Experience Principle 2: Easy to Use (Sep 28)
Making it Easy to Use means letting the developer do everything without involving you.


What I'm Reading


Adam Kalsey

+1 916 600 2497


Public Key

© 1999-2020 Adam Kalsey.