CSS Project Management ====================== Dave Shea, Roger Johansson, Rachel Andrew CSS project management is something we've all struggled with. Not going to sit up here as experts and say "this is what you should do". It's all about finding methods that work for you. Rachel - runs edgeofmyseat.com - build a lot of css layouts that other people will be using. Roger - 456bereastreet.com, small swedish web agency, hoping to learn from this myself Dave - made csszengarden, run an agency in Canada Starting Point? --------------- Where do you start? [Roger] really good thing to try to establish a basic template for your html document and css style. From project to project a lot of things will be the same. Start with a basic template... [Rachel] we have a set of basic starting points, frameworks, keeps you organised, things are named the same, over time you start to rationalise, you know your basic framework works [Dave] I have a basic set of documents - copy that into every project, doctype, starting html, css is setup in a similar way. One thing I start every project with is undohtml.css - it's a very basic set of rules that zaps all the browser default rules - gets rid of inconsistencies from the start. Added a few things, taken away a few things. Can cut and paste it into every new project. [audience] start with content and from there style it up. start on lower page rather than homepage. [dave] yep - right my markup first, write your document first, otherwise you get in a presentation mode of thinking. [audience] related to that - working in a team where the markup is generated by an app, that's the way you have to work Multiple CSS Files ------------------ How do you break up your css files? [ra] experimented with this in terms of what you can do, typography in one or colors in another. Works best to have most things in one css file - the only thing I take out is to move hacks into a seperate file. Exception maybe if there's a site with a section that is very different - so they're not loaded on every page on the site [d] in my original presentation I advocate breaking up into sections, start with a global stylesheet, then when you get to a section you can pull out a separate stylesheet. When it's broken out by section, there's a lot less to wade through when you come back to it - 25 lines instead of 4-500. Even with caching, a 40k CSS file is still a 40k css file [ro] agree more with rachel than dave. Tried experimenting with splitting large files up - benefit for visitor is a smaller file, but as a developer it's more confusing with multiple files. [d] tools that help you find the style rule. one thing that really sold me is the legacy issue - when you're taking away sections of the site, you don't necessarily take away the CSS for it - "I can't remember if we use that". Never had this problem with tables based layouts. Centralising CSS - so have new problem of legacy CSS. Something I've been dealing with recently, have had 1000's of lines of css in one file, go in, add a little at the end, get out as quickly as possible. [ra] depends on scope of project and how large it is [d] 10 pages, a totally different matter. sun.com had 37million pages, didn't work for them. [a] used dreamweaver 8 you can select an element and find the style rule [a] in favour of multiple css files - using dreamweaver with contribute, they get access to the css file. The Human Factor ---------------- working with other people [ra] every project is different, every group of people is different, isn't so much about fixed methodologies, 10 page site, put it all in one stylesheet. [ro] try to comment clearly [d] documentation. about 2-3 years ago, did a redesign of mozilla.org, I was a windows user, when I gave them the CSS they took it and edited it, had problems with the tabs I was using, took the tabs out, started doing a thing where all my css rules where on one line. Used that for a few years, not as much vertical scrolling, loved it. Then started working with other users, look at books, there's a classical format for css, switched back to that because it's more readable. [a] standard app, brand it for customers, professional services people not necessarily skilled in css. We've divided up the style - more complex stuff in one file, and simpler stuff in another. Bit like the contribute example. [a] one of the things we're trying to work out with our colleagues is well commented css, that is then compacted. [a] source control - perforce or source safe, provides an easy avenue for documenting changes, almost have to use separate files for separate sections so people don't overwrite each others changes. [ra] yes, even if you're going to rationalise it before launch Comments -------- [d] - in markup - in tables you used to have to count, with div's i'm starting to hit those same levels, i've began commenting where my div ends - commented by class or id. [ro] started putting a table of contents in a CSS file. Combine with "CSS flags" - markup the section of the CSS file with a comment with an equals sign before it so you can quickly find it. [ra] comment your hacks - when you come back to it, add the url to the page you found the fix on, seen so many stylesheets full of hacks and you have no idea why they're used. [d] have all this whitespace on the right hand save - move the start of the comment over to the right. Not convinced its great, new thing, seems to work pretty well for me. [a] have many people contributing everyone adds who made the change and when - gives you a chance to go back and ask them why. Often find a new fix, and go back and find new things. [a] at the very head of the css file, pull out list of colors I'm using, so if they decide they want to change one of the colors. [a] you can comment in CVS what's changed, but it doesn't work in CSS. Class/ID Naming Conventions --------------------------- [ro] keep it structural, come up with something that works and stick with it, is it a div, container or wrapper. Do it the same from project to project then you know what things are. [ra] being consistent is more important that the names themselves. Don't need to worry to much about it. [d] John Alsopp ran a survey, then google queried a billions sites. Yahoo have a standard in their YUI library. Common names for elements - could have standard blog templates with different styles. Never going to be standardised. [me] (blathering about yahoo) [a] when dave and doug did a swap did a standardised name help? [d] standardising on naming helps, but possibly not worth it for a practical joke [ro] standardised naming would help with user stylesheets? [a] lowercase, pascalcase? [ro] tend to use all lowercase, dashes to seperate words [d] i do that too [ra] used camel case, reverted to all lowercase [d] problem with camelcase, it becomes quite personal Server-side script + CSS ------------------------ [ro] - none [ra] - done a little bit of generating css with php, not seen anything that removes comments, would be good. [d] Shaun Inman came up with server side constants - define a css color at the top, then use it throughout the css file. (missed some questions) [a] caching? [d] have to make sure your css file is being cached - php there's some flags to turn on Code Order ---------- [ra] tend to be fairly structured about it, break it down with comments, be organised so people can find the section - header, sidebar, etc. Avoid temptation to just put things at the bottom of the file. [d] what people do on the zen garden doesn't apply in real life, predominant style is from top of page to bottom. Can't really do that on a huge site, which is non-linear. If you're splitting your files out by section then it doesn't really matter [ro] (...) be consistent [d] I'm not consistent at all [a] work with a large team of developers, ctrl-f becomes the fastest way to find anything. Being too controlling about your css orders. [ro] order can make a difference [d] specificity can be a problem - try to put things that have close specificity as close as possible so I can see them all together. That's the ideal, never happens for me :) [a] I put all the h2's together, tend to use ids [ra] coming to your own method, one that works well, just need to work with things that work well Tools ----- [d] fan of bbedit, hear textmate is pretty good [ro] been using bbedit for 12 years, only for us mac users [d] topstyle and stylemaster for windows. skedit that jon hicks swears by [ra] use (something studio) because it's on linux. Firefox web developer toolbar. [d] Telescope for mac os, does a lot that the firefox toolbar does [a] edit plus, but i was disappointed to find that visual studio has great css support Testing ------- [ra] I just have a lot of computers, being linux based in the office, have mac and windows based computers. Use browser cam, screenshots and vnc, just like having lots of computers if your working with javascript. [ro] mac user, virtual pc, can check just about any browser [d] virtual pc sucks, want to just run windows natively.