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:
For more information on the principles and benefits of using this approach, check out the Expressive CSS Project Page.
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.
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.
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.