Responsive Summit

Or: How I learned to stop worrying and love resolution independence

London • 23rd February, 2012

On 23rd February a few of us who care about responsive design got together around a table to discuss the challenges we have. These are some of the questions that folks wanted us to consider.

You can also check out Responsive Summit on Lanyard for the full list of blog posts, links and photos. We'll be keeping this list up to date as more get added.

Kisses, Josh, Alex and Chris


What should the client deliverables be in #rwd?


Depends on the client and scope of the project. HTML prototypes are ideal because they are closest to the real thing. Mockups communicating how to site will look at different widths may be sufficient though.


Of course, it depends. That's down to the individual designer and client to figure out. But it's safe to say prototypes are very useful in the RWD era. And we should be talking about delivering design systems (modules, libraries, directions for assembly.) But I also still deliver a few comps, as representative instances of that system. Better for the client to interpolate between those than for me to waste their budget comping up every permutation. Keyframes, not wireframes.


We agreed it's important to move away from 'ta-da!' presentations and not be afraid to show the client the mess along the way.


Responsive design is not economically viable for most agency work


More accurate to say agencies haven't yet found the way to present the value proposition and sales pitch around RWD. Ultimately its sustainability and audience potential give great business benefits. If an agency wants to practice RWD, it needs to figure out how to explain that value, and secure budgets that allow them to do it properly.


You gotta learn somewhere. Only through practice will you be able to get better/faster/more viable at RWD. Consider eating some of your time if the payoff looks worth it.


RWD definitely takes longer when you're approaching it with the traditional workflow, but agencies that are taking a more agile, iterative approach are finding that it doesn't take much longer than a static site. We just need to get the workflow right.


WD is not a one-size-fits-all solution, but has been promoted as such within the industry. Discuss (briefly)!


Seriously, I don't think anyone has been presenting RWD as one-size-fits-all. If they are, they don't really get it. It's a sensible option to address some of the flaws of fixed sites, but it definitely leaves many problems unsolved.


Rather than code techniques, examples and usage. I'm more interested in appropriate workflow for design for a varied and fluid web


This is one of those discussions that always ends in Agile. And rightly so. The mindset it represents is the natural destination for any RWD workflow, although Agile proponents are often far too concerned with the process minutiae.


I want to do more with responsive design, but I lack test devices (and the Android simulator is rubbish). What can be done?


The Opera and RIM emulators are excellent.


a large list of emulators is available here


Android handsets are cheap as chips, so a web developer doesn't have an excuse for not having at least one knocking around. I've also heard of informal schemes where people pool their devices between a bunch of freelancers / agencies.


Someone could make a fortune selling 'testing kits' of old devices


Why specify something as responsive when its just proper webdesign?


Like 'user experience', it's a useful phrase to reset expectations and mindsets. It's possible that will fade away with time.


I have tried to stop qualifying decisions and explanations with “in Responsive Web Design”. The process of making sites responsive works best when thought of as part of the whole, rather than a new technique.


I imagine in the future when RWD is ingrained in our workflow it will simply be known as web design.


Mobile JQuery & Responsive Design


jQuery mobile is a very heavy handed framework. 24K + 30k jQuery requirement + 7kb of supporting CSS


Is #rwd the final nail in the coffin for PS/FW comps? Or still a means to an end? I think we need _all_ our tools more than ever


We still need comps at certain stages in the design process. Use the right tool for the right context/conversation. Comps help us convey (and pitch) mood, look and feel and branding. Responsive wireframes/design in the browser (or whatever you choose to call it) help convey behaviour at various contexts. We tend to alternate between the two through much of the project (along with the odd 'traditional' wireframe to document data mappings etc.


Not at all. RWD means we have to rely on skill more than defined process - creating static comps is definitely a relevant skill to have, but we can't rely on it as our primary method any more. Sketching, design in the browser, prototyping all become more central to digital design thanks to RWD


What size screen and functions should we design towards, there are so many more than we can really design for but are there a few key sizes we could design for and the rest fit in or should we be elastic designing?


I would recommend 'phone', 'tablet-like-thing' (roundabouts a 10" tablet tends to work well), then a traditional desktop size. Give it about 18 months and we'll need to consider TVs as well. Everything else can typically be handled with a the flexible in between aspects of the design (although small, 7"-ish tablets are worth giving a bit of extra thought as they sit somewhere in the middle)


How should we prioritize content at smaller screens. Maybe 90% of the stuff HAS to be there. How can we solve that?


I use Page Description Diagrams a lot for this. Viewpoints have to come from the client (usually through a painful but useful meeting where you go through each element on the page), the designer, and customers through user testing etc.


Should pixels be abolished?


Not sure we'll be able to do that given that bitmap images are inherently pixel based (and you can't use SVG to replace a photo of Angelina Jolie on the red carpet!)


