According to many interweb portals, including forbes.com, and Mashable, 2013 was the year in which Responsive Web Design (RWD) became the dominant approach to website development. If you ask around, you get the feeling that responsive sites are now considered to be a matter of course, like an item ticked-off on some task list. The common perspective is that RWD is a smart and working solution that cuts off development time and, at the cost of some extra CSS. It delivers a website that looks nicely on any device of today and tomorrow. According to many developers and architects, the road to building such responsive web front-ends is neither long nor winding.

This article intends to offer a view of RWD from a different perspective. It’s not that RWD is bad, useless or harmful; it just has to be done right to be effective.

RWD at a Glance

A successful website is going to be essential for any business-of any size and type. My personal opinion is also that 2013 was the year when the forefront of the IT industry, and its marketing arm, progressed well beyond the notion of just going mobile. Antiquated websites that continue to display shrunk, stretched, minimized, or cut-off on devices smaller than a 13-inch screen are no longer acceptable to most users: They also penalize your SEO ranking, and should be avoided at nearly all costs.

Gone are the days when you could only create a site that is targeted for a single family of devices-mostly desktop browsers. HTML, together with CSS, was always designed for more than one type of device, desktop browsers and printers being the most common, though braille and aural devices were envisaged too. Today, the range has extended to devices having a very small or very large screen, limited hardware and software capabilities, projectors, TVs and devices that assume a specific user interface and experience. In the end, a successful website is a website that works very well with any sort of device.

Is RWD the ideal approach?

RWD uses the browser implementation of CSS Media Queries. As well as allowing different style rules for different media in the same style sheet, they allow you to dynamically select the stylesheet to apply to any given web page by attaching media queries to their <link> tags.

When a media query returns true, the corresponding style sheet or style rules are applied, following the normal cascading rules. If the query returns false, any corresponding style sheet will still be downloaded but they will not be applied. With CSS Media Queries you can link several CSS files to the page, each bound to an expression that returns a boolean: Every CSS file that matches the expression is applied. Media queries expressions use some run-time information such as orientation of the device and screen width and height. No more; no less.

RWD is great because once you have defined a few critical screen widths, and created ad hoc CSS for those widths, the actual nature of the requesting device doesn’t matter anymore. All that matters is how large is the screen or the orientation and whatever else the CSS Media Queries standard allows you to check. The core of RWD is the following markup snippet:

A media query expression on a LINK element is a just like a plain LINK element but with an extended syntax for the media attribute. In the beginning of HTML, the media attribute indicated the preferred medium for the stylesheet-whether screen or printer. Typically, a media query expression begins with “only screen and”. What follows “and” is the actual query. The query is the logical AND of micro-expressions that leverage the browser implementation of runtime properties such as width, max-width and height of the window. The keyword “only” is used to disambiguate and make older browsers ignore the extra content of the media attribute.

With reference to the examples above, the stylesheet view480.css is applied when the page is being viewed on a browser window no larger than 480 pixels. Instead, the stylesheet view800.css is applied when the browser window is less than 800 pixels wide. The order of media queries is critical as the browser’s implementation of media queries usually ends at first successful match.

