Navigation is one of the most challenging battles for doing responsive design well. To preface this article, I highly recommend you study Brad Frost's collections of responsive navigation patterns and complex responsive navigation patterns. In this post, I'll cover two methods for handling the “toggle” method for responsive navigation in WordPress.
Common responsive navigation patterns in WordPress
There are many possible approaches to responsive navigation. But other than the “do nothing” approach, the “toggle” method for handling responsive navigation is by far the most popular I've seen in WordPress themes.
The toggle method is typically represented by a button with text or a “hamburger” icon replacing an inline navigation method once the screen size shrinks to a particular size. The trigger for the toggle method is where I'd like to focus.
Toggle Method 1 — jQuery resize and window width
I've used a method very similar to this ever since I studied it in the _s theme over a year ago. Essentially, the trigger is handled by identifying the window width at any time with
$( window ).width(). I'll have a full view of a slightly updated version of this code below, but you can see this method in this gist as well.
When the window width is above 600px, the
main-navigation class is utilized, and when the window is below 600px,
main-small-navigation is utilized for the menu itself. Also, the
h1 used for assistive text (for accessibility purposes) is altered to be the menu toggle and associated text, triggered by jQuery's
Therefore, the menu is able to be turned into a click-activated toggled navigation method for small views.
This is a pretty good solution, and has been used quite a bit. One pet peeve of mine for this solution is the hard coded pixel value for where the menu breaks. It's fine for if you build parent themes from starters such as _s, but distributed parent themes that anticipate child theme usage and customization should do better. We could make the hard-coded valuable filterable by PHP using
Integrate wp_localize_script for flexibility
wp_localize_script, making the hardcoded valuable filterable with PHP.
[gist id=”6386511″ file=”small-menu.js”]
You can see the
small_menu_vars.size variable in place of the previously hardcoded number value. This variable is able to utilize dynamic data thanks to WordPress' wonderful
wp_localize_script function, so well taught by Pippin Williamson last year. I think this particular use case can be quite useful, especially with distributed parent themes.
In order for us to be able to utilize this variable, we need to properly set up our variable with
wp_localize_script. Here's the corresponding code that will look familiar after reading Pippin's tutorial.
[gist id=”6386511″ file=”sample-functions-enqueue.php”]
Did you notice the filter? That's where the fun is. We can now make this number, previously hard coded, filterable from child themes. Here's a sample filter.
[gist id=”6386511″ file=”sample-functions-child-theme.php”]
Now your child themes can easily change the break point for the responsive navigation without dequeueing the file and enqueueing a new one.
The previous script does rely on jQuery, and if your project doesn't need jQuery otherwise (granted, this is unlikely these days) you may look for an alternative solution. Or you just might like the idea of handling the breakpoint in a little cleaner way with a CSS media query.
First, take a look at the navigation markup.
[gist id=”6386589″ file=”s-theme-header-markup.php”]
One thing you'll notice is that the menu-toggle class is on the
h1 using the toggled class. The
h1 (toggle menu) is hidden by default with
display: none; and altered with a media query for
max-width: 600px to
display: block;. At the same time, our standard menu is hidden by default and only shown when the toggled class is activated.
[gist id=”6386589″ file=”nav-styles.css”]
The button variable is being defined by grabbing the
#site-navigation (which is the container variable).
[gist id=”6386589″ file=”navigation.js”]
Notice there was no hardcoded value for the width to set a navigation breakpoint for toggling. It's all in the CSS. Because the decision making is all in the CSS, it makes the transition from toggled to not toggled faster as well.
Flexibility for distributed themes
Since the value for the breakpoints are in CSS with this method, it's a bit more flexible than our previous method. However, it could be a bit weird to override the media query in a child theme to adjust where the break occurs.
Which method is better?
I think in almost all situations, the second method without jQuery and handled via CSS is better. It's fast, flexible, and has great support.
However, some distributed themes may be structured in a way that overriding the CSS media query could be difficult and would prefer the flexibility of the jQuery solution and
Some other themes may already use something similar to the first method, and want the flexibility, but need to keep backward compatibility in mind. In that case, it's trivial to add the support for flexible breakpoints with
If your website doesn't have a distributed parent theme that already utilizes another method, the new _s method is probably a no-brainer.