[gfodor]

As someone who's been asleep at the switch with regards to responsive design I get the sense that it's, well, hard. Has anyone written about the "responsive design vs forking the website for mobile" tradeoff? If I were to start hacking together a site today I would probably just create two or three completely different layouts and DRY things up as much as I could in code, instead of trying to get the stars to align and get my browser to render the same assets correctly in all browsers.

In other words, responsive design seems to bring under the fold a use case that does not exist: physically resizing a browser window from a desktop size to a mobile size and having a page render correctly as you do it. Its a nice trick, but unless you assume the same client is going to need to see the content "respond" to changes in window size, then it seems prudent to take that use case off the list and simplify the implementation around the real use case: a client with a pre-defined browser window size hits a page and renders it, full stop. (with some small flexibility since users on desktop browsers do resize their window by some % occasionally) (Ie, if you focus on this case, simplest solution may be to fork it at render time in code where you have to and keep the CSS/etc straightforward.)

[WickyNilliams]

I think you're slightly off with your conclusion of responsive web design. It doesn't aim to cater to people resizing their windows (that's just an added benefit), it aims to cater to all devices regardless of window size.

Assuming we're still considering responsive design, if designed from a mobile-first perspective you'd be surprised how clean the code can be to deal with this. Start with minimal resources and most of your content stacked vertically so that it's lightweight and easy to consume on a touch device. Providing you've used relative units (ems in particular) you can scale up for larger screen with super simple media queries that just bump the font-size on body (e.g. body { font-size: 120%; }). You can find an awesome overview of this approach on Trent Walton's site [1]. Compare this with a hacky approach of doing desktop-first - you're loading assets (probably) unnecessarily, hiding chunks of markup to never be displayed, hammering your CSS to fit your desktop peg into a mobile hole. I know this doesn't cover everything, and any sufficiently complex site will require more than just bumping font-size, but honestly it doesn't have to be super difficult and full of horrible workarounds.

Now with the resposnive vs. separate site debate, the way I've always thought of it is responsive site for web sites, separate sites for web apps. Apps are sufficiently complex, with enough interaction that they require fundamental changes in HTML, CSS and JS to adapt to touch devices. Which leads onto the next point, serve a separate version of a web app based on touch/non-touch not window size, as it is the interaction method that should dictate design choices not how small the window is. It might then be wise to adopt a hybrid approach for your touch-specific app, where you scale up/down for larger/smaller touch-based devices.

Note that some of this may change and become significantly simpler with the advent of the Shadow DOM [2] and Flexbox layouts [3]

[1] http://trentwalton.com/2013/01/07/flexible-foundations/

[2] http://www.html5rocks.com/en/tutorials/webcomponents/shadowd...

[3] http://weblog.bocoup.com/dive-into-flexbox/

[DigitalSea]

Responsive web development is very hard. It's easy to get a firm grasp on it, but sometimes can be a struggle determining what happens to a footer or sidebar on a small screen. Another issue is scaling down a desktop site for a mobile site merely hides things, it doesn't reduce page load times or page weight. I think responsive can work well for some sites, but if you're hiding a lot of content for mobile users a mobile site is best. Mobile Safari will still load an image regardless of whether or not it's hidden, same with scripts and stylesheets you might not even be using on a mobile version of your site.

People often forget a 300kb image on a desktop site is fine, but making your site react to the width of a screen you're shrinking the image down but the file size remains the same. A 300kb image on a mobile site via a 3G connection times two or three can spell disaster for some people's data plans especially if they're close to going over.

Also a handy thing to remember with the target divided by the context is to multiply it by 100 to get the actual percentage value. I know you can simply move the decimal over two places, but that eliminates the step and ensures your calculations are always correct. So the final formula becomes: target / context * 100 = responsive percentage value.

[powatom]

I think it largely depends on the type of website you're running. For example, the kinds of websites I visit are relatively text heavy - I want to see the text regardless of which device I'm using. These websites are pretty light on images and few use any kind of 'novel' widgets or fancy animations. For these kinds of websites, I think responsive design is a pretty nice solution to the problem of different screen sizes. By and large, implementing a responsive design using the methods outlined in the OP is a nice solution which has the best trade-off between results and development time.

However, if you're running a photo-blog, then you probably want to only serve smaller images to mobile clients, and larger ones to desktop clients. Same goes for interactive websites. If your website has some novel navigation mechanism, or is very JS heavy, then you probably want to think more about whether you simply need to split your website into two separate versions: one for mobile, one for desktop.

I think a decent 'cut-off' point is when you start needing to muck about with handling viewport sizes through JS. At this point, it seems to me like your design isn't capable of handling the various screen sizes: if my mobile browser needs to run a bunch of javascript just to display correctly - by turning a menu bar into a drop-down menu for example, or modifying the page's navigation mechanisms - then in all honestly you might save yourself time and effort by simply creating a separate mobile version.

Obviously, there are exceptions to any rule, and I don't think there are any true clear boundaries, and even the 'JS boundary' can be managed nicely through progressive enhancement and dependency management.

Personally, I'm pretty happy with the 'one size fits all' solution. I don't think there's anything inherently wrong with media queries and simply modifying the CSS based on viewport size. It seems much more work to create and maintain separate versions of a website's theme for different viewport sizes.

[FredFredrickson]

I've always assumed the benefit is that you don't have to maintain a separate set of files for each window size... but it seems like, for all intents and purposes, you might as well be if you have to set up special cases for all sorts of window sizes, just in one document.

[gfodor]

Yeah I guess what I mean is you should always aim for DRY but who says the code reuse has to happen on the client? Why not do at least some of the necessary changes based upon screen size upstream on the server if it reduces complexity? My guess is this is probably harder for designers than hacking on CSS. I don't buy the argument that it's more or less DRY depending on where the reuse occurs. The only argument is that there is some value in having the browser understand the layout more fundamentally, but the only use case this enables is the "resize to mobile size on my desktop computer" case, unless I'm missing something.

[jimwalsh]

It's pretty DRY as you'll only be writing media queries for the parts of the site that need to change. Many times you don't have to write MQ's for everything. Writing completely different sites like you mentioned earlier would be/has been a hassle to maintain as opposed to a site that was originally designed as responsive from the onset.

The use case that someone might come to your site on a tablet, laptop and/or phone is a pretty common use case nowadays. Designing and maintaining one site to cover all of those is the goal. Simple MQ's to shift to each one is much easier to maintain than an entire other codebase.

[WickyNilliams]

One reason for choosing client over server: richness of data that can be queried. Media queries allow you to test for all sorts of features [1] which may be difficult impossible to test on server, e.g. color depth, pixel density etc.

[1] http://www.w3.org/TR/css3-mediaqueries/#media1