Get your project up and running quickly on a foundation of Expressive CSS.
Created by John Polacek, web developer from Chicago. Follow on Twitter or Github.
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.
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.
Often referred to as Functional or Atomic, this type of approach to CSS been explored in many blog posts, articles and projects. For more information, check out The Expressive CSS Project Page.
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