Gumby’s Toggles & Switches

Written by in Technology on

So for those of you that don’t know, the team here at Digital Surgeons created a responsive CSS grid framework last year called Gumby Framework. Needless to say, this completely changed the game and the internet was never the same. After a whole year of helping web properties be easily translated across devices, we decided to head back to the drawing board. In early 2013 we once again reinvented the wheel with the release of Gumby2. It is a wonderful platform that I myself have spent many hours hard at work on. My name is Adam Chambers by the way, and I’m a senior engineer at Digital Surgeons. This is my explanation of my favorite, and often underutilized Gumby feature: Toggles and Switches.

Switching it up…

  Toggles and switches were born out of a frustration of the Digital Surgeons dev team. They have been through several iterations, as we strove to find a better solution to the problem, before finally manifesting themselves in Gumby 2 as the mighty Toggles and Switches. When CSS3 came along and we were given the ability to create animations and other aesthetic UX gems with pure CSS, we dove at the chance. “No JavaScript?” we exclaimed, amazing. However, this was not actually the case.

Ain’t no JS got time for that…

  We found that although CSS was now capable of handling the majority of our front-end UX, triggering effects and changes were a different story. Psuedo states like :hover and :active could be used but if we wanted to trigger style changes based on other events we had to resort back to trusty JS. This meant we had a lot of code written purely to add and remove classes from elements based on user interactions. We are JS enthusiasts at Digital Surgeons. Once you understand the true power of the language, you begin to hate using it in such rudimentary ways. We went through many iterations of design patterns before taking a step back and re-evaluating the problem.

Keeping it active

  The concept behind toggles and switches is simple yet the potential is massive. The basic premise is that a class of .active should be added or removed from an element based on data-* attributes specifying the target selector and binding events. Lets help explain that with a little code. Take the anchor below for example. We are specifying a target selector in data-trigger and the event to bind the whole process to in data-on. In this case, when the anchor is clicked, .active will be added to #my-element.

<a href="#" class="switch" data-trigger="#my-element" data-on="click">Click Me!</a>

  Notice the .switch class. This anchor is a switch which means the .active class will be added only once. If we change that to .toggle, the .active class would be added first and then removed on the next trigger, this process would continue indefinitely.

Turn it off and on again

  This wasn’t quite enough for us. We had realized the potential of what we were building and decided that with a small addition, huge advantages could be gained. Adding the ability to specify a selector to remove the .active class would unleash a new realm of possibilities. Take a look at this Toggle.

<a class="toggle" href="#" data-trigger="#my-element|#your-element" data-on="mouseon">Click Me!</a>

Two selectors can be specified in the data-trigger attribute using a pipe separator. When the user hovers on this anchor, the .active class will be added to #my-element and removed from #your-element. This process would then be reversed on the next trigger and so on. If we were using a Switch the process would occur only once.

I have the power

  This simple concept has the potential for complex functionality. We have built many UI elements using Toggles and Switches and without writing any extra JS.

  Gumby 2 now comes with drawers and modals as examples of what you can build using toggles and switches. Check out the Sass for drawers and modals. The .drawer and .modal classes are both hidden by default and utilize the .active class in order to display them, for example .modal.active displays the modal. You can then use any combination of toggles and switches to add and remove the .active class, this provides major flexibility. We have also added variables to settings.scss for you to tweak the provided modal and drawer styles.

<!-- Open and close drawer -->
<a class="toggle" href="#" gumby-trigger="#mydrawer">Open/Close Drawer</a>
<!-- Open modal window -->
<a class="switch" href="#" gumby-trigger="#mymodal">Open Modal</a>
<!-- Open one drawer and close another -->
<a class="toggle" href="#" gumby-trigger="#mydrawer|#myotherdrawer">Next Step</a>

There have been far more advanced creations, check out the Toggle and Switch usage on the new Borderfree site.

The selectors specified in data-trigger are passed directly to JS so any valid CSS selector can be used no matter how advanced. Also, multiple events can be specified, separated by a space, in data-on. The toggle or switch will trigger on each of the specified events. It’s also worth noting that the default event is click so no need to specify data-on=“click”. Here’s a few more advanced examples.

<a class="switch" href="#" data-trigger="#list > li.children:first-child | #element .child">Click Me!</a>

<a class="switch" href="#" data-trigger="#list > li[data-attr]" data-on="mouseon mouseout">Click Me!</a>

<a class="switch" href="#" data-trigger="#form input | #form > a:last-child" data-on="focus blur">Click Me!</a>

Once you realize the potential of these tools you can build pretty much any UI feature. We’ve seen drawers, accordions, feature sliders any much more. Check out the Gumby responsive grid showcase for more creative uses of Toggles and Switches and get involved with Gumby on GitHub.

Discuss on Twitter