Responsive Web Design with Less Code


The Art of Building a website is a noble but challenging one. It got even more challenging after the advent of the mobile device. I can still remember quite vividly the moment when Steve Jobs introduced the reinvented Phone to much fanfare. The Tablet followed shortly after, and the concept of a ‘mobile web’ came into reckoning.

Sales of mobile devices (phones & tablets) currently surpass traditional personal computers by over 6 to 1. And mobile web traffic now makes up about 25% of all Internet Traffic. If you didn’t think you needed a responsive website two years ago, it’s getting a lot more difficult justifying that today. responsive web design is not without criticism, but neither are mobile users when they arrive at a non-responsive website that compels them – albeit unwillingly – to constantly zoom in and out and scroll from side to side.

Building a responsive website doesn’t have to be a zero-sum proposition, where you endure the ‘bitter pill’ of an arduous process as a means of justifying the ‘sweet sensation’ of having a website that looks and feels good on Mobile Devices. It can be “Win-Win” and it must be.

In this article, I will show you a way to build responsive websites much faster than you do right now using Restive.js to streamline your workflow and eliminate the need for media queries entirely.

The Problem with Responsive Web Design

Responsive web design has evolved into the predominant technique for making websites adapt to mobile devices. Due to the varied and smaller screen sizes of these devices (especially for smartphones), and the obvious awkwardness of viewing a desktop website on smaller screens, it goes without saying that the ability to be ‘responsive’ is essential to ensure that your online visitors can enjoy your website regardless of what device they use.

However, traditional responsive web design makes the process of building websites somewhat challenging to say the least, and here’s why:

  • Too Inefficient for Primetime: It takes too much time to build a responsive website. In the golden age of web design (before mobile devices), the only major problem was browser-compatibility (or Internet Explorer-compatibility to be fair to other browsers). Add all the challenges of adapting your website to multiple screen sizes to the mix and you have quite a major challenge. I remember reading answers to a question someone asked about how much longer it takes to build a responsive website and found the responses quite telling. One respondent said anywhere between 10% and 50% extra time. And yet another felt that the figure was much higher at 25% to 75% extra time. These kind of efficiency numbers can only hurt adoption, especially when time is tied to cost.
  • Too Expensive for Mainstream: I’m yet to come across a profession that charges less for spending more time doing the same job. The whole concept of ‘overtime’ pretty much sums it up. If designing a website today [which is expected to be responsive] is taking an average of 25% to 50% more time to complete [not to mention Testing and ongoing Maintenance], I don’t believe there’s any chance of a responsive website being cheaper to build than your traditional desktop one. As a result, the cost implications will cause some trepidation for the majority of website owners, especially when building the old website wasn’t exactly cheap. This also puts web designers in a bind because whether its billing by the hour, or a fixed pricing model, some of that extra cost is going to be passed on to the client.
  • Too Disruptive for Businesses to not cause Hesitation: Most websites today are hardly just HTML + CSS + Javascript anymore. Some use application engines like PHP, ASP, Rails, et al.; and some use content management engines like WordPress, Drupal, et al. And yet some have functionality that is powered by connected APIs and other external systems. For example, if your website has a secure personalized portal for customers, deciding to go responsive is a much bigger discussion than just HTML and CSS markup; it will involve a deep review of how you deliver service over the mobile platform, which may lead to very significant changes to your overall codebase. For a business that relies significantly on the online channel, a swift and pioneering sentiment may be quite easily usurped by one whose hallmark is caution.
  • Industry-Standard Techniques are not Robust Enough: Media queries have become the predominant technique for enabling responsiveness in websites today, but are they robust enough to quicken adoption of mobile-friendly websites?! Right now, media queries are far from intuitive, sometimes quite confusing and frustrating, and sometimes don’t behave exactly as you think they should. This is quite evident when you are designing a website across form-factors e.g. Desktop, Phone, and Tablet. For example, if I have designed layouts for these 3 device categories, how easy is it to implement this using media queries?!

I know that there are always two sides to every argument. Some might say that the reason responsive web design takes too much time or costs too much is because the practitioner is ‘doing it wrong’. And some might say that media queries works just fine and ought to be enough to quickly and easily build in responsive features into websites.

However, even when facts are in dispute, the general trend is undeniable. In a recent report – State of the mobile Web 2014 – that my company [Restive] published recently, we found only 15% of all the Fortune® 1000 websites to be responsive to a single URL address space i.e. without redirection to a dedicated mobile web address. Being that these companies are not exactly lacking in finances, we can probably rule out cost as a factor for low adoption – but we can’t rule out the relative inefficiency of responsive web design workflows.

