Aaron Mentele, Charisma 18 personal blog of Aaron Mentele, web developer and partner at Electric Pulp

Time for further elaboration on the topic of My Opinion Regarding Website Sizing Relative To Viewport. I don’t think there’s a Team Page Zoom - you’ll have to forgive my previous title. And if there was, membership would not require taking an oath to make sites fixed width, fixed font size, or fixed anything.

My point is that there are drawbacks to flexible layouts just as there are to fixed layouts. My specific issue with the former is that developers effectively need to produce larger sites than are being delivered. It strikes me as wasteful to increase the size of all requests for all users in the name of flexibility. My specific issue with the latter is that you can’t change the magnification at all without browser support.

I don’t think anyone has really picked a side, a team, or even a standard methodology regardless of the amount of skepticism voiced. If you’re interested in the topic, though, you should check out Drew Mclellan’s recent post. Be sure to follow the link through to Cameron Moll’s post as well.

Ethan Marcotte is on my very smart people list. He writes on things that need smart people writing about them. Like fluid layouts.

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