{"id":331887,"date":"2021-01-19T07:47:38","date_gmt":"2021-01-19T15:47:38","guid":{"rendered":"https:\/\/css-tricks.com\/?p=331887"},"modified":"2021-01-19T07:47:46","modified_gmt":"2021-01-19T15:47:46","slug":"on-type-patterns-and-style-guides","status":"publish","type":"post","link":"https:\/\/css-tricks.com\/on-type-patterns-and-style-guides\/","title":{"rendered":"On Type Patterns and Style Guides"},"content":{"rendered":"\n

Over the last six years or so, I\u2019ve been using these things I\u2019ve been calling \u201ctype patterns\u201d<\/strong> in my web design work, and they\u2019ve worked out pretty well for me. I\u2019ll dig into what they are and how they can make their way into CSS, and maybe the idea will click with you too and help with your day-to-day typography needs.<\/p>\n\n\n\n\n\n\n\n

If you\u2019ve used print design desktop software like QuarkXPress<\/a>, Adobe InDesign<\/a>, or CorelDraw<\/a>, then imagine this idea is an HTML\/CSS translation of \u201cparagraph styles.\u201d<\/p>\n\n\n\n

When designing a book (that spans hundreds of pages), you might want to change something about the heading typography across the whole book<\/em> (on the fly).<\/em> You would define how a certain piece of typography behaves in one central place<\/em> to be applied across the entire project (a book, in our example). You need control<\/em> of the patterns.<\/em><\/p>\n\n\n\n

Most programs use this naming style, but their user interfaces vary a little.<\/p>\n\n\n\n

\"\"<\/figure>
\"\"<\/figure><\/div>
\"\"<\/figure><\/div><\/div><\/div><\/div>\n\n\n\n

When you pull up the pane, there\u2019s usually a \u201cbase\u201d paragraph style that all default text belongs to. From there, you can create as many as you want. Paragraph styles are for \u201cblock\u201d level-like elements, and character styles are for \u201cinline\u201d level-like elements, such as bold or unique spans.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n

The user interface specifics shouldn\u2019t matter \u2014 but you can see that there are a lot<\/em> of controls to define how this text behaves visually. Under the hood, it\u2019s just key: value<\/strong> pairs, which is just like CSS property: value<\/strong> pairs<\/p>\n\n\n\n

h1 {\n  font-family: \"Helvetica Neue\", sans-serif; \n  font-size: 20px;\n  font-weight: bold;\n  color: fuchsia;\n}<\/code><\/pre>\n\n\n\n
Once defined, the styles can be applied to any piece of text. The little +<\/code> (next to the paragraph style name below) in this case, means that the style definition has changed<\/em>.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
If you want to apply those changes to everything with that paragraph style, then you can \u201credefine\u201d the style and it will apply project-wide.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
When I say it like that, it might make you think: that\u2019s what a CSS class is.<\/strong><\/p>\n\n\n\n
But things are a little more complicated<\/em> for a website. You never know what size your website will be displayed at (it could be small, like on a mobile device, or giant, like on a desktop monitor, or even on monochrome tablet, who knows), so we need to be contextual with those classes and have then change based on their context<\/em>.<\/p>\n\n\n\n
\"\"
Styles change as the context changes.<\/figcaption><\/figure>\n\n\n
The bare minimum of typographic control<\/h3>\n\n\n
In your very earliest days as a developer, you may have been introduced to semantic HTML, like this:<\/p>\n\n\n\n
<h1>Here's some HTML stuff. I'm a heading level 1<\/h1>\n<p>And some more. I'm a paragraph.<\/p>\n\n<h2>This is a heading level 2<\/h2>\n<p>And some more pragraph stuff.<\/p><\/code><\/pre>\n\n\n\n
And that pairs with CSS that targets those elements and applies styles, like this:<\/p>\n\n\n\n
h1 {\n  font-size: 50px; \/* key: value pairs *\/\n  color: #ff0066;\n}\n\nh2 {\n  font-size: 32px;\n  color: rgba(0,0,0,.8);\n}\n\np {\n  font-size: 16px;\n  color: deepskyblue;\n  line-height: 1.5;\n}<\/code><\/pre>\n\n\n\n
This works!<\/p>\n\n\n\n
You can write rules that target the headers and style them in descending order, so they are biggest > big > medium<\/strong>, and so on.<\/p>\n\n\n\n
Headers also already have some styles that we accept as normal<\/em>, thanks to User Agent styles<\/a> (i.e. default styles applied to HTML by the browser itself). They are meant to be helpful<\/em>. They add things like font-weight<\/code> and margin<\/code> to the headers, as well as collapsing margins<\/a>. That way \u2014 without any CSS at all \u2014 we can rest assured we get at least some basic styling in place to establish a hierarchy. This is beginner-friendly, fallback-friendly\u2026 and a good thing!<\/p>\n\n\n
As you build more complex sites, things get more complicated<\/h3>\n\n\n
You add more pages. More modules. More components. Things start to get more<\/em> complex. You might start out by adding unique classes and styles for every single little thing, but it\u2019ll catch up to you.<\/p>\n\n\n\n
First, you start having classes for special situations:<\/p>\n\n\n\n
<h1 class=\"page-title\">\n  Be <span class='super-ultra-magic-rainbow'>excellent<\/span> to each other\n<\/h1>\n\n<p class=\"special-mantra\">Party on, <em>dudes<\/em>.<\/p>\n\n<p>And yeah. I'm just a regular paragraph.<\/p><\/code><\/pre>\n\n\n\n
Then, you start having classes everywhere (most CSS methodologies even encourage this):<\/p>\n\n\n\n
<header class=\"site-header\">\n  <h1 class=\"page-title\">\n    Be <span class='ultra-magic-rainbow'>excellent<\/span> to each other\n  <\/h1>\n<\/header>\n\n<main class=\"page-content\">\n  <section class=\"welcome\">\n    <h2 class=\"special-mantra\">Party on <em>dudes<\/em><\/h2>\n\n    <p class=\"regular-paragraph\">And yeah. I'm just regular<\/p>\n  <\/section>\n<\/main><\/code><\/pre>\n\n\n\n
Newcomers will try and work around the default font sizes and collapsing margins if they don\u2019t feel confident \u201c<\/a>resetting<\/a>\u201d<\/a> them<\/a>.<\/p>\n\n\n\n
This is where people start trying out margin-top: -20px<\/code>\u2026 and then stuff gets whacky<\/em>. As you keep writing more rules to wrangle things in, it will feel like you are \u201cfixing\u201d things instead of declaring<\/em> how you actually want them to work. It can quickly feel like you are \u201cfighting\u201d the CSS cascade when you\u2019re unaware of the browser\u2019s User Agent styles.<\/p>\n\n\n
A real-world example<\/h3>\n\n\n
Imagine you\u2019re at your real job and your boss (or the visual designer) gives you this \u201cpixel perfect\u201d Adobe Photoshop document. There are a bunch of colors, layout, and typography.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
You open up Photoshop and start to poke around, but there are so many pages and so many different type styles that you\u2019ll need to take inventory and gather what styles can be combined or used in combination.<\/p>\n\n\n\n
\"\"
Would you believe that there are 12 different sizes<\/em> of type on this page? There’s possibly even more if you also take the line-height<\/em> into consideration.<\/figcaption><\/figure>\n\n\n\n
It feels great to finish a visual layout and hand it off. However, I can\u2019t tell you how many full days I\u2019ve spent trying to figure out what the heck is happening in a Photoshop document. For example, sometimes small-screens aren\u2019t taken into consideration at all; and when they are, the patterns you find aren\u2019t always shared by each group as they change for different screen types. Some fonts start at 16px and go up to 18px, while others go up to 19px and become italic. How can spot context changes in a static mockup?<\/p>\n\n\n\n
Sometimes this is with fervent purpose; other times the visual designer is just going on feel and is happy to round things up and down to create reusable patterns. You\u2019ll have to talk to them about it. But this article is advocating that we talk about it much<\/em> earlier in the process<\/em>.<\/p>\n\n\n\n
You might get a style guide to reference. But even that might not be specific enough to identify contexts.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Let\u2019s zoom in on one of those guidelines:<\/p>\n\n\n\n
\"\"
We get more content direction than we do behavior of the content in different contexts.<\/figcaption><\/figure>\n\n\n\n
You may even get a formal, but generic, style guide with no pixel sizes or notes on varying screen sizes at all!<\/p>\n\n\n\n
\"\"<\/figure><\/div>
\"\"<\/figure><\/div><\/div><\/div><\/div>\n\n\n\n
Don\u2019t get me wrong: this sort of thing is defintely a nice thought, and it might even be useful for others, like in some client meeting or something. But, as far as front-end development goes, it\u2019s more confusing than helpful. I\u2019ve received very thorough style guides that looked nice and gave lots of excellent guidelines for things like font sizes, but are completely mismatched with the accompanying Photoshop document. On the other end of the spectrum, there are style guides that have unholy amounts of specifics for every type of heading and combination you could ever imagine \u2014 and more<\/em>.<\/p>\n\n\n\n
It\u2019s hard to parse this stuff, even with the best of intentions!<\/p>\n\n\n\n
Early in your development career, you\u2019d probably assume it\u2019s your job to \u201cfigure it out\u201d and get to work, writing down all the pixels and trying your best to make sense of it. Go get<\/em> ‘em!<\/em><\/p>\n\n\n\n
But, as you start coding all the specifics, things can get a little overwhelming with the amount of duplication going on. Just look at all the repeated properties going on here:<\/p>\n\n\n\n
.blog article p {\n  font-family: 'Georgia', serif;\n  font-size: 17px;\n  line-height: 1.4;\n  letter-spacing: 0.02em;\n  margin-bottom: 10px;\n}\n\n.welcome .main-message {\n  font-family: 'Georgia', serif;\n  font-size: 17px;\n  line-height: 1.4;\n  letter-spacing: 0.02em;\n  margin-bottom: 20px;\n}\n\n@media (min-width; 700px) {\n  .welcome .main-message {\n    font-size: 18px;\n  }\n}\n\n.welcome .other-thing {\n  font-family: 'Georgia', serif;\n  font-size: 17px;\n  line-height: 1.4;\n  letter-spacing: 0.02em;\n  margin-bottom: 20px;\n}\n\n.site-footer .link list a {\n  font-family: 'Georgia', serif;\n  font-size: 17px;\n  line-height: 1.4;\n  letter-spacing: 0.02em;\n  margin-bottom: 20px;\n}<\/code><\/pre>\n\n\n\n
You might take the common declarations and apply them to the body instead. In smaller projects, that might even be a good way to go. There are ways to use the cascade to your advantage, and others that seem to tie too many things together. Just like in an Object Oriented programming language, you don\u2019t necessarily want everything inheriting everything<\/em>.<\/p>\n\n\n\n
body {\n  font-family: 'Georgia', serif;\n  font-size: 17px;\n  line-height: 1.4;\n  letter-spacing: 0.02em;\n}<\/code><\/pre>\n\n\n\n
Things will work out OK. Most of the web was built like this. We\u2019re just looking for something even better<\/em>.<\/p>\n\n\n
Dealing with design revisions<\/h3>\n\n\n
One day, there will be a meeting. In that meeting, you\u2019ll find out that the client and the visual designer decided to change a bunch of the typography. Now you need to go back and change it in 293 places in the CSS file. If you get paid by the hour, that might be great!<\/p>\n\n\n\n
As you begin to adjust the rules, things will start to conflict. That rule that worked for two things now only works for the one. Or you\u2019ll notice patterns that could now be used in many more places than before. You may even be tempted to just totally delete the CSS and start over! Yikes!<\/p>\n\n\n\n
I won\u2019t write it out here<\/em>, but you\u2019ll try a bunch<\/em> of different things over time, and people usually come to the conclusion that you can create a class \u2014 and add it to the element instead of duplicating rules\/declarations for every element. You\u2019ll go even further to try and pull patterns out of the visual designer\u2019s documents. (You might even round a few 19px down to 18px without telling them\u2026)<\/p>\n\n\n\n
.standard-text { \/* or something *\/\n  font-family: serif;\n  font-size: 16px; \/* px: up for debate *\/\n  line-height: 1.4; \/* no unit: so it's relative to the font-size *\/\n  letter-spacing: 0.02em; \/* em: so it's relative to the font-size *\/\n}\n\n.heading-1 {\n  font-family: sans-Serif;\n  font-size: 30px;\n  line-height: 1.5;\n  letter-spacing: 0.03em;\n}\n\n.medium-heading {\n  font-family: sans-Serif;\n  font-size: 24px;\n  line-height: 1.3;\n  letter-spacing: 0.04em;\n}<\/code><\/pre>\n\n\n\n
Then you\u2019d apply the class to anything that needs it.<\/p>\n\n\n\n
<header class=\"site-header\">\n  <h1 class=\"page-title heading-1\">\n    Be <mark>excellent<\/mark> to each other\n  <\/h1>\n<\/header>\n\n<main class=\"page-content\">\n  <section class=\"welcome\">\n    <h2 class=\"medium-heading\">Party on <em>dudes<\/em><\/h2>\n\n    <p class=\"standard-text\">And yeah. I'm just regular<\/p>\n  <\/section>\n<\/main><\/code><\/pre>\n\n\n\n
This way of doing things can be really helpful for teams that have people of all skill levels changing the HTML. You can plug and play<\/em> with these CSS classes to get the style you want, even if you\u2019re the new intern.<\/p>\n\n\n\n
It\u2019s really helpful to separate the idea of \u201clayout\u201d elements (structure\/parents) and the idea of \u201cmodules\u201d or \u201ccomponents.\u201d In this way, we\u2019re treating the pieces of text as lower level components<\/em>.<\/p>\n\n\n\n
The key is to keep the typography separate from the layout. You don\u2019t want all<\/em> .medium-heading<\/code> elements to have the same margins or colors. It\u2019s going to depend on where they are. This way you are styling based on context. You aren\u2019t \u2018using\u2019 the cascade necessarily, but you also aren\u2019t fighting<\/em> it because you keep the techniques separate.<\/p>\n\n\n\n
.site-header {\n  padding: 20px 0;\n}\n\n.welcome .medium-heading { \/* the context \u2014 not the type-pattern *\/\n  margin-bottom: 10px;\n}<\/code><\/pre>\n\n\n\n
This is keeping things reasonable and tidy. This technique is used all over the web.<\/p>\n\n\n
Working with a CMS<\/h3>\n\n\n
Great, but what about situations where you can\u2019t change the HTML?<\/p>\n\n\n\n
You might just be typing up a quick CodePen or a business-card site. In that case, these concerns are going to seem like overkill. On the other hand, you might be working with a CMS where you aren\u2019t sure what is going to happen. You might need to plan for anything<\/em> and everything<\/em> that could get thrown at you. In those cases, you\u2019re unable to simply add classes to individual elements. You\u2019re likely to get a dump of HTML from some templating language.<\/p>\n\n\n\n
<?php echo getContent()?>\n<?=getContent()?>\n${data.content}\n{{model.cmsContent}}<\/code><\/pre>\n\n\n\n
So, if you can\u2019t<\/em> work with the HTML what can you do?<\/em><\/p>\n\n\n\n
<article class=\"post cms-blog-dump\">\n  <h1>Talking type-patterns on CSS-tricks<\/h1>\n  <p>Intoduction paragraph - and we'd like to style this with a slightly different size font then the next (normal) paragraphs<\/p>\n  <h2>Some headings<\/h2>\n  <h2>And maybe someone accidentally puts 2 headings in a row<\/h2>\n  <ol>\n    <li>and some <strong>list<\/strong><\/li>\n    <li>and here<\/li>\n  <\/ol>\n\n  <p>Or if a blog post is too boring - then think of a list of bands on an event site. You never know how many there will be or which ones are headlining, so you have to write rules that will handle whatever happens.\n<\/article><\/code><\/pre>\n\n\n\n
You don\u2019t have any control over this markup, so you won\u2019t be able to add classes, meaning that the cool plug-and-play classes you made aren\u2019t going to work! You might just copy and paste them into some larger .article { }<\/code> class that defines the rules for a kitchen sink<\/em>. That could work.<\/p>\n\n\n\n
What other tools are there to play with?<\/p>\n\n\n
Mixins<\/h4>\n\n\n
If you could create some reusable concept of a \u201ctype pattern\u201d with Sass, then you could apply those in a similar way to how the classes work.<\/p>\n\n\n\n
@mixin my-useful-rule { \/* define the mixin *\/\n  background-color: blue;\n  color: lime;\n}\n\n.thing {\n  @include my-useful-rule(); \/* employ the mixin *\/\n}\n\n\/* This compiles to: *\/\n.thing {\n  background-color: blue;\n  color: lime;\n}\n\/* (just so that we're on the same page) *\/<\/code><\/pre>\n\n\n\n
Less<\/a>, Sass<\/a>, Stylus<\/a> and other CSS preprocessors all have their own syntax for this. I\u2019m going to use Sass\/SCSS in these examples because it is the most common at the time of writing<\/a>.<\/p>\n\n\n\n
@mixin standard-type() { \/* define the mixin *\/\n  font-family: Serif;\n  font-size: 16px;\n  line-height: 1.4;\n  letter-spacing: 0.02em;\n}\n\n.context .thing {\n  @include standard-type(); \/* employ it in context *\/\n}<\/code><\/pre>\n\n\n\n
You can use heading-1()<\/code> and heading-2()<\/code> and a lot of big-name style guides do this. But what if you want to use those type styles on something that isn\u2019t a \u201cheading\u201d? I personally don\u2019t end up connecting the headings with \u201csize\u201d and I use the patterns in all sorts of different places. Sometimes my headings are \u201cmean\u201d and \u201cstout.\u201d They can be piercing red and uppercase with the same x-height as the paragraph text.<\/p>\n\n\n\n
Instead, I define the visual styles in association with how I want the \u201cvoice\u201d of the content to come across. This also helps the team discuss \u201ctone\u201d and other content strategy stuff across disciplines.<\/p>\n\n\n\n
For example, in Jason Santa Maria\u2019s book, On Web Typography<\/em><\/a>, he talks about \u201ctype for a moment\u201d and \u201ctype to live with.\u201d There\u2019s type to grab your attention and break up the page, and then those paragraphs to settle into. Instead of .standard-text<\/code> or .normal-font<\/code>, I\u2019ve been enjoying the idea of organizing styles by voice. This is all that type that a user should spend time consuming. It\u2019s what I\u2019d likely use for most paragraphs and lists, and I won\u2019t set it on the body.<\/p>\n\n\n\n
@mixin calm-voice() { \/* define the mixin *\/\n  font-family: Serif;\n  font-size: 16px;\n  line-height: 1.4;\n  letter-spacing: 0.02em;\n}\n\n@mixin loud-voice() {\n  font-family: Sans-Serif;\n  font-size: 30px;\n  line-height: 1.5;\n  letter-spacing: 0.03em;\n}\n\n@mixin attention-voice() {\n  font-family: Sans-Serif;\n  font-size: 24px;\n  line-height: 1.3;\n  letter-spacing: 0.04em;\n}<\/code><\/pre>\n\n\n\n
This idea of \u201cvoices\u201d helps me keep things meaningful<\/em> because it requires you to name things by the context. The name heading-1b<\/code>, for example, doesn\u2019t help me connect to the content to any sort of storytelling or to the other people on the team.<\/p>\n\n\n\n
Now to style the mystery article. I\u2019ll be using SCSS syntax here:<\/p>\n\n\n\n
article {\n  padding: 20px 0;\n  h1 {\n    @include loud-voice();\n    margin-bottom: 20px;\n  }\n  h2 {\n    @include attention-voice();\n    margin-bottom: 20px;\n  }\n  p {\n    @include calm-voice();\n    margin-bottom: 10px;\n  }\n}<\/code><\/pre>\n\n\n\n
Pretty<\/em>, right?<\/p>\n\n\n\n
But it\u2019s not that easy, is it? No. It\u2019s a little more complicated because you don\u2019t know what might be above or below each other \u2014 or what might be left out, because articles aren\u2019t always structured or organized the same. Those CMS authors can put whatever they want in there! Three <h3><\/code> elements in a row? You have to prepare for lots of possible outcomes.<\/p>\n\n\n\n
\/* Styles *\/\narticle {\n  padding: 20px 0;\n\n  h1 {\n    @include loud-voice();\n  }\n\n  h2 {\n    @include attention-voice();\n  }\n\n  p {\n    @include calm-voice();\n\n    &:first-of-type {\n      background: lightgreen;\n      padding: 1em;\n    }\n  }\n\n  ol {\n    @include styled-ordered-list();\n  }\n\n  * + * {\n    margin-top: 1em \n  }\n}\n<\/code><\/pre>\n\n\n\n
To see the regular CSS you can always \u201cView Compiled\u201d in CodePen.<\/p>\n\n\n\n