A Pocket Guide to Front-end Style Guides
Use the style guide as a way to show these extremes, and prove that you’ve tested and know how to appropriately deal with these situations.
A style guide explains how things are going to look, whereas a pattern library tends to focus on how they work. Style guides are a fantastic tool for designers, and pattern libraries are generally more useful for developers, but there will be some overlap.
If you’re creating a new style guide for an existing site, a nice side effect is that it’s often an opportunity to standardise the design, and check with the designer that they didn’t unintentionally create two styles for the same thing (like they’ve left in a layer that is part of an old version of the design).
It may help to have a version number on the document, especially if several people are working on it. If you’re using version control, you could pull the last commit ID onto the page. It’s also handy to indicate the last modified date so you can check how up-to-date the style guide is.
Style prototypes help demonstrate how different styles will feel once they’re in the browser. They capture things like button hover states and interactions on a very detailed and granular scale.
A style guide can show clients that websites are systems rather than collections of pages.
check that your modules degrade gracefully when JavaScript is disabled, when they’re viewed in older browsers, and when images or SVGs don’t load.
The process of building a style guide acts as a design audit of the site, and you can often find ways of merging two (or more) very similar styles for the same thing into one.
Grabbing a style and reusing it on the site should be as simple as copying and pasting the relevant markup.
If it’s comprehensive enough, a style guide reduces the likelihood of naked (unstyled) elements. Elements that often get missed out of design mock-ups include styles for definition lists; tabular data; form fields; block quotes; hover, active and focus styles on links; and even bullet points.
I believe producing a style guide encourages more meaningful code. Just writing it forces you to think about the semantics of the elements you’re using.
It can even serve as a spec for developers – they’ll be able to see an overview of what modules need to be built and roughly how they’ll work.
The modules sit within the page wrapper (the header and footer) as though it were a single template, but with a lot of different types of content in it.
Where front-end style guides excel is in encouraging collaboration between designers and developers.
They should remain as comfortable to live in over time as they were when first built.
device and browser testing should run throughout the build rather than be a source of stress right before a deadline.
When a CMS requires editors to write in Textile or Markdown, I add a cheatsheet to the style guide
Style guides should be unassuming. The reader may not have been present when the site was built, so I find it helps to imagine the reader as a developer who writes sloppy markup, or an editor who loves using headings for styling random bits of text, or a designer who gets a little overexcited when using a colour palette.
keep your boilerplate styles as neutral as possible to make them easy to override and work in as many situations as possible.