CSS Patterns and SASS (Or, how to build extensible mixins)

As a developer, do you find yourself writing the same CSS patterns over and over with only slightly different syntax?

As a designer, do you find yourself using the same design pattern over and over?

Here at Rocket Pop, one of the structures we frequently use is inline labels on forms. If we’re building forms from scratch, this is a pretty easy structure to build (hello, placeholder). However, building forms from scratch opens a huge can of worms: form processors, MySQL data storage, data export, how to accept payment, if necessary.

To help save us time and our customers money we frequently turn to Gravity Forms. Gravity Forms allows us to quickly and easily create custom forms for all of our clients needs. However, we have no ability to customize the HTML output and here’s what that output looks like for a first/last name:

That’s a lot of markup for two fields. And here is what the requirement from the designer looked like. And, we use this pattern (inline form fields) quite frequently because it ensures all visitors easily identify what information is being requested. However, because we have limited control over the markup, we can’t move elements around via HTML output and all positioning must be done with CSS.

The more forms we added, the more unwieldy our CSS became. On KVB60 alone there are 5 forms and each is styled similarly. I know what you’re thinking: surely we can target those class names and style that way. Unfortunately not. One of Gravity Forms’ biggest drawbacks is its lack of semantic classes. In other words, if I add a name field as I did above, it should include a class on the field that indicates it’s a standard, two-field name input. li.name-input and away we go.

The more forms we built, the more frustrated we got. And we realized we needed a permanent solution to make building this design pattern easier and less time-consuming. How did we decide to solve it? We’re big SASS users here and we decided that a SASS mixin was the way to go.

If you’ve worked in SASS, you know that authoring SASS mixins are not terribly different from standard SASS. In fact, they don’t have to be any different. Here’s one we make use of quite frequently:

This mixin could easily be done as an extend: @extend .clearfix, for example.

More complex things, however, require a mixin. In our case, we identified four types of fields we were consistently building: name fields, address fields, half-width fields, and full-width fields. With that in mind, let’s get started building our mixin:

First, we tell our compiler we’re creating a mixin, we name the mixin, then we declare what variables can be passed to our mixin. If you’re familiar with PHP or Javascript functionality, this will look familiar to you. In addition to identifying passable variables, we can tell SASS what the default values of those variables sould be. In this case, it’s a full-width field, with white background, 10px border-radius, 50px tall, and our site’s default text color.

Once we’re inside our mixin, we build our elements just like regular SASS/CSS, but we call upon our variables where appropriate. From this point, we begin to build specifically for the use cases we identified above. How? With if statements. Yep, SASS supports if and if/else logic. We’ll start with our default full-width field:

Our background color and border radius is applied to the outer li container.

Next, let’s take a look at the SASS for the name field whose HTML output we showed you above.

For these, the first thing we do is hide the top-level “Name” field, as we only want the input labels “first name” and “last name” to show. We then apply our rounded-corner background to the interior “span” elements and align them next to each other with margin between them. Because we know the typical width of our label, we can apply padding to our input so the user doesn’t try to type over our label (remember, it’s not a placeholder). We then clean up after ourselves for older browsers with a micro clearfix. And, here’s what it looks like when we’re done:

Screen Shot 2013-05-13 at 14.32.11

How does this help? Well, when we start building a project, we pull the mixin into our SASS folder, update the mixin defaults for that project, and include the command @import "gf_mixins" into our main file. From there, styling a field is as simple as #field_1_1 @include gf_field(name) or #field_1_4 @include gf_field(email).

Want to see (or use) the entire mixin? You can grab it (or fork it) over at GitHub.