I favour breaking the CSS down into manageable pieces. When I've worked in
teams before that's enabled people to start with the same base and work on
their own parts of the project without overlapping. By that I mean a set
of common stylesheets @imported with page/section specific sheet(s) that
can be worked on indepentently. The small sheets have a defined purpose
and can be easily digested, requiring less orientation. This still doesn't
get around inheritance though.... That's a tricky one.
I'm not sure reams of documentation are the answer though... Programmers
hate documentation. How many people ever read it? How many people know how
to write it well? The number of times I've come to comments in code that
bear no relevance to the code itself because a developer's decided to come
back to it later... I tend to over-specify my rules to make the code as
self-documenting as possible. Classes and ids aren't orphaned (div#content
instead of #content) and as much of the path is specified as possible
(div#content div.promo instead of just div.promo). It can make for heavier
code but far better maintanability... I also use consistent naming
conventions to help orientation as well.
I wrote something about this a while back, although it was aimed at the
other end of the market - high turnover, small projects. Some of the
suggestions may still apply though.
I've been meaning to write a bit more about this for a while but I just
didn't get around to it...
web developer | designer
>----- Original Message -----
> >Hi all,
> >I'm interested in gathering advice on keeping large stylesheets
> >maintainable, particularly ones that have more than one person
> >working on them. I think that this is an area of CSS that has not
> >been adequately discussed in the past.
> >I've written more about this on my blog: http://simon.incutio.com/
> >If anyone has any ideas to share, particularly from tackling this
> >problem in team projects, I'd love to hear them.
> >Simon Willison
> Hi Simon:
> In trying to tackle css maintainability, I think you've just
> scratched the surface on the problem of maintainability any web
> As I have always said, css is not a language that lives in a vacuum.
> In fact, it can't do very much by itself -- it has to be used by
> other languages to accomplish anything worthwhile.
> Furthermore, one can jump-into and out-of several different languages
> document to make a single presentation. For example, please review my
> simple solution of how to use a php variable within a css style sheet:
> Because of a diverse focus, all the web languages leave a lot to be
> desired when it comes to maintainability. I believe that this stems
> from the fact that all web languages trying to accomplish a single
> task, which is to deliver a presentation. Unfortunately, no one
> language does it all, but instead requires a symbiotic dependence on
> others. As such, it is going to be difficult to define a set of
> techniques for maintaining styesheets without considering the larger
> picture. It's like trying to maintain a specific custom from within a
> larger diverse society.
> So, if your goal is to set a standard for maintainability, then this
> standard should also consider the maintainability problems, and
> solutions, of other interdependent web languages.
> As for me, my "maintainability solution" has always been -- abundant
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/