I now group related properties on the same line, especially position-left-top; width-height; I then sort everything alphabetically. I find this makes the scanning simpler when navigating styles.

#example{
position:value; top:value; left:value;
width:value; height:value;
}

I do think the catagory ordering could be useful, especially for font styling and I’ll have to see how that works out in my next project.

Also using 2 spaces for tabbing is nice too when I start getting into more complex designs

I’d rather opt for as short selectors as possible and comment my code sections appropriately to quickly find which selector represents what.

Documentation of CSS file.doc

this is the way i manage my css file…& i have been succesfully used this over more than 50 projects

http://surajnaikin.blogspot.com/2008/07/how-to-manage-your-style-sheet.html

‘I always start with box layout, and then complete the same rules with typography information afterwards.’ – so let me get this straight. you will have your universal h1, h2, h3… p typographical elements defined and then you’ll target h3’s and p’s (and whatever) in their native divs to give them extra styling, where appropriate?

up until now i’ve really done my best to stick with my universal styles, but now i’m finding myself needing more than six-odd fonts per page, so am beginning to embrace semantic conventions e.g. a date font might be styled as .date{…}

i’m toying with the idea of posting a blog entry in the hope of getting some email advice;

‘to use semantic id’s sitewide (and have to name stuff all over the place), or use reusable classes’ – what’s your take?

cheers emil. big aid.

@lewis litanzios: Great comment, thanks! I can see how people want to work with different sections at different times, but that’s not how I work. I always start with box layout, and then complete the same rules with typography information afterwards. Works well for me.

I’ve actually never used a CSS Formater, but then again, I’m _very_ picky about what CSS i write, and it’s almost always already optimized when I first write it.

one downside to splitting this info up into dedicated sections is you often find your self writing the selectors two or three times in different sections when you could, in theory, just include all properties under one selector in one place.

breaking things up has far more benefits though. for instance you can sit down and concentrate specifically on the typography for instance (although in my next project i’ll be deciding upon my type before i do any layout). it’s far to easy to become a whore to type once the layout is all done and dusted.

think i agree on the full path issue; i’ll be implementing that in my next project. look at it this way, if you do use full paths it ties in with the alphabetical approach nicely.

not sure about the indentation thing, but nevertheless interesting. i’m one of those people that uses ‘the least human readable approach’, in one liners, for my css presentation. my justification is it’s less scrolling down to get to what you want; once there you can obvious format it how you like when/if editing it.

i’m a big fan of CSS Formatter and Optimiser (http://tinyurl.com/2vpxfe) and use it at the end of every project to tidy things up, group selectors, shorten property values (hex colours, shorthand padding/margins etc) and generally get a nudge in the write direction for how i could make things a bit tighter in the next project.

my 3 cents :)

cheers emil!

The problem is if you use server side includes (e.g. PHP) and have the page header (with the opening *and* closing HEAD tags ), you will include the exact same CSS files for every page.

E.g. I include this on top of every page:

 CSS 

/* all css files included here */

<!-- menu -->
 <a href="#" rel="nofollow"> Home </a>
 <a href="#" rel="nofollow"> Other Page</a>

That problem can be solved with a very messy and misguided solution – conditional if statements that test for the name of each page and include accordingly.

The better way would be to use an MVC framework or plain Object Oriented PHP for a far more elegant solution.