So, today he mentioned a smashing magazine post written on the same topic. And I read.

I keep getting hung up on the same thing, though. Image resizing.

I’ve played with two options.

1. Test the browser width server side and deliver images at an exact size.
2. Deliver a larger image. Test width client-side and display smaller dimensions.

The first option is nice in that you aren’t asking site visitors to download a larger version of your site (in terms of filesize.) But the benefit goes to hell if the visitor resizes the window and you have to make that call again (thereby testing and delivering new versions of the images each time.) And, more importantly (to me,) the image quality is never as good as if you optimize them manually.

The second option ignores the idea of delivering images at the smallest possible filesize. It delivers (meaning the browser downloads) large images, with smaller height and width attributes. But, damn, it looks smart onscreen.

If it wasn’t clear, I have issues with both options. Loading larger images and/or writing more code feels like a slope to offering high-bandwidth / low-bandwidth options. You know, for people with slow connections. Or mobile devices.

I JUST THINK MAYBE THIS COULD ALL BE BETTER HANDLED BY A RENDERING ENGINE. Because as awesome as fluid layouts are, and as well documented as the method is becoming (thanks to some very smart people,) we’d still have to re-engineer the entire web to solve the issue with html and css alone. Whereas browsers… well, they could introduce (check) and enhance page zoom.

I AM JUST SAYIN’!

Given a long enough timeline involving enough developers, you’ll see what I’m talking about. I’ll give you a quick example, though: misuse of whitespace resets.

I’m all for resets so long as they don’t involve an asterisk. The name is misleading, though. Very little is actually being reset. In most cases, the browser-defined preferences are simply being cleared out, leaving certain html elements devoid of any visual interpretability whatsoever.

The idea, of course, is that these styles would then be set to apply a new style to each occurrence of the respective element. But that part gets missed. (Especially in cases built around placeholder content.)

Developers define attributes for specific occurrences of the element (i.e., design interface occurrences) but miss the global instances that can kill content readability. Paragraphs get slammed together, lists are left without visual cues identifying them as such, blockquotes look like plagiarized content, etc.

It seems like this shouldn’t happen. But an absence of comprehensive standards results in people employing the incomplete kind. And bad code finds its way online.

I’m looking forward to the day this changes. Despite all the gross code I’ve contributed personally over the years, I’m still surprised at how often these things come up.