Should we stop building websites that are unresponsive totally?


You'd be hard pressed to say never but unless you're building for a specific device you're going to struggle to find one width to design for.


Do you think we could ever have a 'A Real Web Design Application'


I don't think so. The problem with some of our current tools is that we use them to do more than one tool can reasonably accomplish. Photoshop gets a lot of stick but it was never designed to be used in web design. I think its more likely we'll see people start to tackle specific problems with niche tools that do one thing really well.


With so many moving parts (different layouts for different screens, HTML/CSS, behaviors, etc.), web design will always need to be choreographed across multiple tools, mostly in a designer’s head. I agree that we will likely see more niche tools that solve specific problems really well, rather than a Web Design App™.


responsive design: 3 PSDs instead of 1 or designing to the device?


It depends on your design. Maybe your components need more than three breakpoints. Prototype interation early on can help you work out how much guidance you need from static comps.


Transitioning an enterprise to responsive design


Same way you eat an elephant: in small chunks. It'll take a long, long time because mostly it's a cultural and mindset change rather than a workflow or technical one. Show good practice, experiment, measure results, talk about successes rather than theory.


Responsive design != User experience. I don't think is just adjusting the layout to the device width. How can you brink the appropriate UX to specific device?


Enormous question that really needs a book. But we already have successful user-centred design tools at our disposal - research, sketching, prototyping, iteration all work well. Get your designs on the devices in question, and iterate, iterate, iterate.


Does mobile first really need to be Commandment #1, I have to entirely rebuild my design once it scales up.


Realistically, it's way easier to enhance than it is to somehow hide/replace/remove stuff you have already. That's why mobile first makes good sense if you are starting from scratch.


I think MF has been a great phrase to reset our understanding of how to design for the web. But I find it overly dogmatic. Mobile may be the right place to start, but it may not be. Leave that down to the choice of a skilled team.


does it cost our clients more for us to care about responsive web design


Realistically, yes. But, done right, the client will see business benefits.


We need to not only think of smaller screens in RWD but larger too - but this often seems to get left behind, particularl with "mobile-first" techniques and ideas. How can we encourage people to think about the larger picture or vision as well?


I think it's a bit early right now but mobile-first isn't incompatible with larger screens if you think of it as "start with the base content and behaviour, then enhance based on features/capabilities"...screen size is obviously one of those features


Should there be a "best-practice" guide for RWD?


I think Thursday showed that everyone has their own "best-practice" way of working, all were valid but unique to every designer. I think because RWD is it's infancy there are no guidelines yet because we're still figuring out the "best-practice" way to handle images, advertising etc. Eventually, I hope for a community-led document/book with the basic standards and guidelines that designers can continue to interpret into their own "best-practice" guidelines but at the moment it's too early.


Should the content on a responsive site be the same as the main site or is it ok to loose items


I believe core content and functionality should be the same. However, the tricky bit is figuring out what's core and what's expendable. And of course if your research and testing shows you need to take a different approach and cut things, do that rather than stick blindly to the script.


How come html5/css3 promotes rather than minimisez use of JS?


I don't believe that html5/css3 explicitly promotes the use of Javascript. The reality is that html5/css3 are still evolving and in order to use things that are still on the cutting edge, you need to employ some Javascript. Ideally we could lessen our dependence on it but the fact remains that if you are using Javascript to progressively enhance your designs, then you will still be in good shape when it is not available.


