The Code

Object Oriented CSS and Sass/SCSS Integration

A big part of what made this project successful was establishing code standards right from the beginning. With multiple developers and consultants all working together it was important for everyone to be on the same page. I'm not going to go into great detail here - I've provided some resources in the sidebar if you wish to learn more. Rather, I just want to explain a little bit about the methodologies we used and how they helped us achieve our goals.

Object Oriented CSS (OOCSS)

The goal of OOCSS is to employ the DRY approach (Don't Repeat Yourself) in code reuse, which ultimately leads to more efficient stylesheets and a more streamlined process overall. This is not a new concept by any means, but its importance cannot be stressed enough in a project with so many cooks in the kitchen - each with a different background, portfolio, and style of coding. From a design/development standpoint, this is about as simple as it gets. It established a baseline from which I could begin prototyping.

By identfying the underlying structure of our elements, we can then separate that structure from how it may look/feel in different environments, or themes. In doing so, we effectively give branding its own namespace; a skin that is free to be shaped and colored without infringing upon the more fundamental, structural code. The following is an example of a news story viewed as a card.

Business School Brand Communication

Chris Casey | Jul 22, 2016, 10:19am University News

Ad orci laoreet netus sapien quibusdam pharetra justo, eius necessitatibus eros perspiciatis penatibus delectus, modi, repellendus odit incididunt quia facilis sodales, harum erat possimus. Hac adipiscing nisi at molestias dictumst tortor, exercitation officiis ullam officiis adipisci! Sunt aut provident, fames.

The news story can be broken down into its basic elements. Lets look at the HTML.

<article class="card shadow downtownBorder">
    <h3 class="title"></h3>
    <img class="graphic noBorder"/>
    <span class="byLine"></span>
    <span class="category"></span>
    <p class="summary"></p>
    <i class="fa fa-angle-double-right"></i>
</article>

Everything we need to create this particular card is shown in the HTML above. You'll notice there is a class associated with every element. We've done so because we need to be as specific as possible with our selectors.

Lets focus on the classes on the article element: card, shadow, and downtownBorder.

.card {
  border-style: solid;
  border-width: 5px 1px 1px;
  padding:10px;
}

The border styles and padding for the 'card' class is the same for all cards, regardless of the content displayed within. In this case, we're showing a news story. For this particular content type we want to add an inset gray box-shadow. Since we don't want it on all cards, but we do want it on this kind of card, we apply the styles to the 'shadow' class, and append that to the element.

The same specificity applies to the gold border-top. That color is specific only to the downtown theme, and so that styling is applied to the 'downtownBorder' class.

.shadow {
  box-shadow: 0 0 0 3px #f5f5f5 inset, 0 0 0 4px #ddd inset;
}

.downtownBorder {
  border-color: #cfb87c #ddd #ddd;
}  

The following two examples are still card views, but one is a Testimonial content-type and the other is a Directory content-type. You can see how some of the core 'card' stylings would still apply, but any changes we need to make will be administered on their respective classes.

Wayfarers next level beard, Schlitz disrupt small batch.- Some Student, '17

.testimonial {
  padding:30px;
}

.testimonialGraphic {
  border-color: #ddd;
}

.medicalBorder {
  border-color: #222 #ddd #ddd;
}  

Snackwave Pickled, CISM

Associate Professor

Department of Chemical Engineering

.dualBorder {
  border-color: #ddd;
}  

All of this is pretty basic when handled in the CSS. Individual designers/developers may have a slightly different approach to OOCSS, but the concept remains the same. It is the concept itself that was most helpful in this project. By architecting each component and content type ahead of time, planning the usage accordingly, and breaking things down to their most basic elements, we avoided any confusion between developers. We also avoided creating any extra work for ourselves, which of course helped us make deadline.

Sass/SCSS Integration

As things passed from prototyping to initial integration, we enhanced the stucture of our code base. OOCSS aligns the efforts of multiple developers in the design/prototyping stage, but to efficiently deploy them across an enterprise-level system, we wanted a preprocessor. Sass to the rescue!

All of the style sheet coding we deliver through the University CMS is from within .scss files. We gave each component its own .scss file for easier code identification and maintenance. Although Sass offers many powerful features not currently available in plain old CSS, (namespace nesting, mixins, etc.) we found the greatest value in using one main feature: Variables.

Variables

Once a variable is defined, we can easily manage future changes anywhere that variable is deployed. Lets use our previous Card widget as an example. You'll notice the image border on the testimonial graphic is the same color as the border on the card itself (#ddd). That's a repeated color that's used on many different components/elements. If we wanted to darken that in the future, (to say, #aaa) we'd have to hunt down the border-color property on all the elements on which it is applied. But if we define it as a variable, we'd only have to change it in one place. In other words:

.testimonialGraphic {
  border-color: #ddd;
}

.dualBorder {
  border-color: #ddd;
} 

ad infinitum...

$borderPrimary: #ddd;

.testimonialGraphic {
  border-color: $borderPrimary;
}

.dualBorder {
  border-color: $borderPrimary;
}

All we have to do is change the value for the $borderPrimary variable and it will populate wherever it is used throughout our code base.

From here we can expand our variables to a full range of Unified Design specific colors. This acts as somewhat of a style guide in many ways, easy to deploy and maintain.

The color property isn't the only way to get the most out of variables. You can use any other property like font sets or padding/margins... basically anything you'll be repeating throughout your code. If you find yourself repeating groups of styles as we did, you may want to start using another one of Sass's helpful features.

Mixins

An example from the Unified Design project in which we found mixins valuable is with our components. We have many different components, things like tables, call-to-action buttons, highlight boxes, cards, tabs, etc. Although these are all quite different in their own right, most do share a common set of styles. We use mixins to repeat that code throughout our design.

@mixin component-style {
  border-style:solid;
  border-width:1px;
  font-family: $primaryFont;
  margin:15px 0;
  padding:15px;
  }

.card {
  @include component-style;
  }

.card.downtown {
  border-color: $borderOne;
  }

You'll notice in the defined mixin that we've used a variable for the font-family property. The reusable code starts to trickle down to many selectors in this way. In the Unified Design project, we didn't go too deep using mixins. We were worried about having to make specific changes to individual componets, and if that code was embedded in a globally deployed mixin, we'd have less control over future changes. Going forward, we plan to review our code and re-architect the Sass structure to be more efficient.