Notice: Undefined index: order_next_posts in /nas/content/live/gadgetmag/wp-content/plugins/smart-scroll-posts/smart-scroll-posts.php on line 194

Notice: Undefined index: post_link_target in /nas/content/live/gadgetmag/wp-content/plugins/smart-scroll-posts/smart-scroll-posts.php on line 195

Notice: Undefined index: posts_featured_size in /nas/content/live/gadgetmag/wp-content/plugins/smart-scroll-posts/smart-scroll-posts.php on line 196

Build a responsive menu with CSS

One size doesn’t fit all. Here’s how to ensure that your navigation both functions and looks great, whatever the screen size

As more people access the web from tablets and smartphones, there’s never been a better time to embrace responsive web design. If someone can’t work their way around your site because the navigation doesn’t work, it doesn’t matter how good the rest of your site looks.

There’s a range of responsive menu solutions to choose from. Some are code-heavy, some won’t play nicely with Internet Explorer, some don’t work with touch screens, and many don’t work as intended.

So, how about a solution that ticks as many boxes as possible? If Responsive Nav by Viljami Salminen represents the current state of the art then that’s no bad thing. It uses simple, semantic markup, loads a JavaScript file that weighs in at only 1.7Kb, doesn’t require any external library and it works in all major desktop (from IE6 up) and mobile browsers. Responsive Nav is free and with features like this should have more than fighting chance of making it into one of your production sites.


Getting started

All of the files you will need for this tutorial are included on the CD but you can also download them from Everything is well documented and the download package comes with seven demos which help show how the plug-in works in different configurations.

Meta and style

This tutorial uses the ‘advanced’ demo. The viewport meta tag is used to help ensure cross-device layout peace of mind. Two stylesheets are linked – an all-purpose style and then one specific to the particular configuration of the menu that you’ll be using.

001    <meta name=”viewport”             content=”width=device-width,initial-scale=1”>
 002 <link rel=”stylesheet” href=”../../    responsive-nav.css”>
 003    <link rel=”stylesheet” href=”styles.css”>

Define the plug-in

Then the JavaScript plug-in is defined. In the demo, the full-fat version is used but as you move toward a production-ready site, you’ll want to use the minified version that is also included in the file package. Remember that if you make any tweaks to the original, you’ll need to create your own minified version.

001    <script src=”../../responsive-nav.js”></    script>

The navigation

The familiar unordered list is used here. Line 56 of the stylesheet (styles.css) uses a percentage to manage how many navigation items may appear on one line. The demo includes four items so the stylesheet sets each li (for screen and displays over 40em) to 25%. If you want to change the number of navigation items simply divide 100 by the number of items you require.

001    @media screen and (min-width: 40em) {
 002     #nav li {
 003  width: 25%;

Change the percentage

For the next step you’ll need to adjust the IE7 and IE6 Hacks. You should also be prepared for a little reading up on the subject plus have ready access to those browsers for testing.

001        *width: 24.9%; /* IE7 Hack */
 002        _width: 19%; /* IE6 Hack */

The JavaScript

With the navigation in place it’s time to hook up the plug-in and there are a number of customisable options that can be set here. The next steps will provide a brief explanation of some of the options.

001        <script>
 002        var navigation = responsiveNav("#nav", {

Animate your menu

This refers to CSS3 transitions and should be set to true or false although you’d probably only want to turn off transitions if you found you had conflicts or performance issues.

001        animate: true, 

Change the speed

This is speed at which the small-screen version of the menu opens and closes in milliseconds. 400 feels about right but you should definitely adjust this to your own preferences – the web’s already full of too many default settings.

001 transition: 400,

Where it goes

Using “before” will mean that the toggle button stays put as the navigation expands below it. With “after” the toggle sits at the bottom, underneath the navigation. Both options have advantages and disadvantages and your own layout, together with some usability testing should reveal which suits your site best.

001    insert: “after”,

Explore more

Take a little bit of time to compare the settings used in the different demos and to become more familiar with the impact of any changes you make. At only 408 lines, responsive-nav.js isn’t a bad choice for spending time to understand and help improve your JavaScript knowledge.

More demos

If you can look beyond the absence of styling, the ‘simple’ demo really does pare back the code and is useful for showing what the essential elements are doing. Once linked, just the one line is needed in the HTML to run the navigation.

001    <script>
 002        var navigation = responsiveNav("#nav");
 003    </script>

Left navigation

The advanced-left-navigation demo provides a very attractively-styled alternative to the more common horizontal navigation. If your navigation is occupying a column to itself when viewed on a large screen, it’s particularly important that it gets out of the way nicely and neatly when the page is viewed on the screen of a much smaller device. This particular demo makes use of the customToggle option and the navigation shifts from it’s own <div> on the left into the main content <div> as the page size is reduced.

001    <script>
 002        var navigation = responsiveNav("#nav",     {customToggle: "#toggle"});
 003    </script> 

More custom toggle

The custom-toggle demo makes use of the plug-in’s open: and close: functions to change the background colour of the toggle menu button between red and green. Again, because it is minimally styled, it is easier to see what is going on.

001    <script>
 002 var navigation = responsiveNav("#nav", {
 003 customToggle: "#toggle", 
 004 open: function () {
 005 var toggle = document. getElementById("toggle");
 006 toggle.className = toggle. className.replace(/(^|s)closed(s|$)/, "opened");
 007 },
 008 close: function () {
 009 var toggle = document. getElementById("toggle");
 010 toggle.className = toggle. className.replace(/(^|s)opened(s|$)/, "closed");
 011 }
 012 });

CSS code for toggle

The related CSS for this functionality couldn’t be simpler. The JavaScript simply replaces the class name button.closed with button.opened (or vice versa) and in this particular case the background is changed between red and green. You could very easily make a more significant change using this method and even use the open: and close: functions to make changes elsewhere on the page.

001 button.closed {
 002 background: red;
 003 }
 004 button.opened {
 005 background: green;
 006 }

Open below

Also making a virtue of simplicity is the open-navigation-below demo. Just a single line added to the HTML makes for the start of a useful, compact and cross-screen-size friendly navigation solution.

001 insert: “before”

Responsive versus adaptive web design

If you’re keen to make your website look great on different devices, you’ll be familiar with the ‘responsive versus adaptive’ debate. It is as relevant to menu design as page design. If you’re ever read Jonathan Swift’s Gulliver’s Travels you might also see a parallel with the war between the Big Endian and Little Endian factions.

The responsive faction

The Big Endians in Gulliver’s Travels believe that the only way to eat a boiled egg is by breaking it at the bigger end. Some proponents of responsive web design believe that the only way of designing for different screen sizes is to ensure that your design is fully fluid and adapts itself to any screen size while paying no real attention to the actual device being used.

The adaptive faction

The Little Endians believe the correct method is via the little end of the egg. In the same way, people from the adaptive web design faction believe that the only correct way is to create designs that automatically detect the actual device being used and create a layout that is 100 per cent tailored to that device.

And the winner is?

It’s easy to see the merits of each argument and even to be carried off as a convert to one faction or the other. However, it’s important to remember that the essential job at hand is just to eat the egg, or, doing away with the analogy, to deliver the best user experience on the device in question.