Comments

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…

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

Anders
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." http://www.w3.org/TR/REC-html40/struct/objects.html#adef-width-IMG (I believe the height and width of a PNG file is stored in bytes 17-24, but don't hold me to that)

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

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

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

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.

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.