Your Frontend Methodology is All of Them

This is the first of a blog post series about teasing sense from the morass of information churning around modern frontend development and design (Check out the second here!). As a modern development team, you need a strategy. You need guidelines and best practices and defined design patterns. You need a unified language that your team all shares. This blog series starts with an anecdote about the humble <li> element.

<li>

A few years ago, my team of five frontend developers was tasked with quickly breaking apart comps for the landing page of a straightforward site design. We had to move fast, and we had to work in parallel without stepping on each other’s toes. Each person was given a different component of the front page - the main menu, the news post listings (complete with action links), the sidebar blocks, the footer menu, the random share widgets slowly asphyxiating the last vestiges of white space and page render performance …

This was a blog-format Drupal site, which meant a lot of one design pattern: 

You can’t have a modern, information-focused design without lists, either vertical or horizontal. Take, for example, whitehouse.gov. It is a perfect example of the peanut butter and jelly of Drupal and inline-lists: 

Example: www.whitehouse.gov

Each of us had to style one or more inline lists in our assigned components. When we regrouped the next day to merge our work together, something odd happened. None of our lists played well together: we’d each styled something as simple as an inline-list completely differently. I used display: inline-block; with the IE7 zoom hack. Someone else floated everything left with a clear on the parent element. Someone else chose display: inline. Someone else used inline-block, but without the IE7 inclusion (which we had to suicidally support at the time). The fifth frontend dev panicked and just YOLO’d out a number of position: absolute’s spaced equidistant.

We had no unified approach to such a common design pattern as the lowly inline list. It was a mess and the different implementations were “leaking” into other aspects of the site build. There were no expectations of behavior: How does this technique behave on IE8? How does this technique handle overflowing content? Why is this technique a higher z-index than our overlays?! We needed to approach these patterns sanely and consistently as a team.

Enter Compass and THE ONE TRUE INLINE LIST

Sass and Compass changed everything. We weren’t using preprocessors until 2010, but when they hit, we truly started to work as a team. We finally had that thing that managers want their developers to have but don’t quite know how to, because it’s really hard: we had a PROCESS.

It goes like this: Compass is essentially a big collection of really useful Sass mixins (more on Sass later). That is, Compass makes writing a lot of tedious, common CSS structures fast and, more importantly, standardized. In our case, Compass provides the sublime little inline block list mixin.

// Applying inline-block-list to parent container
ul.nav{
  @include inline-block-list;
}

That little “@include” is applying the following behind the scenes:

@mixin inline-block-list($padding: false) {
  @include inline-block-list-container; // Wrapper behavior is handled here for us
  li {
    @include inline-block-list-item($padding); // See below for all the considerations handled for us
  }
}

Which is actually applying the more pertinent and robust:

@mixin inline-block-list-item($padding: false) {
  @include no-bullet; // Because we always forget this
  @include inline-block; // Takes into consideration things like what to include for IE
  white-space: nowrap; // We also forget about this
  // Optional padding we can pass in
  @if $padding {
    padding: {
      left: $padding;
      right: $padding;
    };
  }
}

There’s a lot going on here, but to summarize: we get an inline list that is self-clearing, floated-left, with optional padding and default, sane styles. The second best part of all this is that we wrote NONE of it. The best part is that my whole team knows exactly what to expect in this scenario. No more cowboy-code to solve the same problem five different ways.

Compass allowed us to define a few important rules within our process. One of those rules has survived 50+ site-launches, two parent companies, and three MacBooks:

[blockquote]If Compass has a mixin for a component, USE IT.[/blockquote]

Given that there are dozens of Compass mixins for every facet of CSS, our modern code is vastly more standardized. And vastly more filled with @includes!

Compass is just a tool in the toolchain

The above illustrates implementation of a framework to give us quick answers when staring at a new project for the first time while panicking about where to start. But something like Compass comes way later in the process. There are other, well-documented frameworks for each step in the design/development process. Each helps make sense of the terrifying possibilities at the start of a large project.

There exist hundreds of acronym-laden approaches to frontend development The specific frameworks you choose don’t matter so much as agreeing, understanding, and communicating about them. That is to say:

Every step in your design & development process should be accompanied by a well documented framework to solve problems and get work done.

There just happens to be many of these frameworks already available all over the internet, which we'll link together into a coherent toolchain in parts 2-3 of this blog series. I will cover why frameworks like Atomic Design, StyleTiles, OOCSS, BEM, and SMACSS rock. We'll use  a few mental models combined together that can be applied to any frontend process to gain tangible benefits almost immediately.  In the meantime, check out Dave Ruse's blog post about responsive wireframes using Foundation.

Update! Part 2 in this series is available here!