John Polacek

Content & Display Patterns with Expressive CSS

Example events page layout from the Content Display Patterns article
Events Page layout design
from Content & Display Patterns by Daniel Mall

Dan Mall’s Content & Display Patterns article talks about the importance of decoupling content and design.

Content patterns are established first, independently from the design. Next, designers create display patterns with various pieces of content. Last, it is up to the developers to “create the hooks for content patterns to flow into the display patterns appropriately”.

CSS is entirely concerned with display, yet in the pursuit of being “semantic” we often permeate our stylesheets with content references.

<div class="event">
    <h1 class="event__title">Star Wars: The Force Awakens Premiere</h1>
    <p class="event__date">Dec 20, 2015</p>
    <p class="event__location">Ritz East, Philadelphia PA</p>
</div>

Developers understand the importance of modular design systems. Instead of creating CSS around content patterns, we could instead craft our CSS based upon display patterns.

Expressive CSS is an approach to writing lightweight, scalable CSS using utility classes that are easy to write and understand.

<div class="abs pos-bottom pos-left text-white pad-2">
    <h2 class="text-reg pad-2-top">My Great Event</h2>
    <span class="bold">February 17-20</span>

Many front end developers have a strong negative reaction when they see markup like the above.

For individuals weaned on an ideology where “semantic HTML” means using content-derived class names (and even then, only as a last resort), it usually requires you to work on a large application before you can become acutely aware of the impractical nature of that approach. You have to be prepared to disgard old ideas, look at alternatives, and even revisit ways that you may have previously dismissed.

From About HTML Semantics and Front-End Architecture by Necolas Gallagher

In the examples below, I demonstrate how one can use the Expressive CSS approach to build a layout like the one featured in Dan’s article.

The benefits of building the layout in this way were:

  • Maintained separation of content and display by keeping content references out of the CSS.
  • Able to quickly build the layout without hardly needing to actually write any new lines of CSS.
  • Simple to create a responsive version even though no phone or tablet layout were provided because responsive utility classes make it easy to experiment.

For more information on the principles and benefits of using this approach, check out the Expressive CSS Project Page.

Basic Demo

To build this example, I wrote markup then simply added CSS utility classes that are part of the default Expressive CSS Styleguide. I was nearly able to achieve the layout without writing any new CSS.

There were only two instances when it was necessary to add new styles. I added a .box-gradient-overlay so the white text on the main image would be readable, and a thick border left class for the colored line on the category kicker.

Portability is one of the main benefits of the Expressive CSS approach. Scalability is another. As a website, project or application grows, it is important to keep stylesheets small and maintainable.

View on Codepen

View on Github

Responsive Demo

The article only had an example for the desktop layout, but with Simple Grid and our responsive utility classes, it was quick and easy to adjust the layout for different screen sizes. (Adjust your browser window width to see the responsive layout adjustments)

// Before
<div class="grid-6 border-right marg-2-bottom">

// After
<div class="grid-12 l-grid-6 l-border-right m-border-bottom s-border-bottom marg-2-bottom">

When flowing in real content across different screen sizes, various layout issues will likely arise. In this case, the heights of the bottom four events vary quite a bit depending on the content. I added a .grid-flex class to the container to make sure the heights were equalized.

View on Codepen

View on Github

Template Demo

In the real world, it is likely that you are using templates to render content that comes from a database. In this example, I used the Twig Template Engine. I’ve created some sample data in a JSON file to represent what one might expect to come from the backend to give the templates something to render.

<div class="marg-1-top marg-2-bottom">
  <span class="pad-1-sides pad-half-vert bgr-grey-lt border-left-6-blue">
    <span class="text-small-2 letter-space-1 uppercase">{{ events[i].category }}</span>
  </span>
</div>
<h5 class="text-reg">{{ events[i].title }}</h5>
<p class="bold text-small pad-1-bottom">{{ events[i].dates }}, {{ events[i].location }}</p>
<p class="text-small pad-0">{{ events[i].description }}</p>

Breaking down our display patterns into template partials (components) gives us the opportunity to keep our codebase even more DRY and maintainable. We can change our components at will, without needing to touch any CSS or the underlying content itself.

View the Template Demo

View the Events Template Code

Related Links