Typography

Typography was hard

Until now, trying to style an article, document, or blog post has been a tedious task that required a keen eye for typography and a lot of complex custom CSS.

When building application UIs, it's really useful to remove all the default browser styling, including paragraphs, headings, lists, and more. This is really useful because you spend no time fighting to undo user-agent styles.

This also means we need a way to opt into our design system's typography styles when we're working with written content.

We have two options.

The nuclear option is to use a .prose class that applies all of our typography styles to a block of content. This might seem great, but it also means that we're back to fighting to undo styles when using our components. The only difference is that now we're fighting against our own styles instead of the browser's, but the problem remains.

A better option is to stay in a clean slate state and look at typographical elements as components. This way, we can use our typographical components to opt into our design systems's typography styles without ever having to fight against them.

We could add a layer of abstraction over native HTML components and use polymorphic components, like <Heading as="h1"> or <Text as="p"> or we could use in-place replacement components, like <H1>, <P>, <Span>, or <Ol>.

Either way, we're opting into our design system's typography styles by using their corresponding classes .h1, .p, .span or .ol, so the difference between these two approaches is merelly in the developer experience.

It turns out that the second option provides for a better developer experience.

• The components are more semantic.
• Going from native unstyled HTML to using the full power of our design system's typography is as simple as uppercasing the first letter of each element, e.g. <h1> to <H1>.
• The components are simpler and without black box magic.

Some people might ask:

If the components are so simple — all they do is apply a class name — why not just use the class name directly?

Good question. Here's why:

• Using component classes as utility classes is a bad idea.

  Utility classes are atomic, and therefore, reusable. That's what keeps the CSS small. If you use component classes like .p or .h1 as if they are utility classes, i.e. without being matched to a component, you're back to the old Bootstrap days where you wouldn't know if a particular component class was being used or not, so you'd be afraid to remove it, and the CSS just keeps growing and growing.

  Component classes should always be matched to components.

• Going from native unstyled HTML to using the full power of our design system's typography is as simple as uppercasing the first letter of each element.

  Just replace all <p>’s with <P>’s.

• The components are more semantic.

  As opposed to more complex components — and the reason we need libraries like VerveUI — HTML was primarily designed for text. Moving away from HTML's well-designed native typographical elements has no intrinsic benefit and makes things like readability, maintanability, and SEO harder.

• The components are less verbose.

  <div>
  	<p className="p">This is a paragraph.</p>
  	<P>This is a paragraph.</P>
  </div>

  The second one is easier to read and write.

  Keep in mind it's that even though it's hard to differenciate between a p and a P in this code block, proper syntax highlighting in your code editor makes that a non-issue.

What to expect from here on out

What follows from here is just a bunch of absolute nonsense I've written to dogfood the typographical system itself. It includes every sensible typographic element I could think of, like bold text, unordered lists, ordered lists, code blocks, block quotes, and even italics.

Blockquotes without a <P> tag inside should look good, too. But if you want those nice “quote marks” you see on the upper blockquote, add one.

Let's slap a <Pre> tag with a <Code> tag inside it to see how that looks.

<article>
	<h1>Garlic bread with cheese: What the science tells us</h1>
	<p>
		For years parents have espoused the health benefits of eating garlic bread with cheese to their children, with the food earning such an iconic status in our culture that
		kids will often dress up as warm, cheesy loaf for Halloween.
	</p>
	<p>But a recent study shows that the celebrated appetizer may be linked to a series of rabies cases springing up around the country.</p>
</article>

What if we just want a <Pre> tag without any code?

That looks pretty good, too.
	If you just want
		to have a preformatted block
			of text
				that you want to look nice,
we've got your covered!

What about links? Here's a link to the homepage. That looks pretty good, too. We've got a nice distinct gray with an underline.

It's important to cover all of these use cases for a few reasons:

1. We want everything to look good out of the box.
2. Really just the first reason, that's the whole point of the plugin.
3. Here's a third pretend reason though a list with three items looks more realistic than a list with two items.

Now we're going to try out another header style.

Typography should be easy

So that's a header for you — with any luck if we've done our job correctly that will look pretty reasonable.

Something a wise person once told me about typography is:

Typography is pretty important if you don't want your stuff to look like trash. Make it good then it won't be bad.

It's probably important that images look okay here by default as well:

Now I'm going to show you an example of an unordered list to make sure that looks good, too:

• So here is the first item in this list.
• In this example we're keeping the items short.
• Later, we'll use longer, more complex list items.

And that's the end of this section.

What if we stack headings?

