Using Tachyons and keeping your markup dry

, . Filed under Web.

I’ve redone my website. A few years ago, when we styled #content and #sidebar, this would have taken several days. The “relaunch” would have been big news, the subject of blog posts and tweets. Now it takes a few hours at the weekend – we have tools like Jekyll and SASS to help us stay DRY and avoid monolithic, bottom up projects.

It looks pretty nice, but I wasn’t really interested in appearance this time. The biggest change has been “under the hood”. Over the last year or so I’ve used my own framework, building reusable modules a la Foundation and Bootstrap. So I’d have something like a slot for title/meta/excerpt patterns and a title-list for a list of titles with meta data.

Recently I’ve been more interested in lower level frameworks like Tachyons. There are a few reasons for this:

  • They weigh far less (the entire Tachyons framework is 7k)
  • They’re less opinionated than bigger frameworks as they operate at the CSS declaration level
  • When it does have opinions, Tachyons does things like type scale well
  • I write less CSS to get the look I want
  • They apply a strict one class for one job rule

That’s all good, but I found one problem, even on a small website like this. Take a look at the classes I use to build a page title:

<h1 class="custom-lh-title custom-green f3 f2 mt2 mt3-ns mb2 mb3-ns">Page title</h1>

I don’t have a problem with using one, five or fifty classes on an element, it’s just that I’ll use this type of page title in 3 different places. Before, I’d use the same class name (something like entry-title), which was easy to remember. Now, I need to remember (or copy and paste) a long string of spaces, letters and numbers.

More problematically, if I want to change the page title’s appearance I need to do it in three layout files. Before, I simply changed my entry-title declarations in my SASS file.

Less CSS abstraction means more HTML classes to manage.

It turns out this is my problem, not Tachyons’:

Most web projects will be utilizing some sort of templating system. Just as with any code, templates should be kept DRY. If the markup for something like a modal overlay is defined multiple times across templates, it should be consolidated to a single place. Rethinking Variables in CSS

So there’s the answer to my problem: Define these class chains in one place.

In Jekyll, you use include to call HTML. Normally, you include whole headers, sidebars and footers across all your pages, but there’s no reason why you can’t include a small list of classes within your templates. For example, you can create a page-title.html file containing:

custom-lh-title custom-green f3 f2 mt2 mt3-ns mb2 mb3-ns

and then include page-title.html to output your string in an element’s class attribute. If you want to change any property of your page titles you just edit the page-title.html file.