Notes: Please add your name, if you contribute, to the 'Authors' section at the bottom of this file. DO NOT COPY AND PASTE THIS FILE WHOLESALE. IT MAKES IT SLOW. Export it or save it as text. 16/06/2006 13:45 - 14:45 CSS Project Management by Rachel Andrew, Roger Johansson, and Dave Shea RA: Written a number of books, including CSS Anthology. Run a dev agency that builds lots of CSS layouts for people. RJ: 456bereastreet. Work for a Swedish web dev doing CSS work/layouts. DS: CSS Zen Garden, book, Bright Creative. Lots of different clients, lots of problems around this issue. Starting point RJ: Good to establish basic template for documents. Meeans project->project lots of things the same. Change as needed. RA: Have basic frameworks as starting points. DS: Basic set of HTML/CSS copied to new projects. Uses undohtml.css. Remove inconsistencies at the start, gives a good base to work with. Audience: I never start with stylesheets, I start with content I know is going to be there. Markup first, CSS after. DS: I do exactly that, we're talking more about earlier things. I think that's a fundamental point, though: if you do markup first you're starting with a semantic base. Audience: If you're working with coders, you almost _have_ to work that way. Multiple CSS Files DS: How do you break up your CSS? Do you have one big file? Do you have lots of files? RA: I've experimented a lot with breaking things down to typography, colours, etc. I found that it works best to have one big file - excluding hacks: those go in another file. Sites where you have distinct differences are different, though. DS: I advocate breaking out stylesheets for different sections of the site. General file for site-wide components. If you then go to other sections, have seperate, secondary stylesheets for those sections. When things are broken down by section, I know I can go to one sheet for that section rather than hunting in one big file. RJ: I agree more with RA than with DS. I've experimented with splitting up large files into smaller files. As a developer, it's easy to get confused when things are split across multiple files: I need to figure out which files to open for which changes. DS: One thing I found that sold me on breaking up CSS is a legacy issue. If you're taking away a section of the site, it's easier to take away a secondary file for that section than remove rules from a big file because you don't know where else it's used. RJ: Naturally, it depends on the scope of the project: for a huge site, there's a need for that. For a smaller project, there's little need. Audience: I've been using Dreamweaver 8, and that allows you to drill down to a rule, and it'll tell you where that rule is in files. Is there any way other than a huge search? RA: DW8 is helpful but I think you _are_ down to a global search. Audience: I'm also in favour of multiple CSS files in a specific context: if you're using DW in conjunction with Contribute, Contribute gives users access to a CSS file. If you have one large CSS file, they get access to everything. You can, then, configure things so they don't get access to structure. RA: That's sensible: it all comes down to working with others and constraints there. The Human Factor RA: Every group of people is different. It's not so much about fixed methodologies as it is about context: a small site has different needs than a large one. So long as you have something you can then explain, you get most of the way there. RJ: That's one important reason to comment in your files. Anything you do that required some thought should be noted. DS: So basically documentation. I did a redesign of Mozilla.org a while back and I was a Windows user, and they were all Unix geeks… Their editor was different to mine and couldn't understand the tabs from my machine. I ended up having to compact everything down to one line. This was really good until I started working with other people again, who couldnt' understand it. I've since switched back for this reason. Audience: We have an application we then have to brand for customers. We find that our prof. services aren't skilled enough to do that, so we divided it up so that some of the complex rules are in one style sheet, and the other stuff is in another bunch of sheets that are simpler and they can change. We think about who has to maintain a certain set of styles. DS: Yeah, it's definitely about context. Audience: One thing I noticed and that I'm trying to work out with colleagues is a system to have well commented CSS then strip and compact that for release… Do any of the panel know of that? DS: You're getting ahead of us: yes. Audience: Source Control. Where I work, we find source control offers an easy avenue to work with one another. Do any of the panel have any experience with that? If you've a large team, it makes sense to split up by section… RA: Yeah, that certainly makes sense. Even if you decide to join those files after source control, that's good. Comments DS: In my markup, I've taken to commenting where my divs end in HTML with the class or id. It helps deliniate later where things are opening and closing. RJ: Same thing for CSS files. I've started creating table of contents to indicate where things are, along with a trick from Doug Bowman - CSS Flags - where you add a distinct marker to comments within a CSS file. RA: One point to remember is to always, always comment any hacks you use… You'll come back to it and wonder what on earth it was doing. Stick the URL in there, so you can see if it's still relevant. DS: I've started commenting using lots of tab characters to right-align my headings, so that I can scroll down and quickly see where major sections are. Audience: We ask our developers to enter initials and date that they made the change. There'll be times when you'll see something and everyone's forgotten who did it, and it lets us pick that person's brain. Or we'll find a fix and then find that we can update that later. Audience: I've gotten into a habit of putting, at the head of the CSS file, a list of the colours I'm using throughout the file. If, later, they want to change the colours I know what's there. Audience: In CVS, you can comment and it keeps track of what was updated. The comments, though, can be problematic. class/id Naming Conventions RJ: Apart from keeping it structural, and trying to name things what they are and do, it doesn't matter, so long as you stick to your rules. Then you don't need to struggle to recall what does what later. RA: It doesn't matter much what you use, it's all about consistency. Avoid presentational names, obviously, but don't worry too much as long as you're consistent. DS: John Allsop, then Google, did 'surveys' of the net to find common naming. I find microformats and naming conventions in templates interesting. THe problem, of course, would be everyone agreeing to come up with a system, but that's not likely. Audience: You mentioned Yahoo… As well as what you see in the UI libraries, we have things we use internally. If you look at a given classname or property, they have prefixes for different areas. That way, if you're pulling things from two places, you know they won't clash. Audience: I was gonna ask about standard naming… You and Doug Bowman swapped designs a while back… Did that stuff help? DS: There was lots of work there, we didn't have that naming convention, but it would have helped. RJ: If everybody used the same naming, it could be useful for accessibility too: they could make every site look the same and make it right for their needs. Audience: I was wondering if you have any recommendations for casing for naming… Pascal, Camel, lowercase,…? RJ: All lowercase, dashes to seperate. DS: Same RA: I used to use Camel, but they had to remember capitalisation, so I moved ot all lowercase. Server-side Script + CSS RA: I've done some autogeneration of CSS files, but not much. I think going back to the comment removal I think that would be pretty simple with RegEx. DS: Automation of comment removal/compression would be good. INman came up with something that allows you to define a constant and then use it elsewhere in your CSS. Audience: One of the things we do is point styles.css to a bunch of dynamically generated @imports based on the user. Audience: We're expected to do similar to Inman's constants. This then gives people the ability to change colours easily. Audience: Just a quick warning: we've run into issues with caching… Code Order RA: I tend to start with wrapper, then header, then stuff in that. Occassionally, I'll have a seperate file with generic stuff in. DS: If I had to say one style was dominant, I'd say linear top-bottom structure is. That doesn't really work well, though, because you have lots of different styles. Make sure you've got things in some sense that works for you. RJ: I try to start with undohtml.css, then any generic style for different elements, then get into page sections. Within each rule, I try to stick to predefined property order. Audience: I work in a team of about 25. Being the lone CSS guy is hard. Ctrl-F is the easiest way to find anything. Other stuff tends not to work. RJ: The problem, though, is that order can make a difference. If order overrides something, it's difficult to trace that. DS: Yeah, I try to keep conflicting things close to one another. It doesn't always work that way, though, because other conventions conflict and override this. Audience: I find I do all CSS by elements. If I'm changing classes, all h2s are together, so it's easier to find. RA: It is very much about just coming to your own method. Tools DS: Editor-wise, BBEdit. I hear TextMate is good. RJ: I've been using BBEdit for 12 years, I also hear TextMate is great. DS: There are also very specific CSS editors for Windows - TopStyle, StyleMaster. What about DreamWeaver? RA: I don't use DreamWeaver much, working on Linux. My main editor is …. I Use Firefox web developer toolbar most. DS: I use XyleScope, which is like the web dev toolbar on Safari. Audience: I use a program called EditPlus, but I was disappointed to discover VS2k5 has excellent support for it. Testing RA: I have lots of computers. Being Linux based, we also need Macs and Windows boxes around. Browsercam is also good because you can login using VNC. RJ: I'm a Mac user, so I just have lots of Virtual PCs. DS: But VPC sucks… I want an Intel Mac so I can run Windows natively. -------------------------------- Authors: Steve Marshall: http://nascentguruism.com/