This blog series has been developed based on a presentation given by Leah Wagner at the 2014 Pacific Northwest Drupal Summit in Portland and at the November 2014 Vancouver Drupal Users Group Meetup. View presentation slides.
Many Drupal themers find themselves looking to the frontend community for inspiration and new development tricks and techniques. How awesome is that! Drupal’s content management system gives us the ability to implement these techniques in a decoupled theme. This means we can leverage these frontend advancements in Drupal.
However, we always seem to have a few Drupal-centric hurdles to work through. My original presentation came together as I started looking further into Modular CSS. This includes a collection of development philosophies that give frontend developers the techniques needed for rock solid, scalable CSS for their websites -- sounds amazing, I know. As I thought about integrating this into my Drupal theme work, it became evident that controlling the delivered Drupal code would be essential, in order to implement the following philosophies effectively.
In this series, I will explore Modular CSS through a grouping of examples and situations we encounter with Drupal in everyday life. I will then dive into how this can be applied to Drupal. Modular CSS requires the implementation of naming conventions and customized class names on different page elements. Our biggest challenge as Drupal themers is that our HTML output is rendered for us. What we need to know is how to manipulate this output, so we can truly make it possible.
Don’t worry, you have definitely seen this before...
.views-row { border-bottom: 1px solid #CCC; padding: 20px 0; } .views-row-last { border-bottom: none; }
Here is an example we see all the time when we work with views. In this case, we have a views list and are adding a border to the bottom of each row with the views-row class. However, we do not want this border showing on the last item. So, we use the views-row-last to override this style.
How is this an example of Modular CSS?
We have a base set of styles, so we can apply additional classes to override this behaviour. However, this is far from an ideal implementation of Modular CSS. Don’t be scared, keep following along and you will start to see why!
Get ready for anagram overload…
Modular CSS is a general way to describe this development approach, but it can be interpreted in many different ways. Hence, the variety of philosophies that have emerged:
Object Oriented CSS (OOCSS) - Read more Block, Element, Modifier (BEM) - Read more. Don’t Repeat Yourself CSS (DRY CSS) - Read more. Pattern Lab and Atomic CSS - Read more. Scalable and Modular Architecture for CSS (SMACSS) - Read more.
While we live in a world of frameworks and libraries, it’s important to note that you don’t need to download anything when starting to implement one of these philosophies. By understanding the following philosophies, you will begin to make smart decisions about how to name, organize, and categorize your code. This will give you the flexibility to implement what you like and ignore what you don’t like. Moving forward, I will focus on SMACSS.
Why have I decided to focus on SMACSS? First, Iets emphasize why using any of the approaches outlined above (or developing your own) is the only correct approach.
What Modular CSS will give you:
Your CSS will have a high level of specificity, while remaining highly reusable. You (should) never have to rewrite code. Rather, share code across multiple projects. Avoid CSS conflicts and changes, that result in, breaking unrelated elements.
While adopting any philosophy is a step in the right direction, I started paying particular attention to SMACSS when the Drupal 8 team adopted this philosophy for its core development. With that said, take it from the author of SMACSS himself, Jonathan Snook. He encourages developers to use this philosophy in a way that works specifically to them. The most important thing is to remain consistent.
Organization and categorization are the most important tools you will have to master. As you style objects, think about the reusability of an item -- not just today, but in the future. Taking this into consideration, be sure to make smart decisions while naming classes or saving files. The five categories are as follows:
Components or Modules?
If you pick up the SMACSS book, you will notice the term “Modules”. In the Drupal community, many of us change this to “Components”. For Drupal themers, the term “Modules” applies to other contexts.
Base Layout Components (or Modules) State Theme
Base
The most basic elements that will exist on your site. These are usually html elements, but you can add widely used classes as well.
These styles are rarely overridden. This is a good guideline while deciding if elements belong with base styles. If this element needs to be customized in multiple areas on your site, this probably isn’t the place for it. a { color: #666; } a:hover { color: #333; text-decoration: underline; } input[type=text], input[type=password] { border: 1px solid #CCC; }
Layout
Two categories of layout styles:
How the major regions of your site are positioned. This would be the standard #header, #main, #footer and maybe #sidebar sections. How the elements are laid out within these regions. A visual reminder is provided by prefixing these classes with “l-”. #header, #footer { width: 100%; background: #333; } #main { width: 100%; background: #FFF; } #content { width: 75%; display: inline; float: left; } #sidebar { width: 25%; display: inline; float: right; } .l-grid-4 li { width: 25%; display: inline; float: left;} .l-inline { display: inline; }
The key here is to keep the layout styles separate from the object styles. Why? In an effort to make your object styles reusable, you don’t want to tie layout styles too closely together. CSS attributes that will most often apply to your layout styles are width, float, position and display.
The Ah-ha moment!
Imagine, you have a listing of 4 blocks that are horizontally aligned across the page. In Drupal, this listing is probably created by a View. Each block has a title, date, teaser text and a “read more” button. This arrangement is also needed on another page. However, one more change needs to be made. We need to have 6 blocks horizontally aligned across the page. This is where separating out the layout of an object becomes invaluable. Theme your 2 listings with a common class that styles the block elements (title, date, teaser, etc.). Then add an additional class that will adjust the layout for the 4 and 6 item options.
If you are using a grid system like Foundation, Susy, Singularity or Bourbon Neat, this may seem familiar. You are already using abstracted code to layout your elements. Nice!
State
Used to style elements that have a JavaScript dependency. A visual reminder that this element is being touched by JavaScript. This is achieved by prefixing classes with “is-”. nav { height: auto; } nav.is-collapsed { height: 0px; }
Theme
Theme styles are used when a single code base needs an alternative style. We usually see this when a website or service has multiple colour palettes. For example, a dark and light layout that can be adjusted by the user. In this case, we define base styles then supply colour overrides in alternative stylesheets. // As defined by the component .button { background: #CCC; border: #000; border-radius: 5px; } // As defined in red.css .button { background: #FF0000; }
Yes, we left Components for last. This is where you will find the biggest shift. It is the most complex portion, so we have dedicated the next post to a review of the topic.