It happens pretty often to encounter situations when you don’t like a default style for an HTML element. The methodology that has proven to be reliable over time is to use the so-called CSS utility classes. Their purpose is to allow you to quickly make HTML classes adjustments until the result looks just right.
CSS utility classes
The utility classes, sometimes called helpers, are simple and reusable CSS class selectors that apply a certain and clear rule in your design system.
For example you may think about the well known
What is this about?
In this article, we’ll try to walk through the naming conventions that various frameworks and design systems use when it comes to typography, especially headings sizing.
The .h1 to .h6 naming convention
I remember I had an Aha! moment first time I ever saw the above naming convention. Ever since then, whenever it comes to typography for a new project, I often try to build my styles using utilities like
In other words, this translates to: I want a larger font size for the
h2, please make it look like an
h1. That’s actually a fair compromise between semantics, thus SEO and visual appearance requirements.
While trying to beat procrastination and start writing this article down, I was curious to find out the above naming convention origins.
How did I not know or guessed that? Of course, it had to be OOCSS!
Object-oriented CSS or OOCSS is a methodology developed by Nicole Sullivan, that helps writing write fast, lightweight and maintainable CSS by treating HTML elements as objects, giving all these objects classes.
We now have ACSS, BEM, SMACSS or SUIT CSS but it all started with OOCSS at Web Directions North in 2009.
Regarding the above question I asked on Twitter, Nicole wrote a very interesting short story on how these heading naming conventions became a thing. You should go read it.
Getting back to this article’s topic, it seems that defining heading styles using the OOCSS methodology is widely adopted nowadays.
At the moment of this writing, many frameworks and design guides are using it:
Let’s go further and see other approaches (in random order) when it comes to typography and heading utilities.
I’m not such a fan of the
.hNnotation, I much prefer a solution that I believe to have been suggested by Mr Jeremy Keith, and that is to use abstract classes made up of the first six letters of the Greek alphabet
Harry Roberts on font sizing in CSS
As their documentation states, there are 2 types of headings:
.subtitle. But the interesting fact, in my opinion, is the seventh size available.
On a side note, in a recent HTML study I made, I did found 21,403
h7 HTML elements within 8 million web pages.
All headings (h1–h6) are reset to the base (body text) size, with margins and padding reset to zero. When building an enterprise application, the heading level may vary depending on the context of the component or page. Using the correct heading level is important for accessibility.
Atomizer creates CSS style declarations based on Atomic classes it finds in your project.
When it comes to Atomic CSS, the Atomizer tool generates your style sheets based on how you’re writing the HTML classes.
Each size is given a name derived from traditional type measuring techniques dating back to as early as 1582.
Shaun Bent on CSS at BBC
Header sizes are defined from
h6. Additionally, Solid provides responsive prefixed utility classes ranging from
.xs-text-6for sizing blocks of text. For the same font size across devices, use the default
.xs-text-nclass. Headers and text sizing classes have no margins or padding by default.
What about the others?
Other popular frameworks like Pure CSS, Milligram or Skeleton don’t use CSS utilities at all when it comes to headings sizes.
While doing some research on this article, I stumbled upon some misleading or not so up to date style guides.
The MailChimp website headings and utilities seem to have nothing to do with their own typography style guide.
Instead, they seem to use the following convention in their style sheets.
The GitHub’s Primer repository shows the following naming convention, which appears to be used across most of Github’s website pages. And yes… I kinda manually checked several pages to make sure this info is correct.
Their live documentation is outdated but it looks like things are work in progress.
We turned Primer CSS into a monorepo and improved our build process, and we’ve been building a new documentation website that we’ll make public in fall, 2017.
Whilst this article is about sizing only, a comparison in terms of semantics and accessibility between let’s say grids, buttons or maybe form elements is something that would be interesting to see.