Height and Width challenged

Freshness Warning
This article is over 15 years old. It's possible that the information you read below isn't current.

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...

jacob
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.

scottbp
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

pb
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. :)

Manuel
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!

JAVTiamat
June 13, 2006 10:20 PM

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

JAVTiamat
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.


Your comments:

Text only, no HTML. URLs will automatically be converted to links. Your email address is required, but it will not be displayed on the site.

Name:

Not your company or your SEO link. Comments without a real name will be deleted as spam.

Email: (not displayed)

If you don't feel comfortable giving me your real email address, don't expect me to feel comfortable publishing your comment.

Website (optional):

Follow me on Twitter

Best Of

  • How not to apply for a job Applying for a job isn't that hard, but it does take some minimal effort and common sense.
  • Movie marketing on a budget Mark Cuban's looking for more cost effective ways to market movies.
  • California State Fair The California State Fair lets you buy tickets in advance from their Web site. That's good. But the site is a horror house of usability problems.
  • Customer reference questions. Sample questions to ask customer references when choosing a software vendor.
  • Comment Spam Manifesto Spammers are hereby put on notice. Your comments are not welcome. If the purpose behind your comment is to advertise yourself, your Web site, or a product that you are affiliated with, that comment is spam and will not be tolerated. We will hit you where it hurts by attacking your source of income.
  • More of the best »

Recently Read

Get More

Subscribe | Archives

Recently

Assumptions and project planning (Feb 18)
When your assumptions change, it's reasonable that your project plans and needs change as well. But too many managers are afraid to go back and re-work a plan that they've already agreed to.
Feature voting is harmful to your product (Feb 7)
There's a lot of problems with using feature voting to drive your product.
Encouraging 1:1s from other managers in your organization (Jan 4)
If you’re managing other managers, encourage them to hold their own 1:1s. It’s such an important tool for managing and leading that everyone needs to be holding them.
One on One Meetings - a collection of posts about 1:1s (Jan 2)
A collection of all my writing on 1:1s
Are 1:1s confidential? (Jan 2)
Is the discussion that occurs in a 1:1 confidential, even if no agreed in the meeting to keep it so?
Skip-level 1:1s are your hidden superpower (Jan 1)
Holding 1:1s with peers and with people far below you on the reporting chain will open your eyes up to what’s really going on in your business.
Do you need a 1:1 if you’re regularly communicating with your team? (Dec 28)
You’re simply not having deep meaningful conversation about the process of work in hallway conversations or in your chat apps.
What agenda items should a manager bring to a 1:1? (Dec 23)
At least 80% of a 1:1 agenda should be driven by your report, but if you also to use this time to work on things with them, then you’ll have better meetings.

Subscribe to this site's feed.

Contact

Adam Kalsey

Mobile: 916.600.2497

Email: adam AT kalsey.com

Twitter, etc: akalsey

Resume

PGP Key

©1999-2019 Adam Kalsey.