launchpad-dev team mailing list archive

[Huw Wilkins <huw.wilkins@xxxxxxxxxxxxx>]

Hi everyone,

Here is my proposal for how we should structure our CSS. I'm sure I have 
missed things or structured things poorly so for my sanity it would be 
good to get some feedback. Once that's done I plan to add this to the 
wiki with some examples. I will probably find a bunch of missing info 
once I actually start doing the work, but this is a start.



       Base elements

These are generic elements that will often be used to make up a 
component. These are the defaults we set that everything else will build 
on. Within this file you should try normalise as many generic elements 
as you can (this will take the place of a reset file).

Examples: generic headings, links, images, forms, generic buttons


       Layout

These elements are the main page structure. Usually there should be only 
one of each element, and each element should have an ID. If it's a 
re-usable component it probably isn't layout. Layouts are really just a 
special type of component and generally should follow component rules 
(see below).

Examples: header, footer, sidebar, content and main navigation.


       Components

These elements are the content themselves and usually make up what might 
be called a widget (or component). They will almost always be a 
collection of elements.

Examples: content portlets, overlay popups, bug lists.


       Modifiers

Modifiers are used to change the state or the presentation of something. 
Modifier classes should usually live with the class(es) they are 
modifying unless they are very generic. They may be generic typography 
modifiers (which would live in typography.less.css) or for a specific 
component (which will live in that components .css file). Component 
modifiers should be clearly labelled (using a clearly labeled section at 
the bottom of the stylesheet may be a good way to do this).

Examples: a portlet could have a collapsed state which you would control 
by applying a "collapse" class. A layout could be one column or two 
column which could be controlled by "one-column" and "two-column" classes.


       Naming scheme

CSS classes should be separated by hyphens. Abbreviations should be avoided.

There are no set prefixes or conventions for layout, base elements and 
modifiers.
Components should use ".component-name" and 
".component-name-element-name" where appropriate.


       Files

 * base.less.css
     o typography.less.css
     o forms.less.css
     o colours.less.css
 * layout.less.css
 * modifiers.less.css
 * components/component_name.less.css


If a file contains LESS it's file extension should be ".less.css". If 
you're unsure add ".less" as most of our files will end up containing 
LESS and this will help us keep track.


       ID usage

IDs can be used when there should only be one of something on the page. 
It is recommended that IDs are not used for styling. Components, Base 
elements and Modifiers should never contain IDs, Layout elements should 
usually have IDs (for the base element). IDs can be used (where 
appropriate) when required by JavaScript element selection.


       CSS compatibility

We should use CSS3 where possible. To maintain compatibility with older 
browsers we should use conditional statements and separate stylesheets 
with overrides for our other classes.

Example:
<!--[if IE 6]>
<link rel="stylesheet" type="text/css" href="ie6.css" />
<![endif]-->


That's it folks.

Cheers,

Huw