Responsive web design often demands that we build at least two very different navigation elements for sites. One is usually targeted to desktop browsers and has a horizontal footprint, while another is often based on a vertical footprint with progressive disclosures. How ever you choose to do it, something that often bothered me was that this one element has very different stylesheets applied to it through the use of media queries.

It’s Great, In Theory

If you stay organized and use a mobile-first strategy, the possibilities for inheritance can actually make this a benefit. At the root certain styles apply to the element in all cases. As breakpoints are reached some styles are dropped, others are added. In theory, it’s great.

IRL, It Can Be A Mess

In real life, at least for me, it often gets to a point where having one element is causing me more problems than good. There is sometimes very little overlap between the navigation elements at their different breakpoints. Adding to the complication if JavaScript is being used to bind events to the elements within the nav you have to start writing media queries into your JavaScript to keep in line with your styles. That’s when I decided that I was going to have separate navs in cases where my navs diverged.

Keep the Source Tidy

It’s not semantically clean to have the menu in the source multiple times, or is it? I see a ton of sites that have a primary nav in the top and another nav element with many of the same items in the footer. Still, when I create a second nav to style separately I don’t build it in the source. I use jQuery.clone() to build a new element from the original. This keeps the source tidy and the new nav only gets created in the DOM if it’s needed.

If you find yourself wrestling with attributes that keep getting moved between media queries, consider if building two separate elements might work better for you. If so, maybe you should clone your nav and have separate styles. Just a though.