The Official Weblog for Restive Labs

CSS Media Queries vs Restive.JS

  Obinwanne Hill        December 16th 2013
CSS Media Queries vs Restive.JS

Responsive Web Design has been with us for a few years now. Ever since the concept came to the fore, Web Designers the world over have invested their time, blood, sweat, and some tears (we can't rule that out) to learn how to make their Web sites Responsive. Indeed, this noble quest is not without merit: The Desktop is no longer the only Web-enabled Device, and we need to accommodate the new entrants.

However, things seem to have gone amiss when everyone decided that CSS Media Queries was the method to do Responsive Web Design. When doing some research on this blog post, I stumbled on the Wikipedia entry for Media Queries where it says it is a cornerstone technology of Responsive Web Design. How did this happen?! I say this with the benefit of Hindsight, of course! I'm really puzzled as to why almost everyone assumed the 'Just Go With It' position?! Well, I guess because it's a Web Standard, but I hope I'm wrong.

The Problem with CSS Media Queries

So if you've been doing a lot of Responsive Web Design lately, it's safe to say that you are quite heavily invested – intellectually and otherwise – in CSS Media Queries. Maybe you're not 100% satisfied with it, but you've made do with it, and for that I strongly applaud you for your strength, endurance, and courage. If I could, I would bestow you all with medals. I don't know about you, but sometimes I feel like "Responsive Web Design with CSS Media Queries" should be an Olympic Event.

About 18 months ago, I started seriously delving into Responsive Web Design. I was really excited initially about the concept and all. However, when I got to CSS Media Queries, it didn't take me very long to figure out that this wasn't the way to go, for two major reasons:

  1. Capability
  2. Maintainability

So let's go after each one in sequence.


There are some things CSS Media Queries can do, but then again there are some things that it can't dream of doing...yet. Web Designers are all different, and all have certain ways they want their Web site to perform in Mobile devices. Let's look at 4 different scenarios that may come up for anyone building a mobile-ready Web site:

  1. You want your Web Site to have two different menus, one for Personal Computers and another for Mobile Devices, or you want to make your layout fluid (width = 100%) on mobile devices (or you just want to know you can do this if you ever wanted to)
  2. You want your Web Site to do something special when the user rotates their Device from Portrait to Landscape Orientation e.g. show a sidebar…oh! but only for Tablets, not for Phones
  3. You want your Web site or Web app to be themed specially for a specific platform e.g. a different look for iOS and a different look for Android (Yes! Sometimes its "Perfect Customization or Nothing"!)
  4. You want to build a Web site with a design methodology that puts priority on form-factor e.g. phone, tablet, etc. before honing in on breakpoints. Truth is, a very large proportion of web sites out there don't even need breakpoints (More on this in a future blog post)

These scenarios could go on and on. All Web Designers are different, and all want to do different things with their layouts. Being flexible enough to anticipate what a designer would like to do, and accommodate that requirement goes a long way in keeping everyone happy and productive. And if you didn't already notice, CSS Media Queries would have a pretty hard time coping [albeit adequately] with these 4 scenarios.


It's really not so implausible to imagine yourself working on a pretty web site with a somewhat elaborate design that needs to be mobile-friendly. You have multiple declared breakpoint ranges, maybe 8 or more, depending on what you want to have happen to your layout at what viewport width and at what orientation.

So what would be some of the likely problem scenarios we are likely to run into when maintaining our Responsive Web site:

  1. You have to setup individual @media directives for each and every declared breakpoint range. This is usually very time-consuming because all your mobile CSS style rules must be duplicated across each and every breakpoint range…not very fun when your Web site is more than a square box and some text
  2. If I needed to make a simple change to a mobile layout, I would have to edit identical style rules in each and every declared breakpoint range. In addition, I really couldn't be very granular with these edits e.g. What if one day I decided I wanted my background to be red in mobile devices, the only compromise would be to change the background-color in each breakpoint range that I hoped represented a mobile device
  3. And what would be the case if I was thinking of upgrading my Web Site?! Let's say I wanted certain parts of my design to adapt for just tablet devices, or for just phones, how would I accomplish this?! This doesn't seem like too much to ask, but it looks like we're going to have to find some kind of clever hack for our breakpoints involving pixel density and resolution. Intuitive Much?!

I know that there are some Web Design Ninjas that could probably do some wonders with CSS Media Queries, I'm not denying that. However, for the majority of us who are stuck in a World where billable hours and tight deadlines reign supreme [unlike in Ninja-Land], time isn't exactly an abundant commodity. So spending hours on endless Web searches and Forum-questioning trying to make a bad Responsive Web Design method work is somewhat ludicrous to me.

I don't know about you, but in my humble opinion, CSS Media Queries just wasn't built very well to handle this 'Mobile Web Design' thing. I've never really warmed up to them I must confess: They remind of minions in 'Despicable Me' who never really do what you want them to do when you want them to do it. I just feel like it's the wrong tool/method for the job, and maybe we could all do with a refreshing new approach.

Enter Restive.JS

Restive.JS is a JQuery Plugin that makes it super-easy to add Responsive + Adaptive features to any Web site. But saying 'JQuery' these days is almost like saying 'Javascript', which sort of puts a lot more emphasis on 'Development', so why would any Web Designer want to use it?!

Well, first of all, Restive.JS aims to totally replace the need to use CSS Media Queries in your Responsive + Adaptive Web Design projects, and for good reason. It does this by enabling Web Designers to focus exclusively on using HTML and CSS to build Responsive + Adaptive Web sites. All the Web Designer needs to do is two very simple things:

  • Install the Plugin (2 lines of HTML code)
  • Configure the Plugin (about 10 lines of HTML + Javascript code)

And that's it! It takes all of maybe 5 minutes. Once you do this, you never have to come back to the [Javascript] code ever, not unless you want to tweak a few things like adding new breakpoints, and that takes seconds to complete. All your work is now concentrated on HTML and CSS, which is a good thing.

How it Works

So a typical Restive.JS setup could look something like this:

<!-- Install JQuery version 1.7 or higher -->
<script type="text/javascript" src="jquery.min.js"></script>

<!-- Install Restive.JS -->
<script type="text/javascript" src="restive.min.js"></script>

<!-- Setup Plugin -->
$( document ).ready(function() {
        breakpoints: ['240', '320', '480', '640', '720', '960', '1280'],
        classes: ['rp_240', 'rp_320', 'rp_480', 'rp_640', 'rp_720', 'rp_960', 'rp_1280'],
        turbo_classes: 'is_mobile=mobi,is_phone=phone,is_tablet=tablet',
        force_dip: true

The Installation part is pretty straighforward, we just link JQuery and Restive.JS.

From the Setup Plugin bit, we see that we have defined four options for Restive.JS: breakpoints, classes, turbo_classes, and force_dip. Let's now explain what this all means.

The Restive.JS will actively monitor the viewport of any devices that visit your web site for the following declared breakpoint ranges (as we have defined them above): 0 to 240px, 241 to 320px, 321 to 480px, 481 to 640px, 641 to 720px, 721 to 960px, and 961 to 1280px (Please note that these are device pixels by default and NOT device-independent pixels). If the viewport of the device that visits our Web site is between 0 and 240 pixels wide, Restive.JS will detect this and it will add the class rp_240 to the <body> tag (which is our JQuery selector); if the viewport is between 241 and 320 pixels wide, it [Restive.JS] will add the class rp_320, and so on. This is basically how breakpoints and classes work. If you notice, the number of breakpoints items is equivalent to the number of classes items.

turbo_classes is a special feature of Restive.JS that will add one or more classes [in addition to any other classes previously added by classes previously mentioned] to our <body> tag when certain conditions are met. From our settings, we have specified that we want to add three classes; mobi, phone, and tablet when the device is a mobile device, a phone, and/or a tablet. So if an iPhone 4 visits our web site, the turbo_classes option will tell Restive.JS to add mobi and phone as classes to the <body> because an iPhone 4 is a mobile device and a phone also. If it was an iPad 2 instead, then what would get added would be mobi and tablet. You'll see why this is useful later on.

Finally, the force_dip option will force breakpoints to consider device-independent pixels [instead of device pixels] in its declared ranges. Restive.JS by default considers device pixels. However, in certain scenarios, you might want to go with device-independent pixels instead and the force_dip option let's you do this. Consider an iPad 4, which has a retina display [pixel ratio of 2] and a device pixel width of 1536 in portrait orientation. This means that it will not match any of our defined ranges since our breakpoints top out at 1280. However, as our Web site is not so complicated as to warrant additional CSS rules for retina tablets, we want all retina tablets to be classified the same as non-retina tablets e.g. iPad 2. So by setting force_dip to true, Restive.JS will see only in device-independent pixels, so 1536 [device pixels] will be considered as 768 [device-independent pixels], which obviously matches one of our declared breakpoint ranges.

So that's basically what the code above does. You can learn more by reading the Restive.JS Docs.

Markup at the Speed of Thought

The good thing about Restive.JS is that you can implement things on your Web page within seconds of thinking about it. Going with our current setup for Restive.JS above, here is just one scenario:

Say I have a Web Site which has a sidebar that is styled by the following CSS Rule

#sidebar {background-color: #eee; width: 320px;}

And now I wanted the sidebar hidden on all phones, but visible in tablets only if the tablet was in landscape orientation, I would just do something like this in my CSS:

.mobi #sidebar {display: none;}
.mobi.tablet.landscape #sidebar{display: block;}

And what if I wanted the sidebar to have a left border, a percentage width instead of a fixed one, and I wanted a different background color?! Well, all I'd need to do is go back and make the update like so:

.mobi.tablet.landscape #sidebar {display: block; width: 35%; background-color: #fff; border-left: 1px solid #eee;}

I hope it's starting to make sense now?! Think it, then Do It! No Web Searches for "How do I...?!" and such. Just friggin' Do the Dang Thing! It took all of a few minutes in all. I wonder how long it would take me to do this with CSS Media Queries?!

In Closing

Please don't get me wrong: CSS Media Queries are NOT evil. I had cause to use Print Media Queries a few months ago and I liked it a lot. Maybe I liked it because all you need is a single @media print directive to get it work, but the point is that it works and there really isn't any other plausible alternative when trying to make a Web page printer-friendly.

Maybe one day CSS Media Queries will be a totally awesome method for Responsive Web Design. Maybe one day it will be so intuitive and robust that it would do anything you ask of it at a moment's notice. Not today though! Unfortunately, even updates to the Web Standards are not like bug fixes, so even if all these great things become a Web Standard, it still takes a while to achieve ubiquity. And who knows if this 'Web Browsing' thing we're all doing now is going to be the norm 5 or 10 years from now [that is if we're not Air-swiping or something by then].

Anyway, it's going to take something really disruptive and influential to phase out HTML + CSS + Javascript, so for the foreseeable future we will be accessing the Web via screens on handheld and desktop devices for a while longer. However, when it comes to Responsive Web Design, Restive.JS is a strong alternative to CSS Media Queries. But don't take my word for it, give it a shot and see if it works for you.

Happy Less Coding!

What is Restive?!

Restive Labs is a creator of software and services for helping Web designers, developers, and enthusiasts build Websites that are both Responsive and Fast.