Five Questions with Zoe Mickley Gillenwater

Published by Chris Coyier

Zoe is a hero of the modern web. I first heard of her from her book Flexible Web Design, which is a super comprehensive and sensible look at building fluid width websites (and other techniques to make websites take advantage of a variable width browser window). At the time, "media queries" weren't really a thing. While it's a different concept, it's related in spirit. Zoe tackles that, and a slew of other CSS3 techniques in her new book, Stunning CSS3: a project-based guide to the latest in CSS.

I met Zoe once at ConvergeSE and heard her talk. She knows her stuff! I thought I'd catch up with her and get the what's what.

*Chris: I know you best from your book Flexible Web Design: Creating Liquid and Elastic Layouts with CSS. For readers: it was an excellent book with loads of practical advice and wasn't afraid to say what flexible design can and can't do for you. That book was only a few years ago. Has the idea of flexible web design changed much in that time? For example, I still hear "fluid" design quite a bit, but much less do I hear "elastic" and much more "responsive." Are those words meaningful and changing the landscape of web design? Or is it just fluff?

Zoe: I don't think the overall idea of flexible web design has changed much in the two years since Flexible Web Design came out, but it's increased in importance since then, and we have more tools to work with now that CSS3 has good browser support. Liquid or fluid layouts have been getting a lot of attention since the iPad was announced, since they change in width based on the size of the user's viewport. They can adapt when someone rotates their iPad from portrait to landscape. They can work on old, small monitors and large-screen TVs.

I really like the term responsive web design. Unlike the terms liquid, fluid, and elastic, which are all just metaphors for how the layout behaves, "responsive" gives a hint of what benefit the layout provides. It's about making your designs responsive to the needs of your users instead of trying to have complete, rigid control over design. But I think of responsive design as a big umbrella term - liquid and elastic layouts are two ways to do it, and you can use CSS3 media queries in conjunction with these types of layouts. But you can also use media queries on fixed-width sites, and this would still be responsive design, in my opinion. There are so many ways now to tailor the design to the user's settings and make it as usable and attractive as possible for him or her.

I'm so excited about media queries used with liquid layouts. They make it so easy to build a site that works on 320-pixel iPhone screens all the way up to 1920x1200 resolution monitors. (I don't know why someone would want to view a web site at 1920 pixels wide, but if they do, you can choose to accommodate them without too much trouble.)

*Chris: Do you think there are limits to how far we should rely solely on CSS for responsive web design? The example of handling a 1920px screen and a 320px screen is a good example. Media queries can help us detect for those sizes and design accordingly, but that means the exact same content is getting served to both screens. Isn't it likely that the 320px screen is on a much slower device in terms of internet connection speed and processing power? And thus it might be good to get a server side technology involved and serve up less heavy pages? Or is it a good thing that both devices are getting the same content and the capability gap of devices is diminishing?

Zoe: I agree that media queries alone are often not going to be enough to create the most usable site for all your different visitors. Depending on the site, you may definitely need to get some some of scripting involved to serve different content or functionality to different devices. But on some sites I think it's appropriate to deliver most of the same content and design elements to users at all sizes. For instance, the media query example I use in my new book Stunning CSS3 is basically a brochure site for a bakery. A small site with simple content like this is probably going to want the same content and functionality on the mobile version of their site as the desktop version - just designed differently to fit the space. So use media queries to customize the design, and other scripting techniques as needed to customize content and functionality.

*Chris: You have a new book out called Stunning CSS3, so I'm assuming you fully support using CSS3 in production websites today. What do you think about the territory where CSS3 and JavaScript overlap? Use CSS3 and skip the JavaScript? Use JavaScript instead? Test for support and do fallbacks? There are lots of ways to handle it and it seems like not much consensus on the "best" way.

Zoe: I'm going to give you the somewhat annoying answer of "it depends." But it's true, I think. Some effects are best controlled with CSS3, and some with JavaScript. Most of what's new to CSS3 are truly visual effects, so it makes the most sense and is most efficient to use CSS instead of JavaScript to accomplish these effects. For instance, rounded corners. Sure, JavaScript can do it, but it's not a behavior - it makes a lot more sense for this to be in the domain of CSS. It's so easy to use border-radius to make rounded corners, it's just a few bytes of CSS to download, and it degrades well in non-supporting browsers.

You can certainly use JavaScript as a fallback for many CSS3 effects. But again, whether you should do it depends on the effect and the project. Going back to rounded corners, for instance, you can use JavaScript as a workaround for IE, but you might get a performance hit for using it, so it might not be worth it for such a minor visual effect. In my book I talk about JavaScript alternatives throughout, and non-scripting workarounds too, and discuss the pros and cons. In the cases where I think it's worth it to implement a workaround, I walk you through how to do it. So I'm an advocate for both approaches, I suppose (leaving it alone and providing a non-CSS3 fallback).

*Chris: Do you have a CSS pet peeve? Something that seems to come up over and over again while building sites you wish there was a better solution for?

Zoe: Since I usually build liquid layouts, combining different types of units is a tricky thing I run into often, like percentage widths with pixel-based padding. There are plenty of ways to work around it, but it would be nice if there was a cleaner, no-brainer way. The calc() function is going to be awesome for this sort of thing when it's finally usable, but that's a long way off!

Another thing I hate having to do with CSS is align side-by-side elements vertically with one another. Like, make a text label, form field, and link all aligned across their middles, or along their baselines. The flexible box layout model is going to make this easy, but again, we have to wait for it.

Something that the flexible box layout model doesn't do that I wish it would is allow you to set the widths of side-by-side boxes proportionally to one another. For instance, make one box take up twice as much space as each of the following boxes take, with each adjusting if more or less boxes are added to the line. There's a common and understandable misconception that the box-flex property lets you do this, but that's not how it actually works or is supposed to work, according to the W3C spec. So there's no way, current or planned, to do proportional widths with CSS - at least not that I've been able to figure out!

*Chris: What kind of software do you use to do most of your CSS work? Do you use any kind of visual editor or prefer writing it by hand? Do you use any snippets/macros/bundles? Any other fancy workflow tips?

Zoe: I use Dreamweaver for all my CSS work, but I write it all by hand in code view. It has great hinting, and I use its snippets feature a bit too. You can also modify its default, blank CSS file to include whatever CSS snippets you want from the get-go, so every time you create a new CSS file your starting-point stuff is already there. Over the years, I've created my own collection of standard CSS rules that I add to almost every project, so that's in my default CSS file, as well as saved as a normal CSS file that I can add to any new project I start.