<p>Over the last six years or so, I’ve been using these things I’ve been calling “type patterns” in my web design work, and they’ve worked out pretty well for me. I’ll 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> <p>If you’ve used print design desktop software like QuarkXPress, Adobe InDesign, or CorelDraw, then imagine this idea is an HTML/CSS translation of “paragraph styles.” </p> <p>When designing a book (that spans hundreds of pages), you might want to change something about the heading typography across the whole book (on the fly). You would define how a certain piece of typography behaves in one central place to be applied across the entire project (a book, in our example). You need control of the patterns. </p> <p>Most programs use this naming style, but their user interfaces vary a little. </p> <p>When you pull up the pane, there’s usually a “base” paragraph style that all default text belongs to. From there, you can create as many as you want. Paragraph styles are for “block” level-like elements, and character styles are for “inline” level-like elements, such as bold or unique spans. </p> <p>The user interface specifics shouldn’t matter — but you can see that there are a lot of controls to define how this text behaves visually. Under the hood, it’s just key: value pairs, which is just like CSS property: value pairs </p> <p>h1 {<br /> font-family: &#8220;Helvetica Neue&#8221;, sans-serif;<br /> font-size: 20px;<br /> font-weight: bold;<br /> color: fuchsia;<br /> } </p> <p>Once defined, the styles can be applied to any piece of text. The little + (next to the paragraph style name below) in this case, means that the style definition has changed. </p> <p>If you want to apply those changes to everything with that paragraph style, then you can “redefine” the style and it will apply project-wide. </p> <p>When I say it like that, it might make you think: that’s what a CSS class is. </p> <p>But things are a little more complicated 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. </p> <p>Styles change as the context changes. </p> <p>The bare minimum of typographic control </p> <p>In your very earliest days as a developer, you may have been introduced to semantic HTML, like this: </p> <p>Here&#8217;s some HTML stuff. I&#8217;m a heading level 1<br /> And some more. I&#8217;m a paragraph. </p> <p>This is a heading level 2<br /> And some more pragraph stuff. </p> <p>And that pairs with CSS that targets those elements and applies styles, like this: </p> <p>h1 {<br /> font-size: 50px; /* key: value pairs */<br /> color: #ff0066;<br /> } </p> <p>h2 {<br /> font-size: 32px;<br /> color: rgba(0,0,0,.8);<br /> } </p> <p>p {<br /> font-size: 16px;<br /> color: deepskyblue;<br /> line-height: 1.5;<br /> } </p> <p>This works! </p> <p>You can write rules that target the headers and style them in descending order, so they are biggest > big > medium, and so on. </p> <p>Headers also already have some styles that we accept as normal, thanks to User Agent styles (i.e. default styles applied to HTML by the browser itself). They are meant to be helpful. They add things like font-weight and margin to the headers, as well as collapsing margins. That way — without any CSS at all — we can rest assured we get at least some basic styling in place to establish a hierarchy. This is beginner-friendly, fallback-friendly… and a good thing! </p> <p>As you build more complex sites, things get more complicated </p> <p>You add more pages. More modules. More components. Things start to get more complex. You might start out by adding unique classes and styles for every single little thing, but it’ll catch up to you. </p> <p>First, you start having classes for special situations: </p> <p> Be excellent to each other </p> <p>Party on, dudes. </p> <p>And yeah. I&#8217;m just a regular paragraph. </p> <p>Then, you start having classes everywhere (most CSS methodologies even encourage this): </p> <p> Be excellent to each other </p> <p> Party on dudes </p> <p> And yeah. I&#8217;m just regular </p> <p>Newcomers will try and work around the default font sizes and collapsing margins if they don’t feel confident “resetting” them. </p> <p>This is where people start trying out margin-top: -20px… and then stuff gets whacky. As you keep writing more rules to wrangle things in, it will feel like you are “fixing” things instead of declaring how you actually want them to work. It can quickly feel like you are “fighting” the CSS cascade when you’re unaware of the browser’s User Agent styles. </p> <p>A real-world example </p> <p>Imagine you’re at your real job and your boss (or the visual designer) gives you this “pixel perfect” Adobe Photoshop document. There are a bunch of colors, layout, and typography. </p> <p>You open up Photoshop and start to poke around, but there are so many pages and so many different type styles that you’ll need to take inventory and gather what styles can be combined or used in combination. </p> <p>Would you believe that there are 12 different sizes of type on this page? There’s possibly even more if you also take the line-height into consideration. </p> <p>It feels great to finish a visual layout and hand it off. However, I can’t tell you how many full days I’ve spent trying to figure out what the heck is happening in a Photoshop document. For example, sometimes small-screens aren’t taken into consideration at all; and when they are, the patterns you find aren’t 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> <p>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’ll have to talk to them about it. But this article is advocating that we talk about it much earlier in the process. </p> <p>You might get a style guide to reference. But even that might not be specific enough to identify contexts. </p> <p>Let’s zoom in on one of those guidelines: </p> <p>We get more content direction than we do behavior of the content in different contexts. </p> <p>You may even get a formal, but generic, style guide with no pixel sizes or notes on varying screen sizes at all! </p> <p>Don’t 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’s more confusing than helpful. I’ve 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 — and more. </p> <p>It’s hard to parse this stuff, even with the best of intentions! </p> <p>Early in your development career, you’d probably assume it’s your job to “figure it out” and get to work, writing down all the pixels and trying your best to make sense of it. Go get ‘em! </p> <p>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> <p>.blog article p {<br /> font-family: &#8216;Georgia&#8217;, serif;<br /> font-size: 17px;<br /> line-height: 1.4;<br /> letter-spacing: 0.02em;<br /> margin-bottom: 10px;<br /> } </p> <p>.welcome .main-message {<br /> font-family: &#8216;Georgia&#8217;, serif;<br /> font-size: 17px;<br /> line-height: 1.4;<br /> letter-spacing: 0.02em;<br /> margin-bottom: 20px;<br /> } </p> <p>@media (min-width; 700px) {<br /> .welcome .main-message {<br /> font-size: 18px;<br /> }<br /> } </p> <p>.welcome .other-thing {<br /> font-family: &#8216;Georgia&#8217;, serif;<br /> font-size: 17px;<br /> line-height: 1.4;<br /> letter-spacing: 0.02em;<br /> margin-bottom: 20px;<br /> } </p> <p>.site-footer .link list a {<br /> font-family: &#8216;Georgia&#8217;, serif;<br /> font-size: 17px;<br /> line-height: 1.4;<br /> letter-spacing: 0.02em;<br /> margin-bottom: 20px;<br /> } </p> <p>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’t necessarily want everything inheriting everything. </p> <p>body {<br /> font-family: &#8216;Georgia&#8217;, serif;<br /> font-size: 17px;<br /> line-height: 1.4;<br /> letter-spacing: 0.02em;<br /> } </p> <p>Things will work out OK. Most of the web was built like this. We’re just looking for something even better. </p> <p>Dealing with design revisions </p> <p>One day, there will be a meeting. In that meeting, you’ll 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> <p>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’ll 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> <p>I won’t write it out here, but you’ll try a bunch of different things over time, and people usually come to the conclusion that you can create a class — and add it to the element instead of duplicating rules/declarations for every element. You’ll go even further to try and pull patterns out of the visual designer’s documents. (You might even round a few 19px down to 18px without telling them…) </p> <p>.standard-text { /* or something */<br /> font-family: serif;<br /> font-size: 16px; /* px: up for debate */<br /> line-height: 1.4; /* no unit: so it&#8217;s relative to the font-size */<br /> letter-spacing: 0.02em; /* em: so it&#8217;s relative to the font-size */<br /> } </p> <p>.heading-1 {<br /> font-family: sans-Serif;<br /> font-size: 30px;<br /> line-height: 1.5;<br /> letter-spacing: 0.03em;<br /> } </p> <p>.medium-heading {<br /> font-family: sans-Serif;<br /> font-size: 24px;<br /> line-height: 1.3;<br /> letter-spacing: 0.04em;<br /> } </p> <p>Then you’d apply the class to anything that needs it. </p> <p> Be excellent to each other </p> <p> Party on dudes </p> <p> And yeah. I&#8217;m just regular </p> <p>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 with these CSS classes to get the style you want, even if you’re the new intern. </p> <p>It’s really helpful to separate the idea of “layout” elements (structure/parents) and the idea of “modules” or “components.” In this way, we’re treating the pieces of text as lower level components. </p> <p>The key is to keep the typography separate from the layout. You don’t want all .medium-heading elements to have the same margins or colors. It’s going to depend on where they are. This way you are styling based on context. You aren’t ‘using’ the cascade necessarily, but you also aren’t fighting it because you keep the techniques separate. </p> <p>.site-header {<br /> padding: 20px 0;<br /> } </p> <p>.welcome .medium-heading { /* the context — not the type-pattern */<br /> margin-bottom: 10px;<br /> } </p> <p>This is keeping things reasonable and tidy. This technique is used all over the web. </p> <p>Working with a CMS </p> <p>Great, but what about situations where you can’t change the HTML? </p> <p>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’t sure what is going to happen. You might need to plan for anything and everything that could get thrown at you. In those cases, you’re unable to simply add classes to individual elements. You’re likely to get a dump of HTML from some templating language.</p>