This is the celebrated journal of Mr. Simon Collison A.K.A Colly

Process Toolbox, part seven: Convention

22nd March 2010

Here’s part seven of The Process Toolbox, a transcript of my @Media presentation. Having dealt with inspiring creativity in the last instalment, I’m moving on to conventions and flexibility. Without question or compromise, every website needs to be built with a solid foundation layer - a reusable package.

Quality control

Quality Control & Assurance

It can be beneficial to identify members of a team who will be responsible for quality-controlling certain areas throughout the project - such as a CSS lead, a CMS lead etc. This puts responsibility in the hands of members of the team, and they then develop the ideas and establish agency-specific conventions. Naturally, anyone can contribute ideas or suggestions at any time, but it’s good to have someone fostering your CSS and making sure it’s as good as it can be prior to any releases.

On Convention

We all understand the importance of semantic naming conventions; of the stylesheet cascade, of JavaScript frameworks and unobtrusive implementation; of choosing a way of writing code and sticking to it. There are many different ways of doing many different things. My naming conventions might differ from yours, and my way of ordering my CSS might clash with your own.

This can be taken a step forward and given clarity by setting out a suite of files and resources that kick-start any build, whether final product, prototype etc. You can call it a framework if you wish, but I don’t. Anyway, there are good reasons for working in this way:

  • Allows better collaboration within the team; the designer can jump into the developer’s code and vice-versa.
  • Anyone who hasn’t even worked on a certain project can jump in and quickly solve problems because everything is on convention.
  • Keeps output fresh and ensures use of best practices.
  • Establishes a thoroughly connected layer of base files allowing for swift CSS and JavaScript implementation and other assets.
HTML and CSS examples

For example, in the head element of our web pages, we can use comments to clearly define meta data and links to external files in a set order. We can use conditional comments to always prepare for serving alternate CSS to IE versions. There are many more bits and pieces to include by default (view source on this site).

In the main CSS file, we can add a Table Of Contents as we build, making it easy for anyone to quickly find a chunk of CSS. That TOC is in place from the start, so the designer can simply begin adding to it. Note also that we can import our own reset.css here - so we all know that browser defaults are turned off on all projects.

Shared approaches to CSS syntax

Finally, we all approach writing CSS in the same way, in our case single lines for each selector. Not everyone likes to do it the way we do, but we are happy. So, its become a convention, right down to the spaces between rules and brackets.

A reusable package

It pays to develop a base layer of rules and conventions that act as starting points for HTML, CSS, JavaScript and ExpressionEngine for your own projects. Think of it as a bumper compendium of cascading and connected CSS files, naming conventions, modules, plugins and library scripts that ensure any project led or worked on by any member(s) of a team will stay on convention, and be simpler for anyone else to step into and work with at any time. This could include:

  • Basic HTML files & naming conventions
  • CSS: Stylesheets, IE-specific, reset, scratch files.
  • JavaScript: jquery, function file, transparency support
  • PHP for basic templating prior to CMS integration.
  • Other Assets such as set folder names for images and CMS stuff
  • Essential CMS set-up procedures, plugins, modules etc

Constant iterations of the package should be made, and it should be made available internally with a changelog, meaning anyone can use it as a starting point for any projects.

It’s important to constantly consider HTML, CSS, browsers, JavaScript, naming conventions, CMS usage and any improvements in general methods or implementations. My package isn’t publicly available because it is mine - bespoke, custom, built especially for my purposes suiting my needs. If you like the idea and general approach, you’d do worse than to build your own constantly evolving package.

*Note:* Slides designed by Gregory Wood.

Full series…

This article was originally posted on Erskine Labs, September 2009.

Responses

# Dan Griffey responded on 22nd March 2010 with...

Great article - just one question - how come in the ‘Ultimate Package’ there are CSS files in the JS folder?
Thanks!

# Simon Collison responded on 22nd March 2010 with...

@Dan: Oops, I used an early (wrong) Ultimate Package image. I’ll sort that out right away. Glad you appreciated the article.

# Dan Griffey responded on 22nd March 2010 with...

Thanks - that makes a lot of sense.
Nice to start with a framework and hear how other agencies do this.

# Stephanie responded on 22nd March 2010 with...

I really like the idea of a scratch CSS file.  I know my main style sheets inevitably end up cluttered with stuff that has comments reminding me to remove it or optimize it later.  I’m sure it also facilitates collaboration since everyone fears to touch the style sheets and suffer my wrath…

# Nick Toye responded on 22nd March 2010 with...

Good stuff mate.

# Nick Toye responded on 22nd March 2010 with...

By the way, why do you go with a forms only css and not have it integrated within the main css?

# Andi responded on 22nd March 2010 with...

Great article! I got my own little Package i’m starting my projects with…and i recommend this to any webdesigner/developer!

# Simon Collison responded on 22nd March 2010 with...

@Nick: The forms.css is there as a suggestion of how we sometimes separate key ‘blocks’ of CSS into separate sheets. For example, default and general rules might live in screen.css, importing in (for example) forms.css, nav.css, layout.css, microformats.css and so on. I know people who’ve done similar things for years. Depends if it suits your way of working.

These are just suggestions, and we decide on a project-by-project basis if a site demands this kind of separation.

# Nick Toye responded on 22nd March 2010 with...

@Simon, I thought as much.  I remember Andy Budd once talked about multiple CSS files at some talk once in London.

I actually prefer to keep things as simple as possible, I suppose it’s a matter of taste.

I remember somebody’s CSS was split up into about 20 odd sheets, can’t remember who, but it was madness.

# Johan Möller responded on 22nd March 2010 with...

Doesnt this just require more calls and worse site performance? or do you usually compress them into one when done?

# ModeTen responded on 22nd March 2010 with...

For larger projects where multiple team members are working together this invaluable. Particularly if you have a high staff turnover! Smaller sites and agencies may want a lighter set of rules!

Responses are now disabled Your ability to respond is disabled automatically some 30 days after articles are published, or manually much sooner if spamming guttersnipes target a particular article.

Prev 800 Next

Superfluous Aside

Archived in Design & Web, Writing & Speaking

Written in Nottingham

There are 11 responses

External References

Copyright © Mr. Simon Collison 2003-2017. Protected and licensed under a Creative Commons License. Grab the RSS feed

Engineered in Nottingham, scaffolded by ExpressionEngine, steam-pumped by United & kept alive with tea and hugs.