Can you find sthg less bloatware than bootstrap?


Zurb's foundation is a similar concept, not sure if it's lighter or not though


I'd love to hear more about responsive experience, i.e. this blog post by Mark Boulton


Please see the list of links here.



Fluid grids break the link between the proportions of the content and the proportions of the grid, making fluid designs less aesthetically beautiful than fixed-width ones. How do we address that?


We 1) observe the nature of fluidity, 2) challenge aspects of CSS that conflict with the nature of fluid graphic design, and 3) attempt to hack around any limitations. See:


I think the most robust responsive designs are going to be a mixture of fixed and fluid elements. The main challenge seems to be keeping white space in check while not breaking the relationships between elements (i.e. the logo on the top left getting too far from the nav on the top right). Define what needs to be fixed for your site (e.g. on a blog a good reading measure is important), and use fluid elements to fill in the gaps.


designing for content vs. canvas - pros and cons


The canvas is a lot more variable than the content, so it makes sense to design for what's most stable (content-out)


What's the best way of dealing with data tables in responsive layouts?


We tend to adjust them (add/remove columns fo data) on the server and therefore (hope to) serve the most appropriate data to each device rather than trying to adjust client-side. This works pretty well but we're experimenting with a few other techniques as well.


It's good to use a max-width on 1300px+ resolution?


It depends, how bad does your design handle widths above 1300px?


It depends on where the relationships start to break down within the design (e.g. is the logo getting too far from the nav?). Many layouts have a maximum width - stretch them any further and the layout breaks. It's at this point that you need to consider adding a new breakpoint (and adjusting the layout, perhaps adding side columns) or scaling the layout up (by increasing the base font size, if your site is built using ems).


Why have desktop apps been built adaptively for years, but we’re still building websites with static dimensions?


It was easier. We lacked tools to create a decent UI without images


Your thoughts on the suggestion that one should start with the mobile layout first and have it scale to desktop environments? Does starting with that limitation breed good design?


See "Does mobile first really need to be Commandment #1".


Getting away from 960 grids and into fluid layouts


The most important thing to remember with fluid grids is that the actual physical pixel dimensions they're designed at in Photoshop doesn't matter, because those dimensions will become percentage-based in CSS. That's why I propose the use of a 1000px grid in Photoshop to make the calculations much, much easier. More info at


