Last time, I talked about the design theories that went into my new site: Metro, minimalism, reductionism, galleries, etc. This time, then, I want to talk about the tech it took to make those design sketches a reality.
First and foremost, before I was finished even drafting the design layouts, I had been convinced to move the site off of a static grid and onto a responsive grid. Why? Traditionally, websites have been designed for a known horizontal width. Usually the smallest one commonly used on the market (ever seen a size designed for “1024 or greater”? yeah, that.) But with a responsive grid, everything is based on percentages, not pixels. So, instead of a column being 62px wide, it might be 7.82% of the screen width instead. The advantages are obvious: content always fills the view while maintaining the same proportions. Those annoying “sidebars” of space blocking out most websites? Gone. The visual fills your entire view.
Knowing I wanted a responsive grid, I did some poking around. And I very quickly settled on one by Tyler Tate / TwigK (@tylertate) called “Semantic.gs.” Why? Because all of the grid work is done behind the scenes in the CSS, not by adding fake grid alignment classes to elements, which remove the flexibility of the grid and interrupt the dream of a semantic web (you know the one, where HTML markup is actually just markup and not styling.)
Letting Go Of The Pixel
The first thing I had to learn was that the pixel was dead to me. In a fluid world, there’s no place for calculating size by pixels. Block level elements were set to percents (and every image is set to 100% width within a containing block-level element). Type is set by em. Everything is relative and in an ideal world that’d be great.
In a fluid world, you can always know the width of an element. You live and die by the width. When aligning things in a grid, however, you sometimes need to know the height of things. Like my logo (to set the menu height). Or the height of a single square element so that input heights can be made to match. This is where things get… messier.
My first idea was, in all regards, a reasonable one: images have implied dimensions. Once the DOM calculates the width for one, it’ll also know the height, and with some assistance from jQuery I can just use that.
var rssHeight = $("img#rss").height(); $("input").css("height","rssHeight).css("lineHeight",rssHeight);
Those of you smarter than me probably already see the problem here: you have to wait for (often large) images to finish loading. The end result? The website kinda loads then “snaps” to the right aspects. Not exactly elegant.
My second idea was a better one. Pick an element with a ratio I could know (like my logo, or the RSS icon or anything really because I made the bloody graphics), then, calculate its height based off that ratio and something the browser was going to know right away anyway: the browser width. This way, we don’t wait for the image to load to grab it’s height. As soon as the DOM is ready we tell it in advance what height it’s going to figure out it’ll be eventually anyway. Way, way faster.
var body = $("body"); var bodWidth = body.width(); // the content is only 78% of the page width to keep it from raping eyeballs var adjustedWidth = bodWidth*.78; var squareHeight = adjustedWidth*0.0491; $(".singlesquare").css("height",squareHeight); $(".doublesquare").css("height",squareHeight).css("width",squareHeight);
Thinking Big. And Bigger
I’m pretty young, really. When I started designing for the web. 800×600 was already the dominant web resolution, with 640×480 the trailing legacy support size. But even so, if I were to go back in time and tell that me that someday in the not-so-distant future he’d find out that the largest standard resolution he’d need to support one day would be 2560 pixels wide (the approximate width of a 4 megapixel image), he’d laugh me out of his web dev class. 2560? Shit, the bandwidth alone would be impractical, and even then, what would you show it on?
Yet, here we are, and supporting 2560px is a real limitation to making a genuinely responsive site (you know, because downsizing looks OK to great, but upsizing never ever ever looks good ever). Yowzer.
In design, “web-size” refers to a low-resolution image that’s no good for printing, but thanks to the web’s approximate 72ppi resolution (actually varies a lot these days by display), and low total resolution, these images look just fine on the screen.
Yeah. That’s not the case when you’re looking at monitors that have more pixels than the average digital camera of 2004. “Web-size” doesn’t cut it anymore. I had to think it out. Every header image must be at least 2560 pixels wide. The homepage uses a 1:2.45 size ratio. The other pages all use a 1:4.6 ratio. But the width is always the same. 2560. No more casually scraping images off the web for blog posts, that’s for sure. Every image I upload needs to be planned, and it needs to be high-quality. And, because bandwidth is still an issue, I always have to worry much more about optimization than I did when graphics could be 500px or less. I promise you, your average mobile connection will throw an absolute hissy over a 2.1mb png file. As will your average user. Among other things, it means that highly compressed JPGs are currently the only way to go. Don’t believe me? Here’re some export weights from Illustrator’s save for web for a 4112x1429px image (the one used earlier in this blog, before I resized it):
- PNG-24: 3.26mb
- PNG-8 (256 perceptual): 1.33mb
- PNG-8 (64 perceptual): 1.07mb
- JPG (80, Optimized): 1.52mb
- JPG (40, Optimized): 696.5kb
See? Compressed JPG, clearly the winner. The gallery images suffer the compression hammer a bit less, because, well, it’s a portfolio site after all. But the point stands: a true fluid responsive site really makes you think about your images. A lot.
Whew. That’s a lot, and we’re just scratching the surface. Next time we’ll take a look at waypoints, sticky elements, and what’s in a gallery. After that, WordPress hacking for fun and flexibility. See ya then.