Approaching CSS management on large-scale web projects
A nice set of documents
At the beginning of a large-scale web design project, if you're lucky, you'll be given a set of designs and a functional specification, describing how the website you are to build will look and what it will do.
If you're really lucky, you'll get a style guide, that will outline in pixel detail how elements should look and their relationship to other elements.
Given this set of documents, the CSS developer's job is then to mark up the different page templates so that they conform to the design, with neat semantic HTML and ordered CSS that keeps the coherence the designer intended in the design.
Any Interface (or Front-End or Clientside) Developer who has worked on a larger site, with templates that number in the tens (for enquiry forms, site maps, product pages, overview pages, hub pages, articles and so on) will find that it's quite a task leaping in and 'just getting on with it'.
The Interface Developer needs to analyse the proposed site for visual trends and sort the layouts and elements into a semantic outline with a cascade of style inheritance. This has been, in my experience, an informal, heuristic process, often a sole endeavour and rarely with any formal procedure for doing this and not necessarily documented: the CSS itself serves as documentation.
What's needed is a formalisation of this process, in terms of both the methods and methodology used in coming up with decisions as to how to create a hierarchy and cascade and also in terms of documentation for this.
CSS Systems Analysis
CSS Systems Analysis would not be Systems Analysis in it's strictest sense, but the aims would be similar:
- To reduce the time taken in creating code, as the code will take on a modularity so can be more easily split amongst coders of a lower skill level, without fear of them stepping on each others toes, or reinventing the wheel on every page.
- To reduce the amount of time taken in fixing bugs, as a formalisation will lead to structured, as opposed to ad-hoc testing of a coder's own code, and as modularity will reduce the risk of high level changes having cascade effects.
- To ease maintenance as there will be better documentation and a greater ability to make changes at a high specificity without affecting other areas.