According to Ethan Marcotte, Responsive Design is all about fluid layouts that continuously adapt to resolution changes. What about fixed-width layouts (i.e. Joni Korpi's Frameless Grid)?


Fixed-width layouts have their place, although these tend to be referred to as 'adaptive' layouts rather than fully responsive. In my mind, though, they're definitely still part of the general responsive approach to web design; using a combination might sometimes be appropriate. The key thing to remember with fixed grids, though, is that they're not as future-proof as fluid grids, which don't require specific breakpoints most of the time. As always, use the appropriate tool for the job.


Height & it's effects... For instance, fluid paragraph content that overflows to a column to the right when the window height is reduced. This is especially helpful for horizontal scrolling websites. :]


If you have an interface element that is dependent on a certain height then it's definately worth using a height media query.


Responsive tables for tabular data


One possible approach: Leave the table at a comfortable width, and fix the position of the headers. Would take a bit of CSS trickery, but would allow cells on a small screen to have space to be readable and keep their context.


What is best practice for responsive comment systems?


Disqus seems to be leading the way, as the platform is already responsive.


How to deal with mobile phones with higher resolution than desktops


If you're talking about higher resolution in terms of pixel density, loading the desktop-sized full-width image and then having the browser squish that down to fit the mobile will — in the case of the current iPhone Retina Display, anyway — have the desired effect of making the image appear crisp. I do that on my blog. Worth bearing in mind that images are still unnecessarily large, even for the Retina Display, though.


baseline grid / vertical rhythm in responsive web design


No solid answers yet, but @nicewebtype has been doing some nice thinking regarding 'Molten Leading'.


The transition of large Mega Menus to be responsive. What are the best options and how should we approach this task.


I am of the opinion that "mega menus" are usually not a great way to present navigation and help people find their way. Aside from my personal opinion, you should check out this post from Brad Frost about some of the emerging approaches to handling navigation for responsive sites.'.

Text Column Support


Works well in every browser, except not at all in any version of IE (as far as I know). Neat trick: to keep elements, such as articles, from breaking across columns, set their display to “table” in your CSS.



What's the best approaches to handle different bandwith speed now and how can we handle it in the future?


W3C spec and Mozilla's work.


You could try this script I developed called Pngy to get an approximation of bandwidth right now.


What do you guys think of sites responding to the input method available to the user? E.g. touch device=chunky tabs/big hit area. pointer device (blackberry bold/curve) has smaller tabs (smaller hit area) and thus makes use of the limited screen estate


Assuming a small screen = touch and a large screen is not is dangerous. Modernizr can detect touch so we can load a touch.css but we should have a media query.


A fine idea in theory, but detection isn't reliable enough yet, and there will always be new technologies that spoof others or fall outside previously-defined categories. Most of my current design work now assumes a touchscreen by default. This means generous targets, which are still beneficial for other input devices as per Fitts's Law and generally make for a clean, uncluttered look. If client feedback or user testing suggests we need something denser, there's flexibility to do that.


How do we design around "break points" for future-proofing against new screen sizes?


Design around content breakpoints not current device widths.


Design around content breakpoints but optimize around most common devices accessing your site and/or most popular devices in the market place. In other words, make sure it's fully flexible with no major hiccups in between breakpoints but don't spend precious resources fixing tiny problems that may not map to any common (for your specific problem) screen size. And be sure to test on real mobile browsers. Most problems on responsive sites have little to do with (often cosmetic) screen size issues and far more to do with overall legibility, manipulation and functionality (e.g. JavaScript) incompatibilities


What if the "next big device" isn't rectangular?


That's why content needs to be the priority rather than chrome. Whatever this device is, it will presumably be able to render a stream of content. Content is key, chrome is a 'nice to have'


How do we educate that 'responsive' is not just layout. (Content being responsive to the user. E.g, sitting on a train you wont want upcoming events when looking at a restaurant site)


Responsive is more than layout but trying to guess what the user will want based on context is (in my opinion) fools gold.


I'm with Stephanie - data-inferred context is the deadest of ends. Primary research and design ethnography are far more valuable, IMO.


what needs to become part of the HTML5 spec?


HTML Media Queries


Delivering different content based on network connection. Is this possible and how?


See "What's the best approaches to handle different bandwith speed now and how can we handle it in the future?"


How long will it take until we can use device APIs to get real information about a device’s connection speed.


See "What's the best approaches to handle different bandwith speed now and how can we handle it in the future?" Also it will take as long as browser vendors to implement. Developers should pressure them to increase priority.


I appreciate the value of APIs such as these but I think this may also be a case of "careful what we wish for". If we work up tomorrow and suddenly had these APIs, what would we realistically use them for? If knowing "you have bandwidth" is simply an excuse to keep loading sites (ie. users) up with heavy content is this really the best solution for the ecosystem? Some of this stuff will take years to resolve and may still remain incredibly messy, even with APIs. I think we need more holistic thinking about the overall problem of "reasonable, default, fit for purpose page weight"


How does (or should) responsive pages affect the scripts attached to the page?


It's not should you or shouldn't you load certain scripts at certain breakpoints, its much more about the network connection. One of the big things that came from this discussion was that having a simple way to get a good sense of the type of connection a person has could go a long way toward us knowing when to go ahead and load certain things (scripts/images/videos/etc) while always giving the user an override to go ahead and download that thing even if it takes 60 seconds :)


What's the definitive approach for responsive images, detecting resolution, retina, bandwidth etc?


All Webkit devices are incapable of detecting ppi right now but you can detect retina by using device-pixel-ratio


Best practices for keeping download sizes to absolute minimum for mobile devices (I.e. can mediaqueries prevent desktop stylesheets from being downloaded when on mobile?) OR should we detect bandwidth speed and be responsive to that too?


