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

htbrwsf-image-interestingman-main

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.

<!-- 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>
     
<!-- Configure Restive.js -->
<script>
    $( document ).ready(function() {
        $('body').restive({
            breakpoints: ['10000'],
            classes: ['nb'],
            turbo_classes: 'is_mobile=mobi,is_phone=phone,is_tablet=tablet,is_portrait=portrait,is_landscape=landscape'
        });
    });
</script>

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;}
.mobi.phone header #logo div {font-size: 320%; text-align: center; margin: 0 auto;}
.mobi.tablet header #logo div {font-size: 360%; text-align: right;}
.mobi.phone header #menu-container, .mobi.tablet.portrait header #menu-container {height: auto;}
.mobi.phone 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 .mobi.phone.portrait. 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.

(3 Posts)

Obinwanne Hill is Founder and CEO at Restive Labs, a company that aims to build tools and develop techniques for Web professionals and enthusiasts to enable them build Faster, More Responsive Websites. He developed Restive.JS and is actively working on a World Engine capable of making any Website both Responsive and Fast without destroying the Earth's atmosphere in the process. You can reach him on Facebook, Twitter, Google+, or LinkedIn.

Comments

  • ehh….you are making this a bigger deal than it really is, just develop the site with the screen in mind and not a device….we are so worried about specify devices when we really should just focus on breakpoints. When does the content break? Every site is different. I hate when we try to create a blanket solution or a stupid plugin or recommend twitter bootstrap, when all it does is create more bloat. Makes people lazy imo.

  • Kelly Johnson

    I somewhat agree with the article and with the post by ‘danny’. Too much too soon in tech. Make ‘what is’ rock-solid then worry about developing new bells and whistles. Same complaint from the ‘ages’ of web-dev. Message to/received and understood by intended audience still reigns supreme over any technique, best-practice or ‘standardization’ so get a break point and move on. Just be sure you’re actually informing or selling as intended first.

  • Tim

    This looks pretty cool, however, I think the whole responsive thing is getting way overblown, just like flat design and Flash were. Your smart phone has a built-in full fledged web browser that can zoom in and out of text areas at the touch of the screen. Is responsive really necessary? That is the biggest question to ask before you begin a web project. Text is really the only reason you’d need to have a responsive site… to make those text areas more readable. Who cares if images are made more “readable” on a phone? No one that is reading a blog article. And no one cares about viewing artist or designer portfolio sites on a phone where images will be too small to see what’s going on anyway.
    Pick your responsive sites carefully.

  • Obinwanne Hill

    Breakpoints are not always the answer because starting out you’re not naturally thinking about “where the content breaks”, that’s simply not how most websites work, especially those that are currently not Responsive. Sometimes, web designers want to design for form-factors i.e. one version for smartphones, one version for tablets, and another for traditional desktop environments: it’s a more natural design aspiration being that these are the 3 major delineations as device categories go. Right now, it’s quite difficult doing this via Media Queries, and Restive.JS is one option to deal with this.

  • Obinwanne Hill

    Thanks Kelly. I appreciate the feedback. I really would like us to get to a point where Responsive Web Design is simply just Web Design again and Web designers can add Responsive enhancements for different device categories as easily as they can write CSS; Restive.JS gives one the ability to do that. I didn’t invent Responsive Web Design, but I got a little frustrated with Media Queries and how it was significantly extending development time for even very simple Websites. Ultimately, Restive.JS is one approach and the Web designer can choose which one best suites their project

  • Obinwanne Hill

    Hi Tim. I don’t know about you but when I visit most Websites via my Smartphone, zooming in and out is the last thing I want to do; and I would imagine that wouldn’t be what the website owner wants as well for their mobile users, especially if they’re trying to guide online visitors to complete one or more specific actions. It really does make some sense to optimize a layout for different screen sizes or form-factors. The best way of accomplishing this is the challenge for most Web designers.

  • cmscss

    Interesting article – thank you. I find that basic built-in control over layout (actual built-in control like align:top; or even align:centre;) is missing – we’re talking about the basics of layout and design and it’s been missing from CSS for 15 years? Now we’re adding responsive techniques on top and layout takes longer than it should IMHO. I like the look of what you’re proposing with Restive.js – especially for larger websites so will definitely check it out. Thanks heaps. Ben.

  • Obinwanne Hill

    You’re very welcome. I agree with you that things are taking longer than they should. HTML + CSS is a partnership that just works and that every Web designer is comfortable with; it makes sense to move all Responsive CSS markup inline to speed up the overall workflow.

  • DasLicht

    Restive.js example page via http://restive.io/testing/speckyboy/htbrwsf/restive/index.html

    is not responsive here

  • ctjustice

    Nice article. Rather timely after reading an article on how to make HTML fluid (http://fluidity.sexy/)
    I’d like to ask the author, what is the recommendation for a small grid system to go with what you are promoting in the article? I like Bootstrap and others, being even when we slim it down, it is still pretty large. I also like how this article might point to a more graceful solution for very old browsers. In some cases, our customers are a segment that are running really old browsers. So we need to be careful of modern CSS frameworks. Thanks.

  • Glennyboy

    Restive.JS own web site is not responsive; not sure that fills me with much confidence in the scripts!

  • kosmar

    sass to the rescue

  • outthislife

    I can’t agree. SASS is simply better at this, you can nest your media queries within an element and be done with it.

  • Obinwanne Hill

    Restivejs.com is Responsive. Again, you need to break that ‘Resizing Browser Window’ habit; I know it’s hard.

  • Obinwanne Hill

    Ok. If SASS works for you then that’s fine. I don’t use it and for those that don’t maybe Restive.JS could make things a little easier.

  • Obinwanne Hill

    Thanks for reading, and sorry for the late response. The big idea is to enable one make Responsive enhancements inline with the rest of your CSS. Everything else you do stays the same, there is no change. Regarding grids, I used 960 Grid (http://960.gs) quite a lot a while a while back, but I find that using ‘border-box’ box-sizing and ‘float’ as usual works just as well. There’s even a nice polyfill (https://github.com/Schepp/box-sizing-polyfill) if you need to support IE below version 8. For me, the less bloat the better. JQuery is the only thing I find that I can’t do without.

  • Oliver
  • Ravinder Babbar

    HI I tried the demo code provided but its not working can any please help and let me know this plugin will not work in addons of firefox and chrome for mobile browser testing or it will only work in real mobile devices.

  • Responsive websites are NOT optional. There is a real need for them. People will always attempt to fight anything new as it causes them to come out of their comfort zone. That is a sad state for a Developer to find themselves in since we are expected to move as quickly as technology does. At various times I have utilized Bootstrap, SASS, LESS, and currently use Stylus (because it is a JS solution that makes development of responsive sites much easier and faster). I have run into the issues you discuss with media queries, and it can indeed become a time-consuming process if you are concerned with actually doing it correctly and not just good enough. Thank you for taking the time to address this issue. I look forward to digging in during my tests this week.

  • It’s really not. If I have two windows next to each other (which I often do, and many other people will too), they each become 540px wide. If the site doesn’t RESPOND to that, it is by definition not responsive.

  • Obinwanne Hill

    Thanks David. I appreciate your comments. Thanks for giving Restive.JS a shot, I hope it streamlines your workflow like it has mine. Please give me a shout if you have any challenges. Cheers.

  • Temp

    No, he’s correct — it’s not responsive at all, period.

  • Obinwanne Hill

    I reckon the primary reason that Responsive Web Design came to being was to “adapt the layout [of a web page] to the viewing environment”, a challenge that became widespread and unavoidable with the rapid proliferation of mobile devices. So, if a Website does just that [i.e. adapt], it would be classified as NOT Responsive simply because it does not adjust when you resize a browser window on a non-mobile device?! Doesn’t that sound a tad counter-intuitive?!

  • Pix-Maze

    Thanks man big article but doesn’t work

  • From all frameworks the most useful is Twitter Bootstrap with having much more flexibility and features when comparing to others and it is my first choice when I start new design and the second preference is build it from scratch using HTML5. Thank you for sharing nice article with us.