Should < img > Deprecate "height" and "width"?
By @edent
· content development HTML HTML5 img web · 1 comment · 500 words · read ~705 times.
Image adaptation and resizing is a hot topic at the moment. With devices of varying screensize accessing your site, how do you ensure that the crappy 240*240 phone gets a reasonable experience while still making everything look gorgeous on the retina-busting iPad?
One of the very first things we're taught in HTML school is that we should separate content and style.
<span font="comic sans" colour="red">This is wrong!</span>
Instead, we should be doing
<span class="stylish">This is corrent!</span>
Yet, the very next thing we're taught is
<img src="example.jpg" height="120" width="90" />
Well hang on a second! We've mixed up content (example.jpg) with presentation (the dimensions of the image). The image will almost certainly have to be resized based on the screen size accessing the site. Which means all manner of crufty JavaScript and CSS hacks to get it to display perfectly.
The Right Way
Here is how I think the image tag should work.
<img src="example" class="icon" />
The first thing to note is that the image shouldn't have a file extension. As I've set out in a comment on Bruce Lawson's blog, the server should be looking at the HTTP accept headers to see what image type to serve up. If the device is capable of displaying SVG - that's what should be sent. If the device is too old to support PNG - the image should be served up as JPG (or whatever format the device accepts).
Again, the content of the image should be separated from the presentation (i.e. the file format).
Secondly, we drop the height and the width from the img tag. In the olden days, they were needed to stop the page from dramatically reflowing as images loaded. That's still a valid concern today, but the challenge is that we don't know what physical size the image will have until it is requested.
"So what?" I hear you cry "We can already do this in CSS. Images can have their dimensions set by absolute pixel size and / or relative size."
Indeed, you are correct. But, the HTML5 spec currently lists height and width as attributes which may be used. This, I believe, acts to tempt the unwary developer into using them. They should be as obsolete as "align" and "border".
Ideally, the logic should be on the server-side. Your CSS shouldn't be asking the device for its own properties, your server should be dynamically generating CSS which suits the User-Agent. The server should be adapting images on the fly (and cacheing them) depending on the resolution of the devices.
We should be writing ridiculously simple HTML5.
Computers are there to do the hard work for us. We shouldn’t be writing extra markup in every single new document. Get the silicon slaves to do it all.
Jo Rabin says:
As you point out the reason to prefer the presence of the attributes height and width is that it avoids ugly, distracting and possibly expensive reflowing of content.
What we see here, I think, is two valid and desirable sets of principles colliding. Yes it's desirable for some reasons to separate content and presentation and yes it's desirable to minimise the transfer of data, reprocessing of the same data, the delay between requesting a representation and the user perceiving the representation and so on.
Because of the way that the separation of structure and representation have been divided between HTML and CSS - and in particular because the CSS is usually retrieved after the HTML these concerns need to be traded off according to the demands of the application, the specific delivery context and so on.
I don't think there is any point in being religious or purist about the separation of concerns between HTML and CSS. They are tools. And they were not mandated by God.
Since the server knows at the point of receiving the original request enough about the delivery context to say what size the image needs to be, what's the big deal about it telling the silicon-slave-which-is-the-device know what size of image to expect, by putting the image size in the markup? Yes, for sure that increases the care with which the developer needs to create the original HTML, but in my view trading developer time for user time is hardly ever a good trade off to make - and really can't be considered to be good practice from a usability perspective.
What's missing here, I think, is reasonable tooling that lets the developer focus on concerns such as usability, functionality and so on, and lets the silicon-slave-which-is-the-server figure out the best way of realising the developer's intentions. As you say, let the server figure out what image format to use. Equally let the server figure out how best to create a representation of the entire page or application. Might be a PDF for example.
Until we enter some dream world in which such tools exist - and indeed maybe create some underlying standards that are more friendly to the existence of such tools - let's keep height and width as important elements of allowing a superior user experience.