Hi all 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. http://www.contentwithstyle.co.uk/Articles/12/modular-css/ http://www.contentwithstyle.co.uk/Articles/17/a-css-framework/ I've been meaning to write a bit more about this for a while but I just didn't get around to it... Cheers Mike web developer | designer www.donotremove.co.uk www.contentwithstyle.co.uk >----- 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/ > >archive/2005/09/26/maintainability > > > >If anyone has any ideas to share, particularly from tackling this > >problem in team projects, I'd love to hear them. > > > >Thanks! > > > >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 > coding. > > 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 > (i.e., css, html, php, perl,javascript, etc.) within the same > 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: > > http://www.sperling.com/examples/pcss/ > > 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 > documentation. > > tedd > ______________________________________________________________________ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
