Expressive CSS follows the atomic approach to writing lightweight, scalable CSS with utility classes that are easy to write and understand.
View Starter Kit View Example View on GitHub Follow @johnpolacek
Created by John Polacek, web developer from Chicago. Follow on Twitter or Github.
Expressive is a term loosely borrowed from the concept of expressiveness in programming languages. A programming language is generally considered expressive if it allows you to naturally express your thoughts in code that is easy to understand.
Often referred to as Functional or Atomic, this type of approach to CSS been explored in many blog posts, articles and projects.
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
Browsers do not care what your classes are named. People who visit your site do not care what your classes are named.
The people who do care are those who will inherit your code. Consider how quickly an author can understand your front end codebase.
Expressive CSS takes the idea of Utility/Helper classes that are already widely used in many popular front end frameworks, and encourages you to take it further.
Utility classes are commonly and extensively used by many popular front end libararies.
.center-block {
display: block;
margin-left: auto;
margin-right: auto;
}
.hidden {
display: none !important;
visibility: hidden;
}
People like to use these classes because they are straightforward and easily understood. Why fight that? Embrace it. That is what Expressive CSS is all about.
Easy to understand + Easy to add/remove = Expressive
Go beyond applying a reset to normalize the default element styles. Elements without any class styling should have a look and feel.
Keep an eye on your base element styling with a test page.
Here are some articles about using base styles instead of a reset:
How long does it take before the different classes you make for widgets, blocks, modules, menus, modals, forms and components start to become unmaintainable? Writing CSS for all of these can lead to a stylesheet overloaded with declarations of font-size, padding, margin and more.
How many CSS declarations are in your stylesheets for...
margin
padding
width
etc.
color
font-size
font-weight
font-style
text-align
border
Avoid defining the same styles over and over again. In most cases, use a utility class to avoid multiple declarations of the same styling property, especially for common properties like padding/margin, typography, colors, alignment and container styles. This is the key to unlocking the benefits of Expressive CSS.
A trade-off. You will have more classes in HTML. However, this will result in smaller stylesheets, especially as your codebase grows. By making extensive use of utility classes, you can avoid nesting and overrides which will reduce the complexity of your CSS architecture.
When naming classes, consider those viewing your markup for the first time. With Expressive CSS, they should be able to get some sense of layout from the markup alone, without the need to even open a browser. This enables them to understand the element styles quickly and work faster.
Given the markup below, which div can you better guess what it might look like?
<div class="inner">
<div class="border pad-1">
Avoid overly abbreviated class names. Hyphens help the eye when scanning markup.
.fr // too abbreviated
.floatr // better, but..
.float-right // this is more readable..
.float-r // or abbreviate a little if you prefer
Component class names should be clear and easily understood. Avoid names that are mysterious.
.widget
.module
.ribbon
.modal
Build responsive layouts quickly by prefixing them inside of media queries across common breakpoints. Many grid systems and front end frameworks already use this technique.
.grid-4
.m-grid-6
.s-grid-12
.grid-4
.m-grid-6
.s-grid-12
.grid-4
.m-grid-6
.s-grid-12
.grid-4
.m-grid-6
.s-grid-12
.grid-4
.m-grid-6
.s-grid-12
.grid-4
.m-grid-6
.s-grid-12
Create breakpoint prefixes for any properties that you want to change based on screen size.
.s-hidden // hide when on small screen
.s-text-right // align right on small screen
.l-hidden // hide when on large screen
.l-text-large // large text when on large screen
Every time you write a style declaration, you are creating an exception to a default behavior.
More levels of cascade leads to..
More complexity leads to..
Harder to maintain CSS leads to..
Harder to scale leads to..
A giant mess
By restricting the style declarations of related properties to one area of your stylesheet, you not only reduce the size of your CSS, you create a unified visual style for your site that is easy to maintain and to change.
Let’s make the link at the bottom of that widget aligned right instead of aligned center. Instead of having to hunt for the line of css that controls alignment in devtools, then drilling into the css and editing, all you need to do is change class="text-center"
to class="text-right"
.
As you build up a system of utility classes, the number of times you need to author new styles will greatly decrease.
To get started, check out the Starter Kit.