Now, I’m not exactly an authority on Formula 1 matters, but I can safely say that Sebastian Vettel can’t win a Grand Prix race [today, heyday, or any day] behind the wheel of a Prius, irrespective of how awesome he is as a driver. If you’re going to win a race where all the cars are Lamborghinis and Ferraris, you’re going to have to ‘pedal-to-the-metal’ in something equally spritely. In like vein, if you’re going to build responsive websites faster, you’re going to need a much faster workflow than the one you’re currently using.

An Alternative Approach to Responsive Web Design


Making your website look, feel, and perform well on every web-enabled device should be your ultimate goal and all your web design tactics should be focused on this. You might not get there today or tomorrow, but this should be an ideal that you constantly strive to attain. Mobile devices are here, they are not going anywhere, and more device categories might be around the corner. This is the new reality! As a result, designing a website today with the mindset that making it responsive is an ‘added extra’ is a losing strategy. Let’s face the facts: It doesn’t depend any more!

All web design should be ‘responsive’ by default. All websites must adapt to different environments that need access. It doesn’t matter if you are starting with the desktop version of a website, you must always pause and consider whether your design and functionality will work as anticipated on other devices, even if certain items of the layout are resized or rearranged, or certain devices aren’t as contemporary as you would like them to be. How to do this in the quickest, most-intuitive, stress-free way is the ‘holy grail’ of contemporary web design. And it all starts with a streamlined design workflow.

Inline CSS Responsiveness

If it is taking so long today to develop responsive websites, maybe we should go back to before phones [the smart ones] and tablets, and try to figure out what happened. Back then we still had HTML and CSS like we do today. We also had media queries like we do today, although they were intended for other special tasks like printing and accessibility. Therefore, it’s very plausible that the efficiency baseline of the traditional web design workflow was breached with the advent of mobile devices and media queries as the preferential technique for responsive web design.

We need to go back to a design workflow where the standard is that inline CSS rules are 100% responsible for responsive web design implementation. What I mean by this is that when I want to implement responsive enhancements on my layout, I should be able to define that enhancement directly in my main CSS markup.

So I should be able to do this:

#my-element-id {/* Styles */} //my desktop style rule
.phone #my-element-id {/* Styles */} //my general smartphone device style rule
.tablet #my-element-id {/* Styles */} //my general tablet device style rule

Instead of being stuck with this:

#my-element-id {} //my desktop style rule

