- January 28, 2016
Expressive type for CSS
- @alliwagner
- Developer
Guys I figured it out! I figured out how to code type on the web.
I kid.
However I have been really digging my approach to type in the template-build phase as of late. It’s super simple, saves you tons of time, makes your files smaller, and communication both with your teammates and the client more focused. I’m not selling CSS snake oil here, I’m just that into it.
Basically for typography specifically, I’m emploring you to leverage what has come to be known as Expressive CSS. That means all type styles are captured within very expressive classes “.sans-italic-small”, “.sans-italic-medium” “.serif-bold-uppercase-small” which should be applied directly to the semantic element which they adorn.* Keep all other type related CSS, the kind you put in the font: shorthand property, out of the rest of your CSS entirely, captured in type styles declared once. Expressive CSS, an approach I’ve been thinking about for a while but most recently discovered was captured and coined by John Polacek, is an approach to “writing lightweight, scalable CSS using utility classes that are easy to write and understand.” Principles include “classes are for visual styling and HTML elements are for semantics.”
I’m imploring you to, at the minimum, try to declare type once and only once in your CSS.
It saves you time.
When I’m setting the project up, the first thing I do is create an HTML key for type with CSS styles applied to it, an example of which can be viewed here. While I’m writing the markup for said project, before I have to think of the very best class to name the element in order to apply styles, something I’ve probably spent way too much time on in the past, I just add the appropriate, expressive style according to whatever design artifacts have been created. Additionally, I’m writing and compiling a lot less CSS if you stick with your type key.
It makes communication more efficient.
Across disciplines, viewing live type in the browser from the design system isolated in a key doc, named so literally, facilitates focused communication around the type system. Additionally, that high-level view, outside of Photoshop, is useful to designers, developers, and clients alike. Updating in a visual QA phase is easier. You’re not adjusting type styles in the CSS, you’re swapping classes in markup. This key also turns into a style guide artifact that can be handed off the client for reference.
Back-end devs will find it easier to integrate.
As a front-end dev handing templates off to a back-end dev, any type changes they need to make is much easier for him or her with expressive CSS approach. She won’t necessarily have to unpack and then reroll the CSS to make a simple style change to an element. She simply needs to change the HTML, the CSS supports this. It also ensures she stay within the type system while building out additional components/generally extending the system.
In conclusion, a succinct design system should have a limit to the number of styles which it supports. Isolate them in very expressive, easy to understand classes, and keep inheritance low making them powerful, write them only once in your CSS.
*Note: John Polacek advises classing type “.serif .small”, as opposed to my “.serif-small.” He forked my codepen which can be viewed here: http://codepen.io/johnpolacek/pen/rxKaPJ