Classes are general and written in English. Do not give every element on every page a unique class. Do not give elements very specific names. Classes are inherited from their parent element. Classes are combined together to style elements uniquely.

Classes are used to add structural meaning. A good class describes more specifically the function of the element to which it is applied. A bad class is something like red ; a good class is something like warning. (Imagine that you were creating a skin for people with red-green color blindness, and you wanted to change the appearance of words using the class red to be the color blue! That would be very confusing and therefore harder to maintain.)

Class names are short and, ideally, English words in common usage. If you find yourself combining several words to make a class, like english_user_information, stop and think whether you could use several more general classes: english user information.

Our classes are how we describe and document our data, so it's very important to use them consistently and accurately. If you find a class that doesn't fit this system, it's probably a mistake and needs fixing.

Metadata Grouping

Content Type

Meta data

Grouping and spacing presentational elements

Roles and States



What Kind and Where?

It might be useful to look at some diagrams of pages on our archive, to really understand that in CSS, we write a path to places in our XHTML; we don't need to give everything a unique name, because we describe it: "what kind and where".

Rails Classes

Rails automatically generates a unique class on #main on each page, named by the view partial #main calls. This means that each page on the archive can have rules set independently, which is very useful for tweaking the layout, but ought not to be used as a core technique. = = .sidebar

System Messages and Warnings

This is a work in progress. Could you design a system of messages and warnings? Check the issues list!

← Back