A question that popped up in my head: do we need the
? After some thinking about it, I think they are presentational and don't provide any additional information to the HEIGHT and WIDTH attributes for the IMG elementIMG element. There was a time, when images couldn't be resized using these attributes. If that was still the case, they would be useful. But unfortunately, table designers took over the web and destroyed every markup that was there.
We can now resize the image using the HEIGHT and WIDTH attributes, exactly the same thing we can do using CSS. And that is the main reason I stopped using them (at least, I try). Even the W3C says they are deprecated in the specification:
All
IMGandOBJECTattributes that concern visual alignment and presentation have been deprecated in favor of style sheets.
I don't think the spec. is referring to this, as this doesn't affect either alignment or presentation. I think that comment is aimed at such things as border properties. I don't think you'll add many bytes by including the dimensions for an image; but I would include them, as the experience will be better for the user.
The reason for specifying height and width on an image is that the page will load faster, if you do. The text elements will drop into the appropriate places on the user's screen while the images are being fetched. Otherwise, the page will need to be re-drawn as they load.
Speaking of images, do you like the new version of my gallery? I remember your saying some time back that you didn't like the Newhouse method that I used on the original version.
I agree with Michael. Im not sure the actual dowload time differs that much, but it appears as if it does because the layout coordinates are calculated much faster. Also, it keeps the text from moving around during download. For large images, or many small ones, the difference is quite significant.
yeah, the height and width are used to preserve space for the actual image, so the page will load faster because the browser don't need to calculate the size of it.
I think that the width and height of pixel based images are metadata describing the image, and not at all presentational. It allows, as mentioned above, the browser to draw the layout before the image is downloaded and the size has been deduced from it itself. I'm also a bit of a sceptic towards the idea of using CSS to describe properties that are really part of the image itself, like the image dimensions. If anything, CSS should be concerned with how to scale, tile, or otherwise handle rendering fixed size or dynamic size embedded elements that are not at their original intristic dimensions. Also, CSS lacks the capability to do somehting that the XHTML width and height attributes can, and that is scaling proportianally to the intristic dimensions of the image - something that belongs with CSS and not XHTML.
The 'width' and 'height' attributes are really outdated and are very accurately marked as deprecated in the HTML 4 spec.
They make difficulties in the maintenance of the content. A very simple example:
Some text goes here <img alt=":-)" src="smiley.png"> ... more text.
So if I change the "smiley.png" image so it has slightly different dimensions I have to change the content, but then these dimensions doesn't belong to the content - they belong to a given visual presentation.
May be back in the past it was important to specify the 'width' and 'height' because of performance issues, which don't have today anymore. Even, when we have large images we usually dedicate a whole block for them:
<img alt="[ Mountain photo ]" src="mountain.jpg"/>
the performance is not an issue because that particular image dimensions won't cause re-flow of the inline content in any subsequent blocks, even if retrieved after the document has been loaded and displayed.
And after all if one insist on this performance hint, he/she could always specify and change the dimensions in the style sheet... but again it is not part of the content!
It is not metadata. It was metadata http://www.w3.org/TR/REC-html32.html#img. Why it isn't metadata:
Simple, nothing more to add. I totally agree that it should be metadata, but is not. You can resize the image using HTML or CSS, try it ;-).
Speaking of images, do you like the new version of my gallery? I remember your saying some time back that you didn't like the Newhouse method that I used on the original version.
That is just great use of markup :-)
Since the img element is one of the "replaced elements" using the (x)html markup method to define the dimensions does not actually relate to the image itself.
It addresses the overide 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.
i wouldn't hardcode height and width into the markup for one more reason: figure out sombody decides not to display images in his browser: they would become absolutely meaningless. they really are, imho, presentational. im am in favour of modularization, removing these attributes from the markup to the styling [sic!] sheets.
I am just playing around with accessible imagemaps today. If you are leaving out the width and height attributes and turn off images in your browser, you are not able to access the links of your imagemap via mouse or pointing device. I agree that this is an extremely rare case and you should provide redundant text links as well, but I just thought I'll let you know.
Minz Meyer writes you are not able to access the links of your imagemap via mouse or pointing device
: but what about alt? should do the "trick"... or did i misunderstand something?
Maybe we take this back a level and ask why we're using img in the first place? The only effective place that I believe image should be used (ie: where it's actual content and not just for presentational uses) is a diagram or figure that explains something. The rest of the time, it's presentational (just plain text or nothing at all would do instead) and shouldn't be used.
Next question: what do height and width describe? The height and width of the image, fairly obviously. I agree with liorean, in that it's metadata and is describing how the image is. When you start to use it for presentational uses (stretching or deforming the image), that's when we get into trouble, and I believe then it's for presentational use.
The 'width' and 'height' attributes are really outdated and are very accurately marked as deprecated in the HTML 4 spec.
No. The height and width attributes are deprecated for some elements in HTML 4, but not for img.
I usually include them.
I'm going to have to disagree with Liorean and David House. It IS presentational markup. It was intended as a way to tell the browser what size to present the image as. Granted, it CAN be used as Metadata, but I don't believe it is inherently. If it was metadata, the browser would not try to render the height and width attributes that way (theoretically speaking, of course, as we all know how bad web browsers can be at their jobs).
If this is the case, give the image an ID, and use CSS to scale the image appropriately.
Even if it was originally intended by the W3C to be metadata, Netscape and Microsoft have mucked it up so much that even if it WAS, it ISN'T nowadays.
When used as metadata, there's nothing wrong with the height and width included with the image. They'll help the browser with the rendering. In addition, they're necessary if you're floating the image. Say, for example, you have a group of templated pages. Each page has an image on it, but the dimensions of those images is not the same across the pages. The image is styled with a float:left. The only way to make sure that the float works is to specify the width, and the only place to do that is within the <img> tag.
@csant
you are right, it should do the trick, but if you are using a graphical browser with images off, only the alt attribute of the img element is showing up, but not the specified alts of the area elements.
I am working on a little testfile which will be up at minzweb hopefully tomorrow.
@Minz
that seems to be in contradiction to the specs:
Several non-textual elements (IMG, AREA, APPLET, and INPUT) let authors specify alternate text to serve as content when the element cannot be rendered normally. Specifying alternate text assists users [...] who have configured their graphical user agents not to display images, etc.
i shortened the text to respond to your statement only. it explicitly states that the alt attribute is to be rendered when the images are switched off: should we then talk about buggy rendering from browsers? i wait anxiously for your little testfile.
I think, that attributes width and height aren't deprecated. Look at the XHTML image module.
Perhaps if you consider the height and width attributes to be presentational, you must also consider the language definition of the page to be presentational too? After all, the appearance of the page would change if you, say, set it to Japanese. Height and width are inherent properties of an image, but not of a text block, so they can be assumed to be metadata, surely?
August says:
"The only way to make sure that the float works is to specify the width, and the only place to do that is within the
<img>tag."
Not the case. You /can/ specify the width and height of images with CSS just as effectively (for this purpose) as with attributes. In fact, I'm not sure that the CSS specs don't require CSS height and width for CSS floats.
Anne says:
"Why it isn't metadata: 1. You can resize the image."
So we should stop using things because they're abused by some people? I bet you think <table> is universally evil, then.
David House says:
The only effective place that I believe image should be used (ie: where it's actual content and not just for presentational uses) is a diagram or figure that explains something.
(somewhat off-topic) Arf, what a boring web that would make! What about photographs? Photographs can be just as contentual as diagrams. Don't tell me you'd go sticking a photo --- if it's part of the whole point of your document --- as a background image in a <div>!
Oh, and the ever-important graphical smileys are contentual as well. ;)
(My own contribution)
I think it all depends on the context you're working in. The value of <height> and <width> as metadata consists solely in one thing: Allowing visual browsers a headstart in page layout. This is not a bad thing. I think we tend to engage in a bit of "reverse racism" against visual browsers when we have arguments like this; just that something affects only visual browsers doesn't necessarily mean that it should be instantly relegated to CSS.
Of course, as it's been said (a bit too radically by some), we should be using CSS for non-contentual images. So our use of <img> should be well thought through. However, if there exists a case where one <img> is appropriate, there surely exists a case where several <img>s are appropriate. In this case, height and width attributes could have a dramatic effect on legibility of the page.
So my solution is to use height and width when, by my judgment, they contribute substantively to the legibility (read: accessibility) of the page.
I think some people are missing the point.
Yes, CSS can handle element and object dimensions, bt the truth is, why should they? CSS is an extention to HTML et al, NOT a replacement. Good CSS can produce wonderful effects when combined with good HTML, even add functionality if JSS is used.
The width and height attributes are necessary, in my opinion for a number of reasons:
In fact, I've often wondered about the whole "standards" thing... it's not really a standard. Different browsers render differently, no matter what "standards" they both calim to follow. Even simple things, for example, IE uses standard Windows form objects to render form objects on a web page, yet Mozilla uses a slightly different set of objects for forms. Both render the page correctly, yet the visual styling of these elements can alter a page drastically. Windows XP again has a different set of objects to Windows 9x, most notably, the drop-down control. So these "standards" don't really control anything - it is down to how the OS and browser combine.
I had a feeling I had read this thread before... Height and Width challenged. While I wish there was a better way, I think they should still be used...