We should make sure that looks good, too.

Sometimes you have headings directly underneath each other. In those cases you often have to undo the top margin on the second heading because it usually looks better for the headings to be closer together than a paragraph followed by a heading should be.

When a heading comes after a paragraph…

When a heading comes after a paragraph, we need a bit more space, like I already mentioned above. Now let's see what a more complex list would look like.

• I often do this thing where list items have headings.

  For some reason I think this looks cool which is unfortunate because it's pretty annoying to get the styles right.

  I often have two or three paragraphs in these list items, too, so the hard part is getting the spacing between the paragraphs, list item heading, and separate list items to all make sense. Pretty tough honestly, you could make a strong argument that you just shouldn't write this way.

• Since this is a list, I need at least two items.

  I explained what I'm doing already in the previous list item, but a list wouldn't be a list if it only had one item, and we really want this to look realistic. That's why I've added this second list item so I actually have something to look at when writing the styles.

• It's not a bad idea to add a third item either.

  I think it probably would've been fine to just use two items but three is definitely not worse, and since I seem to be having no trouble making up arbitrary things to type, I might as well include it.

After this sort of list I usually have a closing statement or paragraph, because it kinda looks weird jumping right to a heading.

Code should look okay by default.

I think most people are going to use highlight.js or Prism or something if they want to style their code blocks but it wouldn't hurt to make them look okay out of the box, even with no syntax highlighting.

Here's what a default tailwind.config.js file looks like at the time of writing:

module.exports = {
	purge: [],
	theme: {
		extend: {},
	},
	variants: {},
	plugins: [],
}

Hopefully that looks good enough to you.

What about nested lists?

Nested lists basically always look bad which is why editors like Medium don't even let you do it, but I guess since some of you goofballs are going to do it we have to carry the burden of at least making it work.

1. Nested lists are rarely a good idea.
   • You might feel like you are being really "organized" or something but you are just creating a gross shape on the screen that is hard to read.
   • Nested navigation in UIs is a bad idea too, keep things as flat as possible.
   • Nesting tons of folders in your source code is also not helpful.
2. Since we need to have more items, here's another one.
   • I'm not sure if we'll bother styling more than two levels deep.
   • Two is already too much, three is guaranteed to be a bad idea.
   • If you nest four levels deep you belong in prison.
3. Two items isn't really a list, three is good though.
   • Again please don't nest lists if you want people to actually read your content.
   • Nobody wants to look at this.
   • I'm upset that we even have to bother styling this.

The most annoying thing about lists in Markdown is that <li> elements aren't given a child <P> tag unless there are multiple paragraphs in the list item. That means I have to worry about styling that annoying situation too.

• For example, here's another nested list.

  But this time with a second paragraph.

  • These list items won't have <P> tags
  • Because they are only one line each

• But in this second top-level list item, they will.

  This is especially annoying because of the spacing on this paragraph.

  • As you can see here, because I've added a second line, this list item now has a <P> tag.

    This is the second line I'm talking about by the way.

  • Finally here's another list item so it's more like a list.

• A closing list item, but with no nested list, because why not?

And finally a sentence to close off this section.

There are other elements we need to style

I almost forgot to mention links, like this link to the homepage. We almost made them blue but that's so yesterday, so we went with light gray, feels edgier.

We even included table styles, check it out:

We also need to make sure inline code looks good, like if I wanted to talk about <span> elements or tell you the good news about @verveui.

Sometimes I even use code in headings

Even though it's probably a bad idea, and historically I've had a hard time making it look good. This "wrap the code blocks in a soft background" trick works pretty well though really.

Another thing I've done in the past is put a code tag inside of a link, like if I wanted to tell you about the docs. Looking pretty great, right?

We haven't used an h4 yet

But now we have. Please don't use h5 or h6 in your content, Medium only supports two heading levels for a reason. h4 elements are already so small that they are (almost?) the same size as the body copy. What are we supposed to do with an h5, make it smaller than the body copy? No thanks. So So, given it's a design principle of VerveUI to only have one (good) way of doing things, I'm a bit torn on this one. I guess we'll see how it goes.

We still need to think about stacked headings though.

Let's make sure we don't screw that up with h4 elements, either.

Phew, with any luck we have styled the headings above this text and they look pretty good.

Let's add a closing paragraph here so things end with a decently sized block of text. I can't explain why I want things to end that way but I have to assume it's because I think things will look weird or unbalanced if there is a heading too close to the end of the document.

What I've written here is probably long enough, but adding this final sentence can't hurt.