Journal tags: elastic

1

Zoomfusion

I know I’m not the sharpest knife in the drawer but there’s one recurring topic that makes me feel downright stupid. I’ve heard a lot of my fellow designer/developers talking about how page zoom (rather than text zoom) spells the death of liquid layouts.

Now, forgive me for being dense, but I just don’t get it. I totally understand how page zoom could spell the death of elastic layouts; using ems for layout won’t be necessary if browsers natively resize pixel-based layouts. But both pixel- and em-based layouts have a set width and that width doesn’t change depending on the width of the browser window.

A liquid layout will resize depending on the browser width, right? Page zooming doesn’t do away with that flexibility. If I open a fixed or elastic width page in a browser window that’s narrower than the size dictated by the designer, I’ll get a crawlbar. Now I could use the browser’s page zoom feature to shrink down everything until the content fits within my browser window but the content would become illegible.

Text-resizing and viewport-resizing are related only in as much as they are both ingredients in good bulletproof design:

  1. Ensuring that a design works for different text sizes.
  2. Ensuring that a design works for different viewport sizes.

Native page-zooming in browsers obviates the first concern. It does absolutely nothing for the second concern.

I’m perplexed. Either a whole swathe of my peers are confusing elastic and liquid layouts or I’m missing something fundamental.

A more plausible explanation for this strange equation of page zoom and liquid layout mortality is that designers who have already decided that they don’t want to deal with liquid layouts—for the very understandable reason that they’re harder to do than fixed layouts—are attempting to retroactively justify that decision without really thinking through the argument.

Rather than clutching at ill-thought-out strawmen like page zooming, their time might be better spent reading a good book.