Media Queries are defined and maintained by W3C. (See http://www.w3.org/TR/css3-mediaqueries.) According to the current standard, Boolean expressions can leverage the following properties:

Each browser that supports the Media Queries standard is expected to recognize these keywords in Boolean expressions and evaluate them. A newer version of the Media Queries standard is in the works and newer properties are being added. At the moment, though, none of the additional properties slated for inclusion in the standard seems to address the core issues of RWD.

Core Issues of RWD

Suppose you have two devices-say, two laptops-that display the same web page. Imagine also that both browser windows are 700 pixels wide. According to the snippets above, the Media Queries engine of the browser selects the view800.css stylesheet. Resize now the browser window on one of the laptops to 400 pixels. The browser intercepts the resize event, re-evaluates the expressions and applies a different CSS file as a result. If the new CSS file is not in the local cache, it is downloaded from the server with all referenced resources such as fonts and images. The net effect is that the two devices render different markup out of the same received content. The media expression is all that decides about the appearance of the content; and nothing in the media expression has to do with the actual characteristics of the requesting device.

If you think that this is just the major strength of RWD, well, read on as my take is that it just represents a significant weakness of RWD. RWD doesn’t distinguish devices; it only looks at screen width and a few other parameters. This is definitely the foundation of a multi-device solution; but it is a rather simplistic one. More, using RWD to build responsive sites leads to treating a browser window resized to, say, 480 pixels the same as a smartphone. From a rendering perspective, that’s just cool. From a performance perspective, instead, that’s just undesirable. You don’t want to force a smartphone to download (likely over a 3G connection) the same amount of data as a WiFi connected and computationally more powerful laptop. Last but not least, a smartphone (as well as a tablet) is a device with its own style, shape and expected user experience. More and more users expect to explore and enjoy a website over a device using the native metaphor of the device. This means that a website should seriously consider having different use-cases and layouts per device. You can hardly achieve this solely by using CSS.

Core Assets of RWD

It should be clear by now that we all agree that responsive websites are essential, but how do we do it? RWD has been the first answer; but in the end RWD has some hidden costs and may not be able to take your solution up to the level of flexibility that users require today or may require in the near future. In a nutshell, with RWD you can’t reasonably provide a solution that behaves differently (use-cases, layouts, selected content) on different devices, only for different screen-sizes, orientations and aspect ratios. The main responsibility of the web architect is determining whether a plain simple RWD solution that cross-cuts device differences is enough. If not, a different approach must be sought out.

Costs of RWD

Setting up a RWD solution is not as easy as it may seem. It takes much more than just using a framework like Twitter Bootstrap in the building of the markup. As I see things, costs of RWD are often underestimated on the wings of enthusiasm for a solution that seems to make device detection unnecessary. I would classify costs as below:

• Identifying the most appropriate content selection and layout that may be worked out nicely across various screen sizes
• Creating the navigation system for the displayed content
• Determining the size of images (smaller screens are usually far higher resolution than desktop monitors)
• Testing HTML rendering on browsers that support media queries and finding a workaround for those which don’t

The primary concern is the selection of the content to display and its most appropriate hierarchy and structure. How you organize content depends on the way you decide on your visual breakpoints.

In the RWD jargon, a visual breakpoint is a screen width (expressed in pixels) that forces the browser to apply a different stylesheet. Breakpoints are, in the end, determined by the design of the page, and should go in at the points at which the design stops working properly. However, for a start it helps to set a breakpoint around 400 pixels to cover legacy phones. You have another breakpoint around 800 pixels to capture smartphones and mini-tablets. Another one up to 1200 pixels for tablets; and beyond 1200 you have laptops and large screens. The number of visual breakpoints is up to you and the desired granularity of the solution you’re building. Thanks to RWD you can also add breakpoints that consider change of orientation.

The first task consists in identifying the content to display across the various breakpoints and the layout of the content for each of the breakpoints. Once you have HTML wireframes approved, you should focus on how CSS can shape up the same content and fit it into the desired layout. CSS is a declarative language; it’s not programming and doesn’t include custom logic. Therefore, what you can do with CSS is limited.

You are likely to face another problem with the navigation system of the website. There are no standards: it can be a drop-down menu, tabs, accordions, navigation bars, toolbars and the like. First and foremost you need a strong graphical idea for a successful RWD site. In addition, the HTML generated must be flexible enough to be rendered as a drop-down menu, toolbar, tabs or whatever you want to get on various screen sizes. This is where libraries like Bootstrap may help a lot. The key point I want to make, though, is that building a RWD solution is not as simple as arranging a bit of nice-looking CSS. There’s a strong graphical idea behind and a lot of quite sophisticated CSS, which is likely to be assisted in places by JavaScript.

A nice-looking website makes intensive use of images as part of the content as well as for embellishment. Images used to embellish are typically fairly small compared to images that are part of the content. In a responsive site images are displayed within containers whose size changes with the width of the browser viewport. Subsequently, images end up being shrunk and sometimes stretched. The quality of shrunk and stretched images largely depends on the resize algorithm employed. Browsers typically don’t do a great job at least compared to PhotoShop or even free tools such as Paint.NET. In addition, shrunk images are still large downloaded images displayed close to the size of a thumbnail. The paradox of images is that, in a RWD solution displayed on a small screen size, you download large images to display them in a few pixels box when you might as well just hide them. It’s probably not a big deal when the small screen size is a resized desktop browser window. When it is, instead, a smartphone, it’s going to be quite different.

RWD therefore requires using “flexible” images, such as SVG files. Where this isn’t possible, a solution is to use “adaptive” images. An adaptive image is not a technical trick. It’s just a blanket term that refers to the technique of having images downloaded in different sizes to minimize the impact on the bandwidth. However, this works as long as you set up a server-side engine-at your own cost.

Finally, an RWD site is designed to work regardless of the device. But it doesn’t really mean that you can design such a site and go to production without testing it on real devices. This poses a problem in identifying the most significant devices to test on and getting those devices. The ideal number of devices to test on is another tricky point-the highest number the best. Yes but this poses other issues such as costs of testing.

Summary

An RWD site requires you to step back and consider your approach from scratch. It is not a matter of adapting and shoehorning content on a smaller screen. A RWD solution, I must emphasize, is typically more expensive than a plain old, non-responsive website. You must convince users of these extra costs. One of the reasons for higher costs is that the responsive website must be tested on a growing number of supported devices. Worse yet, the initially brilliant idea of having a single design turns into a drawback as you must work out one-HTML that CSS can transform into different views. Often you end up downloading ad hoc blocks of HTML that just get hidden except for the visual breakpoint they’ve been designed for: This is not really an optimization.

Managing a RWD project is also different from a plain old site project. It is no longer possible to track progress with Gantt charts, but there are a lot of iterations and true collaboration with more technical people guiding less technical people. Questions like “how does navigation work” and “does this content reflow nicely on a smaller screen” are common at any time of the project and should be answered promptly and effectively. Developing a RWD project requires ad hoc skills-graphical and technical (that is web and HTML development) but also great doses of creativity and innovation.