Let the user choose and serve lightweight content to everyone regardless



How to deal with third party ad networks with fixed size units.


One way is to retain a fixed-width column in your grid, and allow for fluidity in your other columns instead.


Another way is to design your minimum grid module size based on an ad unit size (or a multiple of it).


How long before Ad Servers will just support multiple resolutions?


When they can prove there's a return on investment for delivering ads in this way. I'm hoping one ad provider will start offering it, and others will follow.


The issues surrounding adverting within responsive design, how adverts should also adapt?


Ideally, the IAB would start work on some fluid ad formats. But unless providers start experimenting with that first, and find their CTRs substantially improved, I don't hold out much hope. Text ads of course present far less of a problem.


For web models that require a profit model (read:advertising), seems as though nobody has found the golden ticket to attractively and efficiently display responsive advertisements. What can we collectively do to work toward some ideas and answers?


We agreed there was a need for someone to bite the bullet and do responsive advertising successfully, to give others the courage to try it. In the Ad agencies' defence, it's a huge risk (none of us actually know for sure whether responsive advertising would be more successful than static)



In addition to working with the W3C for a web standards-based responsive image solution (possibly similar to the <video> spec), are there things the Apache (or Node.js) teams can do to help give us a reliable, browser-independant server-side solution?


See my write-up notes at


Image negotiation (e.g., different ad units at different width ranges). How to not display AND not load when not needed.


At the moment using background images seems to be the way to address your specific question. We talked about some things, such as, "load: none;" that many thought would help w/ this exact problem. However, this is only a subset of the larger issue around images on the web and our need for either a new format or, as is being proposed, a new <picture> element.


What is the best solution for serving images of different filesizes for different devices until we have a proper HTML solution with fallbacks like video and audio tags?


Not a solution for everyone but if you don't mind using the server, there is lots you can do with server-side detection/pre-optimisation combined with real-time client-side feature detection and adaptation. No formal 'solution' however, it's very much a case of building what you need. See our Adaptation and Pragmatic Responsive Design presentations on Slide Share for more context.


A standard way to handle responsive images with a minimal (no extra) HTTP requests


See comment above ("What is the best solution for serving images of different filesizes for different devices?"). Using the server enables you to serve an appropriate image on initial load. No additional request required unless the user reorients the display (and the device viewport size is such that a new image is even warranted)


Is a new HTML tag/structure for responsive images the way forward or should it be much broader like responsive "areas" (div/sections etc. to be displayed at certain screen sizes)? I know, this sounds more like a server-side functionality. Feasible?


I'm all for HTML Media Queries. If you're making adjustments to content, or changing how it is interacted with (changing from a list of links to a drop down, for instance), then you're changing the semantics of that content and that should be reflected in the DOM. Otherwise we're using CSS for semantic information, which surely is as bad as using HTML for presentation.


Best practices for image size and load times


Take a look at Pngy: Not perfect, but it is a start.


How do we solve the responsive image resolution issue without javascript and without loading more than one image?


Currently, the best solution is to load the lo-res one by default and use JS to swap that out for the hi-res version if it's detected that the browser is wide enough to display it. With JS turned off, the user will still get an image; albeit the lo-res one (which is a far better fallback than the unnecessary bandwidth required to deliver the hi-res one). Full details about this method at


There is a whole discussion around responsive images which lead to the proposal of a new html element (PICTURE), what's your opinion? See


We all agreed that the proposed <picture> element was a very sensible way forward.


Do we need a "load: none;" CSS rule instead of "display:none;"?


Would be nice :-)


Personally I'd like some way to do this in HTML. If it's content, and we don't want it to appear, then that's something that should be happening on the DOM side, not the presentation layer. HTML Media Queries anyone? :)


How can we use responsive images in a mobile-first way? What’s are best practices?


See our Adaptation and Pragmatic Responsive Design presentations on Slide Share.


iPhone 4 retina display not differentiating its devicePixelRatio in the user agent, which makes serving higher-res IMG SRCs difficult.


Current no feature information is being provided in a http request. Either we ask vendors to add in more information or we are left with UA sniffing or a JS approach.