Webmasters Gallery

How often have you seen a “completed” site that still has lorem ipsum text lurking in the quiet corners? While we often strive for perfection in our designs and code, I am reminded every time I stumble across a garbled bit of lorem ipsum that not all aspects of web development process are given the attention they deserve.

Developing a complete and detailed suite of typographic elements is an often-overlooked aspect of the process. While not always as prominent or exciting as other graphic elements, typography is an essential part of every site and does most of the heavy lifting to fulfill each page’s purpose: transferring information.

While I can’t do anything about lazy lorem ipsum use, I’ve been working on a tool that helps develop beautiful and robust online typography.

Why I Care So Much About Typography

A little bit about me will help set the scene. I’m a full-stack developer working alongside designers in a digital agency. I studied graphic design before moving into development, so I understand layout and typography. Although I started out in design, I want to stress that I do not consider myself a designer. For this reason, this post will not explain how to design a type system. I will talk about how to implement one in development.

Throughout my career as a developer, I have frequently noticed sites that miss the finer details of typography. Although not glaring problems, these little mistakes whittle away at the overall user experience.

I’m not entirely sure why typographic mistakes happen so often. Perhaps it’s due to time constraints, oversights during development, or something completely different.

I’ve been on a mission to solve this issue, which has lead me to writing this article and also the development of my current side project: Type Nugget. It’s a tool that I hope allows users to easily create robust type systems.

Why You Should Care About Typography, Too

The benefits of having a robust type system in place are many. It ensures consistency across your project and allows you to write less code. Most importantly, though, a robust type system makes sure the content communicates what it’s supposed to.

A workmate recently sent me an article on Pitchfork. As soon as I landed on the page I fell in love with their type system and structure. Reading the copy was smooth; an absolute pleasure. Their typographic system is simple and beautiful. I’ll be making references to this website as I continue talking about type systems!

(Look at that drop cap ?)

One of the most important requirements of a type system in today’s web climate is that it works perfectly across all possible existing viewports. We never know what’s going to come next in the world of devices! This is doable, but first, let’s get into the world of responsive units.

Looking at Responsive Units with Heart Eyes ?

In my opinion, you can’t master web typography until you understand responsive units. Wrapping your brain around responsive units takes a little bit of math, but it really changes your world once you’ve figured it out. Soon, the sight of px will make you cringe!

There are already articles on this particular topic, so I won’t delve too deep, but here’s a brief explanation of the units I tend to use with type:

• em: Relative to the current (inherited) font-size. If I set an element inside this article to font-size:2em, it would be twice the font-size of the rest of the article.
• rem: Relative to the font-size of the root element (which is a fancy way of saying the html element). If I added another element inside of the element used in the previous example, and then set it to font-size:1rem, it would now be the original size, regardless of it’s parent being set in ems (I set up a pen here that shows how ems and rems work together).
• vw & vh: Relative to 1% of the viewport width & height, respectively. So 5vw means the font-size is 5% of the browser width, and 5vh is 5% of the browser height.

I tend to set a px font-size on the root element of the document, and set the rest of the typographical elements using ems for font-size and rems for margins to keep a consistent type grid. I often like to set headings in vw (or even on occasion, vh) and use a media query to transition them to an em size after a certain viewport max-width has been reached. This avoids blown out headings on even the smallest of mobile devices. There’s a great Sass mixin by Eduardo Bouças here for making viewport relative text with minimum and maximum sizes.

Responsive Units in Action

Let’s take a look at how Pitchfork has used responsive units.

The font-size on their html and body elements is set to 10px. They then have a .contents div that wraps all of their article content. It’s set to 1.8rem and changes to 1.6rem once the viewport is less than 992px wide (I would have done this mobile-first instead of desktop-first, but I think that’s just a matter of preference). This means that the main content font-size is 18px on desktop and 16px on smaller devices (10px * 1.8 = 18px, 10px * 1.6 = 16px), both very comfortable font sizes for the given viewports.

The headings styles vary appropriately depending on what kind of article you are reading, but seem to scale in a similar way. The h1 on a Features page starts at 4.8rem, scales to 4rem when the viewport is less than 992px wide, then 3rem when the viewport is less than 767px wide (48px,40px & 30px respectively). The .contents div also always prevents the copy from exceeding the optimal measure (line length) of the text which, as a general rule of typography, is somewhere between 40 and 80 characters long depending on context.

Pitchfork have done well, but this is really the bare minimum required for a great type system to flourish.