@media only screen and (min-width : 320px) and (max-width : 480px) {
/* Styles for some mobile devices */

@media only screen and (min-width : 321px) {
/* Styles for some other mobiles */

/** ...And yet more Media Query Directives **/

Yes, media queries are CSS, but in this case they seem to be a serious productivity buster, primarily because of all the distributed and illogical ‘Markup Realms’ that they will introduce into your CSS. By virtue of @media directives, your once sequential codebase is now split into multiple regions, each of which you will have to manage and maintain separately, often with less than enjoyable consequences.

Let’s consider a real website project to put this in perspective.

A Real-world Responsive Design Project

Let’s assume you are designing a simple website. You have designed only the desktop layout and have the HTML and CSS markup finalized. You do intend for the site to be fully Responsive. Based on your expectations, you would like for tablet users to have a somewhat varied experience from smartphone users on account of the disparity in physical size compared to phones.

You can view a demo of our web page here.

As is evident, we are using a centered and fixed-width model that is 960px wide. And being that we have no major challenges with our desktop version, we now want to add responsive enhancements, specifically for phones and tablets.

First, let’s decide what we want to have happen when our website encounters a mobile device:

  1. We want to move from a fixed-width to fluid-width layout if the device is a mobile device e.g. phone or tablet. Also we want to add 10px padding to each side i.e. left and right.
  2. We want to reduce the size of the logo if it is a mobile device. Since our logo is text, we want a 10% decrease in font-size for tablets, and a 20% decrease for phones. And we also want the logo centered if the device is a phone, and right-aligned if it is a tablet
  3. We want to collapse the main menu from horizontal to vertical if the device is a Phone (in either orientation) or Tablet in portrait orientation. When the menu is collapsed vertically, we want the height of individual menu items to be reduced, and we also want to place horizontal line dividers to demarcate said menu items.
  4. We want to hide the Sidebar content for all Phones. We also want the Sidebar hidden for all Tablets in portrait orientation, but visible when in landscape.

So being that this is a simple website, we have just 4 Responsive enhancements we want to implement.

Using a media queries approach, let’s see if we can add these features to our website and make it Responsive:

/** Responsive CSS - Using Media Queries **/
@media only screen and (max-width: 320px) {
    /**phone in portrait CSS rules here**/
    section {width: 100%; padding: 0 10px;}
    header #logo div {font-size: 320%; text-align: center; margin: 0 auto;}
    header #menu-container {height: auto;}
    header #menu nav ul {height: auto;}
    header #menu nav ul li {float: none; width: auto; height: 40px; 
		line-height: 40px; border-bottom: 1px dashed #444;}
    #content #main{float: none; width: 100%;}
    #content #sidebar{display: none;}

@media only screen and (min-width : 321px) and (max-width : 480px) {
    /**phone in landscape CSS rules here**/
    section {width: 100%; padding: 0 10px;}
    header #logo div {font-size: 320%; text-align: center; margin: 0 auto;}
    header #menu-container {height: auto;}
    header #menu nav ul {height: auto;}
    header #menu nav ul li {float: none; width: auto; height: 40px; 
		line-height: 40px; border-bottom: 1px dashed #444;}
    #content #main{float: none; width: 100%;}
    #content #sidebar{display: none;}

@media only screen and (min-width : 481px) and (max-width : 768px) {
    /**tablet in portrait CSS rules here**/
    section {width: 100%; padding: 0 10px;}
    header #logo div {font-size: 360%; text-align: right;}
    header #menu-container {height: auto;}
    header #menu nav ul {height: auto;}
    header #menu nav ul li {float: none; width: auto; height: 40px; 
		line-height: 40px; border-bottom: 1px dashed #444;}
    #content #main{float: none; width: 100%;}
    #content #sidebar{display: none;}

@media only screen and (min-width : 769px) and (max-width : 1024px) {
    /**tablet in landscape CSS rules here**/
    section {width: 100%; padding: 0 10px;}
    header #logo div {font-size: 360%; text-align: right;}
    header #menu nav ul li {width: 20%;}
    #content #main{width: 65%;}
    #content #sidebar{width: 33%; padding: 0 0 0 2%;}

As simple as this website appears to be, the above code took me about 20 minutes in all to rationalize and setup [I mean…I can get car insurance in half the time?!]. The markup looks like it could work, but it appears that we’re going to have a number of major operational challenges brought about by the unintended consequences of media query overlap:

  • If anyone is using a desktop monitor with SVGA resolution (1024 x 768), they’re going to get the ‘tablet in landscape orientation mode’ version with a fluid width. Maybe not a major issue, but you would probably have wanted them to get the desktop version.
  • There are numerous phones on the market that have widths in landscape orientation that are larger than 480 pixels e.g. iPhone 5. This means that the media directive that we had designated for ‘tablet in portrait orientation mode’ will be applied if the device is an iPhone 5 in landscape orientation. This is definitely not what we would have wanted to happen.
  • Similar to point 2, there are also a lot of popular phones out there with widths in portrait orientation greater than 320 pixels. So the media directive for ‘phones in tablet orientation’ will be applied to any phone that fits this criteria.
  • There are also numerous popular tablets with a landscape orientation width greater than 1024 pixels. Take the Google Nexus 10 (a tablet) which has device independent pixel dimensions of 800px high by 1280 pixels wide (in landscape). Changing our max-width value from 1024 to 1280 should sort this out, but now some notebook computers will get the look-and-feel not specifically intended.

I could go on, but I think the point is made.

This is a very simple website we’re trying to build here. Something as simple as the four responsive enhancements we have clearly outlined shouldn’t really be such a hassle to setup, tweak, and test. It’s clear that testing this website, and tweaking it, will probably take up to an hour if not more. For a more complex website, by the time you’re done with all the testing iterations, your brain and your body will be weary from all the time you’ve spent on StackOverflow, et al., trying to find the best route out of ‘Media Query Tweak Hell’. And we haven’t even drawn straws for who is going to maintain all this?!

I’m sorry, and I sincerely apologize to the entire responsive web design industry and everyone who believes that media queries are the best thing to happen in web design since HTML + CSS, but I simply CANNOT take this any more. I’ve looked at media queries… I’ve really tried to like them with all my heart… and I have failed. I don’t mind being one of the few that’s going to revolt against this — terribly inefficient — ‘machine’. There just has to be a better, faster way to build responsive websites in a timely manner.

Meet Restive.js

Restive.js Cover Page

The premise behind Restive.js is simple: Go Responsive with Less Code. It is a jQuery Plugin [or framework if you like] that helps you add responsive features to a website almost instantly. It does some behind-the-scenes heavy-lifting and smart DOM manipulation to give you more flexibility. It has quite a lot of features [that you can explore at your own time], but in the context of building Responsive websites, it enables you to define all of your Responsive CSS markup inline.

Installing it is simple and everything you need to both install and set it up for our specific circumstance is roughly 10 lines of code + markup total.



Restive.js has the basic format of most jQuery plugins. In the above code + markup, we have defined 3 options, ‘breakpoints’, ‘classes’, and ‘turbo_classes’ and I’ll just briefly explain what they do.

breakpoints and classes are the primary options in Restive.js. What they do is setup declared breakpoint ranges, and then apply classes to the given selector as the viewport width of the device on our website matches that specific range. So if we had defined breakpoints: ['240', '320'], and classes: ['240-css', '320-css'], the plugin would setup the breakpoint ranges of 0 to 240 pixels, and 241 to 320 pixels, and then it would add the class 240-css to the <body> tag (which is our selector) if the device viewport width fell between 0 and 240 pixels, and it would add 320-css if the viewport width was between 241 and 320 pixels. This is pretty much how these two options work hand-in-hand.

turbo_classes is a special feature of Restive.js that adds classes [in addition to those defined in the classes option] to our <body> tag when certain pre-defined conditions are met e.g. when the device is a mobile device, when the device is a tablet, etc. There are about 9 specific conditions in all. Right now, we’re using 5 because that’s all we need. So for example, is_landscape=landscape will tell the plugin to add the class landscape to the <body> tag if the device is in landscape orientation, and being that Restive.js is stateful, this class will also be removed if the device switches to portrait orientation.

In our particular circumstance, we do not need conventional breakpoints, as we are focused primarily on form-factors. Hence we will simply define breakpoints: ['10000'], and classes: ['nb'], to create a range from 0 to 10,000 pixels that will match all devices. Then we simply use turbo_classes to apply specific classes pertinent to our aspirations.

So since we have set all this up, and knowing that Restive.js will take care of all the required DOM manipulation, we simply add the following CSS rules to our existing markup

/** Responsive CSS - Using Restive.js **/
.mobi section {width: 100%; padding: 0 10px;} header #logo div {font-size: 320%; text-align: center; margin: 0 auto;}
.mobi.tablet header #logo div {font-size: 360%; text-align: right;} header #menu-container, .mobi.tablet.portrait header #menu-container {height: auto;} header #menu nav ul, .mobi.tablet.portrait header #menu nav ul {height: auto;}
.mobi header #menu nav ul li {float: none; width: auto; height: 40px; line-height: 40px; border-bottom: 1px dashed #444;}
.mobi.tablet.landscape header #menu nav ul li {float: left; width: 20%; height: 60px; line-height: 60px;}
.mobi #content #main{float: none; width: 100%;}
.mobi.tablet.landscape #content #main{float: left; width: 65%;}
.mobi #content #sidebar{display: none;}
.mobi.tablet.landscape #content #sidebar{display: block; float: left; width: 33%; padding: 0 0 0 2%;}

And that’s it! Simple, straightforward, intuitive, and inline markup that allows us easily and quickly implement our desired responsive features. If you want to target a CSS rule for all mobile devices, you simply prepend .mobi to the existing rule. If you want to do same, but only for phones in portrait orientation, you just prepend This approach enables you to implement virtually all the Responsive features you want at the speed of thought.

So how does Restive.js know what is a phone and what is a tablet?! Well, the plugin has advanced device-detection built right in. How accurate?! Well, I’d have to say 99% accurate because I haven’t tested it on all mobile devices known to man. However, I’ve tested it on all the mobile devices on BrowserStack, and virtually all of the contemporary devices on Nokia Device Lab e.g. Nokia Lumia and Asha Series, with 100% accuracy. And Restive.js will only get better with time as more updates are made to it.

The primary benefit of this approach is in testing. Unlike when working with media queries, you simply do not need to test on a plethora of mobile devices. All you need to do is use pick a popular phone [or emulator] e.g. iPhone 4 or Samsung Galaxy; and a tablet e.g. iPad 2, and that’s it. You don’t even need a real device, you can use an emulator like the one in Google Chrome (see below for more on responsive website testing). The only reason you would need to test on multiple devices is simply out of curiousity, not out of necessity.

Also, a key advantage of this approach is code/markup maintenance. The initial Javascript code we highlighted earlier that is required to setup Restive.js is literally ‘Set-and-Forget’; you never need to maintain it, unless you want to add additional turbo_classes items to the mix. For the CSS markup, anyone can maintain it, even if they didn’t actually write it; you don’t need to figure out what someone was trying to do, it’s pretty clear and straightforward.

A Quick Note on Testing Responsive Websites

It has sort of become a tradition that if your website doesn’t adapt when you resize a desktop browser window then that automatically means that it isn’t responsive. I didn’t know it was such a big deal until we launched the Restive.js website and had a lot of folks chastising us for being a Responsive Plugin without actually having a responsive website. That would, of course, be incredibly ironic if it were true. I can only hazard a guess that these lovely people were being misled by this often used – but terribly inaccurate – responsive website check.

The best way to determine if a website is responsive is NOT by resizing your desktop browser, but by using a mobile device emulator. On the Restive blog, there is a post highlighting a better way to test responsive websites using the emulator approach. It’s more accurate, and is much more professional, so I kindly urge you to drop the ol’ Resizing Browser Window habit.

Restive.js Drawbacks

So Yes, Restive.js significantly simplifies your workflow, but this simplicity comes at a small cost that we will review here:

  1. Restive.js is a jQuery Plugin so you’re going to have to load jQuery before you can use it. If your site wasn’t using jQuery already, this will be 2 additional HTTP requests. In terms of bytes, Restive.js adds about 21 kilobytes (Minified + GZipped). So adding the approximately 33 kilobytes (Minified + GZipped) of jQuery, this takes the total additional payload to about 55 kilobytes. Given that the average website is over 1.5 Mb in size, it’s a small percentage of the total payload, but it is still something.
  2. Performance-wise, Restive.js is technically not as fast as media queries. However, the speeds we are talking about here are in milliseconds and will be discernible to only the most pedantic Cesium atomic clocks. In the simple tests I did for both pages using WebPageTest, the total ‘first view’ load time was 0.497 seconds for the media queries page, and 0.942 seconds for the Restive page; for ‘repeat view’ the results are much closer at 0.314 seconds and 0.375 seconds respectively. Restive.js is fast enough for you not to notice that it’s actually there.

Responsive Framework Comparison

Restive.js is not the first framework for helping you build responsive web designs faster, and I thank God for that because there’s no way this issue hasn’t fired anyone up to actually do something about it. There are currently a number of popular frameworks available today such as Bootstrap, Foundation, Skeleton, and others. All these platforms do different things and it would ultimately be up to the web designer to choose the best one for the job.

The major difference between these other responsive frameworks and Restive.js is that the latter does not use media queries – and as a result is immune to all of its incumbent challenges. Also, being that these frameworks sort of pigeonhole you into a specific design motif, it’s quite difficult to maintain the uniqueness of your web design, unless you’re willing to spend even more time customizing UI components and such. And yet another difference is the bloat some of these frameworks impose on you: Bootstrap alone levies about 120KB in CSS markup, which might be overkill if all you’re looking for is responsiveness.

Restive.js is targeted more at the purist web designer, someone who is quite comfortable building a full website with HTML and CSS (without the use of any all-in-one frameworks), but who just needs to get past the responsive implementation hurdle without breaking a sweat. Let’s not forget that there are still lots and lots of websites out there that are not responsive, and it is much faster to tweak them by adding the required responsive features using Restive.js than it is to do same using some of the aforementioned frameworks (and I will prove this in a subsequent article).

In Closing but Moving Forward

Designing websites for Desktop environments is a relatively routine task, and web designers have done what they can over the years to optimize their workflows to that standard. The introduction of the mobile web-enabled device has created significant disruptions to these workflows, not only because of the learning curve, but because the media queries approach is somewhat unwieldy and inefficient. Granted, certain skilled practitioners of media queries can accomplish much in less time, but for the majority this general inefficiency still persists.

Restive.js provides both a tool and a technique for building Responsive websites in far less time and with virtually no interference to long-established design workflows. Normalizing the responsive web design workflow for efficiency will go a long way in enabling the rapid creation of websites that work everywhere we want them to. Here’s to that happening sooner rather than later.

Related Topics

This page may contain affiliate links. At no extra cost to you, we may earn a commission from any purchase via the links on our site. You can read our Disclosure Policy at any time.