The New Typography

Originally published here:

Perfect typography is certainly the most elusive of all arts. Sculpture in stone alone comes near it in obstinacy.

— Jan Tschichold (Author of Die neue Typographie, 1928)

Alexandria, Arial, Cambria, Droid Sans, Lucida, Myriad, Raleway, Tahoma, Times New Roman, Ubuntu.

Those ten typefaces were used extensively on our website across various sections, and often on the same page to differentiate content elements and provide a visual identity to specific areas. They were then supplemented by a phalanx of back-up typefaces to cover issues of platform-specific availability – hello to Trebuchet, Malayalam, Optima, Geneva, Palatino, Georgia, Verdana.

It the time of implementing, having a large font stack made sense – in fact it was best practice. Fonts were identified that were common to specific operating systems and them paired up to create a unified “stack” of fonts that would ensure your content would look very similar however it was viewed. Web fonts were at the time still an emerging technology, and IE still had major issue with anything other than Embedded Open Type formats with @font-face – I documented the complexity of supporting this at the time.

Myriad was chosen as our headline font as it looked great and was readily available on most platforms due to being packaged by default on a mac, and bundled with Adobe Reader (a very common installed application on a pc). Recently we have seen a sharp decline in Myriad being installed on our target platforms – leading to some rendering issues with fonts defined lower down the ‘stack’, and a steady incline in the support of “web fonts”.

Our recent relaunch of the research section of our website afforded us the opportunity to use a framework (Foundation) and revisit the font stack in light of better options and support (Typekit, Google Web Fonts et al).

Here is an example of a commonly-used font-stack from our site:

font-family: "Myriad Pro", "Myriad Web","Apple Myriad","Adobe Myriad",Candara,"Trebuchet MS",Trebuchet,sans-serif;

This was replaced by the following in our research site:

font-family: "Raleway", sans-serif;

After two weeks auditing our site and uncovering all the various stylesheets that contained rules defining font families, I have now implemented a change to every page delivered by our CMS so that we use the same font stack as that defined in the Research restage. This work was not without its hiccups, as certain pages had some layout elements affected by the new font – but we are working with our web content providers across the university to fix any problems, and provide guidance where the update has highlighted practices that need updating.

I’ve also received feedback from maintainers of pages not in our CMS, who would like their content to be part of this project, which was very rewarding. And subsequently I’m looking at ways we can roll out this change to all pages hosted under our domain.

This is a really large step forwards for us, creating a consistent user experience as well as a much simpler maintenance process for everyone involved.

The next step after this initial consolidation is to work closely with our print colleagues to define a new typographic identity for the university that reflects its position both geographically and academically.

Watch this space.


Moving stylesheets forward dynamically

Originally posted on :

When I started 5 years ago, the university had a myriad of small stylesheets governing how each section – sometimes down to a single page – looked, on average these were small files and shared a lot of rules, generally due to one being copied as the starting point of the next.

The team soon embarked on a huge project to create a standard, consistent visual identity and to ensure this was applied correctly and easy to maintain we created one “global” stylesheet to replace all the narrow-scoped ones.

This global stylesheet has been modified and added to over the last half-decade as more demands are made of it, until it now weighs in at over 1600 lines of rules. We’ve often discussed ways to make this file easier to work with and update, usually around breaking it up into smaller, more specific files that were then brought back together for publishing. There just wasn’t an elegant way of doing this at the time. It was also apparent that several attributes (particularly colours and typography) were repeated throughout the document, and possibly overwritten further down as new rules were appended.

This really frustrated the team as we knew there should be a better way of doing this.

As part of relaunching our Research section we wanted to move from plain, hand-typed stylesheets to something more powerful, flexible and easy to maintain – which meant looking at either SASS or LESS as CSS preprocessors, which also meant we could address the issues of scalability and repetition that had started to bog down our global stylesheet.

We went with SASS as it was a better fit with our existing infrastructure, and I personally found it easier to pick and integrate into my workflow. Over the next few weeks I’ll post about the lessons we’ve learnt from using SCSS in the wild, but first I thought it’d be good to share some of the key reasons for adopting this approach to creating CSS files.


A simple ruby file allows you to customise the configuration of your project, and gives your processor (we used compass locally, and scssphp remotely due to current lack of a ruby dev server). This meant we could define the folder structure and also the level of commenting and compression applied to the output scss files. It also meant we could have separate dev and production config files:

Our defined structure – we have a preference for a HTML-based naming convention to files, so out went “stylesheets” “images” and “javascript” in favour of “css”, “img”, and “js”. We also added an underscore prefix to the default sass folder to ensure it always appeared at the top of any directory.


Define once, reference often. Prior to having custom defined variables we’d have to manually re-enter the same information over possibly dozens of rules, and then search and replace them whenever a change to the presentation was required. A great example of this would be defining font-stacks and global colour schemes:

$headings: 'Raleway', sans serif;
$copy: 'Lucida Sans', 'Lucida Grande', 'Lucida Sans Unicode', 'Bitstream Vera Sans', sans-serif;
$interaction: AlexandriaFLF, "Palatino Linotype", Palatino, Georgia, "Times New Roman", serif;

$linkcolour: #ee3388;
$bodycolour: #404040;

This could now be dropped into rules, safe in the knowledge that future iterations would only require one update in one place.


A simple but powerful benefit of using scss is that you can create partials – files of small specific rules that can be included into larger files at compilation. Our current list of partials gives an indication of the purpose of each – meaning simpler debugging, and also the ability for several people to work on areas of our site without having to constantly commit changes to the same main scss file and then compile remotely.

  • _normalize – a standard set of rules to remove differences between browser rendering. Based on the file that ships with sass builds of Foundation 4.
  • _baselayer – a set of rules to apply common presentation elements, all our basic visual styling is here.
  • _colour – predominantly the variables for our current global colour palette
  • _typography – again, mostly variables and functions

We still have a lot of work to do.

Okay, so that’s a quick up to speed of why we made the switch, and where we’re up to. As mentioned, I’ll be writing posts whenever we have significant discoveries, decisions, and/or solutions to share – for instance the following are all currently up for debate:

  • Agreeing naming conventions
  • How best to break up our stylesheets using partials
  • Being able to compile remotely and locally in the same fashion
  • Optimising existing CSS into SCSS
  • Deciding what (if any) mixin libraries to @include – compass and particularly bourbon look interesting.