Building on that minimum, it’s important to realize that typography is more than just text. There is a whole suite of elements (h1-h6, p, span, em, strong, a, ul, ol, li, blockquote, caption, and a whole bunch more) that contribute to the typographical flow and appearance of content. It’s important that they’re not forgotten, especially when working on content heavy websites like blogs or news sites. Using a CSS reset like Normalize.css or a framework like Bootstrap normally means you have this covered already. However, it’s always a nice touch to stray a little from the default. I often find it helpful to set a global margin on all of these elements within a content context that is equal to the main line-height. This maintains a nice, consistent grid. For example, if my main copy within .content is 1em with a line-height of 1.6em, then the top and bottom margins on all my headings, paragraphs and other elements within .content are also set to 1.6em. This is not a strict rule, just a good starting point.

As a side note, while the above elements are fantastic for dictating the visual aspect of a website, they’re also incredibly important for making sure a website is accessible. Using semantic HTML elements makes sure your website makes sense to machines, such as screen readers for the visually impaired, or web crawlers like Google.

I was trawling through Pitchfork trying to find examples of some of these elements. When I couldn’t find an example of a list, I entered one into the page through dev tools out of curiosity. Sure enough, they were styled nicely even though I couldn’t find examples of where/if they were used on the site. ??

While not technically falling directly under the umbrella of typography, I believe states and transitions are a big deal for the overall feel of a website. Unfortunately, they too are often forgotten. I assume the first thing that comes to many developers’ minds when I say “states and transitions” are link styles. That’s not all of it though and it’s not all hover styles either. Hover styles are important for links, but focus is also important.

Have you ever tried navigating through a website using tab and shift+tab? I certainly have, and on some websites it’s almost impossible. The browser has a default method of displaying this but I’ve often seen this removed because it’s not aesthetically pleasing. Please, if you’re going to remove it, replace it with something prettier!

Form inputs can also be greatly enhanced by :focus styles and really add that extra something to your site. Another thing I’ve noticed on this topic is either a lack of transitions or transitions with odd timing, both of which makes moving between different states feel really jerky or unnatural. In my experience, I’ve found transitions between 1.5s-2.5s plenty. Anything more than that makes me uncomfortable (again this is a general rule that can be broken when necessary).

While we’re talking about transitions, try to avoid transitioning all properties of an element. This will probably come to bite you either performance-wise, or down the line when trying to style a child element.

Additional Reading on Architecture

Here’s a few things that I’ve learned that have made my development life significantly better:

• Avoid specificity issues by staying clear of unnecessary styling directly on elements e.g. styling .nav a when you could have styled .nav__item. I found this most crucial when styling headings. I used to style the h1-h6 tags directly, until I realized that h1-h6 are semantic elements that mark different stages of a document. Not all h1 tags need to look the same! I now style headings using classes such as .heading--xl, .heading--sm.
• Use global text modifier classes instead of adding random CSS to change small parts of a project. e.g. I use classes like .text--xl, .text--sm.
• Avoid unnecessary nesting of selectors e.g. .nav > .nav__item when you could have just styled .nav__item. This avoids specificity issues and can also improve performance as the browser doesn’t have to do as many lookups on elements. Take a look at this article about Modular CSS for more information on why this is good to avoid.
• Adopt a CSS “architecture”. It doesn’t need to be an existing one. Make one up if you wish. Just have one. I use something very similar to BEM coupled with the methodology in the Modular CSS article linked above. Here’s a great list of some different architectures (and various other great things). A great CSS-Tricks article was written on this very recently, also. Go give that a read if you’re interested!

Check Out Type Nugget

The agency I work for has an innovation program that gives us time to work on our own products and ideas. I’ve gathered a small team that shares my passion for these topics. For the last few months we’ve been building Type Nugget.

Type Nugget is a tool that makes it easier for developers to build a solid type system based off the principles I’ve discussed. It still has a fair way to go before it’s where I want it to be, but we have eyes on it becoming the go-to app for setting up web type systems, as well as building a great community for web type enthusiasts.

We’re super excited to make it a reality, so check it out and let us know what features you’d love to see!

Wrapping Up

The internet is all about content. As web developers, our job is to make sure users can understand that content. To me, that’s a good enough reason for any web dev to know type systems inside and out. The case gets even stronger when responsive units are added to the mix. So take an hour or two to brush up on these integral elements of web development. Or, take the easy way out and use Type Nugget ?

Design Your Content Typography First (and a Look at Type Nugget) is a post from CSS-Tricks