Ethan Marcotte answers your responsive web design questions

@txpmag: Is there a future for responsive web advertising?
EM: There's a need for responsive advertising, I'll say that much. On The Boston Globe, we came up with a solution for responsively promoting ads in the site's fluid grid, moving an ad higher or lower on a page's hierarchy as the viewport got wider or smaller. And we – and the Globe – were pretty excited about the solution we implemented.

But we quickly realised that layout is the least of our problems. The way that online ads are designed and sold needs a healthy degree of refinement. Both Mark Boulton and Roger Black have covered the matter in great detail. So quite a few things need to change. Until the advertising industry starts thinking more flexibly, maybe it's up to us to start getting creative, and outline a few more ways that ads can move beyond the desktop.

@northk: I want to know what the most practical and robust approach is for displaying responsive images on multiple devices.
EM: Well, there's a lot of activity in the whole 'responsive images' area right now. Bandwidth detection's a blind spot for all of us, whether we're working on the frontend or backend. 'navigator.connection' isn't widely implemented or (I'd argue) specific enough to be helpful, and we're all watching the Device APIs Working Group work with interest.

That said, I'm really excited about the 'picture' discussion, most of which has been ably shepherded along by Mat Marquis on the W3C community group for responsive images. And Scott Jehl's 'picturefill' means we can start experimenting with it today.

Of course, we don't even have a specification for a new markup pattern, much less a working, native implementation. So maybe in the short term, maybe we need to rely on server-side content negotiation – though if that's the case, hopefully it has a more "mobile first" mindset, a la Brett Jankord's Categorizr.

But I do wonder if there's another option available to us: why can't we ask our users what experience they'd prefer? They're accustomed to making cosmetic UI decisions whenever they visit Gmail, or to choose the quality video they'd like on YouTube. Heck, every time they click on a "mobile" or "desktop" link on their phone, they're opting into experiences and feature sets that are radically different from each other. So I'm wondering if there's a more nuanced solution here: could we ask our users to, well, tell us what kind of bandwidth decisions to make?

@christianboyle: Should RWD be optional and priced separately as a feature or should it be the default approach and priced in from the start?
EM: It honestly depends on the project. Not every site needs to be responsive, while some wouldn't benefit from a site-optimised approach. And research into your audience's needs will answer that better than I ever could.

Stevie McKeown: In his book you advocate using percentages for padding and margin. However on your personal site you also use pixels and ems within both margin and padding. What is your current advice?
EM: Well, my site's not responsive – it's using a flexible, grid-based layout, but there aren't any media queries to speak of. But to your question: I'm a big fan of percentage-based measurements for horizontal margins and padding, and ems for their vertical equivalents.

Nelson Rodrigues: What framework do you recommend for a designer and developer duo starting in RWD?
EM: There are a number of great responsive frameworks out there: Foundation by ZURB, Josh Hopkins' Fluid Baseline Grid, and Twitter's 2.0 release of Bootstrap has an optional responsive grid.

Each looks pretty damned promising to me, but I should probably mention I don't use CSS frameworks for production code. I find them invaluable for prototyping, for getting ideas on the screen as quickly as possible, and seeing how they shake out in a responsive layout. But for final, client-ready deliverables, I like tailoring the code to the design, and finishing up with a responsive design that's optimised for small screens by default, but progressively enhances up to wider displays.

Paul Randall: What devices (smartphones/tablets) and breakpoints do you typically develop and test with?
EM: Well, I'm a big, big believer of matching breakpoints to the design, not to individual devices. If we're after more future-proof responsive designs, we should stop thinking in terms of '320px', '480px', '768px', or whatever – the web's so much more flexible than that, and those pixels are a snapshot of the web as we know it today. Instead, we should focus on breakpoints tailored to the design we're working on. And whether those breakpoints are pixel-driven or 'em'-based is up to you.

As for testing, I'm really fortunate to be able to work next to the jQuery Mobile testing laboratory. But if you're interested in building up your own testing kit, I'd highly recommend PPK's ALA article on the mobile browser landscape, and Brad Frost's device purchasing strategies.