CSS Filter: making tight CSS files, style guides and learning best practices – help needed.

March 9, 2007 5:32 PM

CSS Filter: making tight CSS files, style guides and learning best practices – help needed.

My fellow CSS enthusiasts,

Here’s me with another ‘what’s the best way to do this’ or ‘is there a template for this’ type questions – it’s my curse in life to ask these! Basically I’d like to hear what folks do for best practices in CSS design (both layout and formatting). I'm not a full time coder - just someone very interested in the topic, and I’m trying to get my stuff looking more professional and to work even better, and think maybe marking up the, err, markup might help. So I have a multi part question:

- style guides: any good examples you’ve found. I’ve seen some examples here (a visual one, from Stuff and Nonsense and one over at Dave Shea’s site). Any other good examples you’ve used or created? I’d like, of course, to find a template to speed up annotating these. If you have style guides in general (HTML or anything else – doesn’t have to be CSS) please send them here as well. If you have other things you do besides an actual style guide, tips etc. share those as well, if you can.

- standards: other than creating accessible, compliant designs that satisfy the Validator (the evil W3 corrections site), what do you do to make your code more professional? I split up the layout from the formatting, but would like to know things that help make me a better designer – i.e. do you put things in a certain order in the stylesheet, etc. I know you combine selectors wherever possible – I’m looking for those kind of best practices or standards if you’ve got them. Any recommendations for favourite books, sites and blogs etc. for advanced designing in CSS are always appreciated. There are a slew of them, and I’m looking for good quality stuff – kind of like ‘practical CSS Zen Garden’ type resources. It’s one thing to actually view source – it’s another find someone talking about the source, which I find also helpful.

(I’d ask this over at a CSS forum like CSS Creator but I likes my MeFis, know some of you are designers and know that this is probably a better place for meta discussions of design, best practices, etc. – although if you know of a better forum, let me know that too).

thank you!

posted by rmm to computers & internet (13 comments total)

i learned using glish.
posted by phaedon at 5:40 PM on March 9, 2007

(a more direct link. my bad.)
posted by phaedon at 5:51 PM on March 9, 2007

I don't have any single guide I prefer but if you'd like you can join us on IRC. #web on freenode is the best chan I've found for discussing web dev. It has a high emphasis on standards, accessibility, usability and universality. There's also a specific #css chan but I find #web more responsive.
posted by sipher at 7:27 PM on March 9, 2007

Ugh, I do CSS all day, every day, and I'm not entirely sure it's possible to really get it all properly organized.

But mainly, I would say the best tip for having neat CSS is to start with the page already mocked up in some other format. That could be a Photoshop image of what the page looks like, or a Visio wireframe mockup, or just a sketch on a napkin, but you really need to know what's on the page before you even sit down to transfer it into HTML. It takes far, far longer to maintain your stylesheet if you add something in at the last minute than if you just planned for it in advance.

For myself, I generally break the sheet up into page sections, most often based on the ID of a div. I'll put that ID at the top, then alphabetically organize the selectors that either inherit some rules from that div, or which only (or mainly) get used in that div underneath it. Sections get comment-separated with a nice big divider. It's also nice to put some keywords about the likely contents of that div in the comment, so that I can do a keyword search and find them. The obvious way to organize sections is from top-bottom, left-right as they will be displayed on the page, if you know this information.

Just as a matter of esthetics, if I have some selector with only one rule in it, I keep it on its own line, but if it's got 2 or more, I expand it like so:

.awesome
{
margin:1em;
color:orange;
}

I put the brackets on their own lines because it makes it easier for me to read them (some do without these line breaks). I do not indent the rules because I rely so heavily on Web Developer Toolbar's inline CSS editor, which doesn't recognize tabs, and has to fit in a very narrow space.

If you use sibling or child selectors, definitely comment them heavily, because they're harder to read at a glance, and someday someone will want to know what span > p.awesome + input + input + span + input is referring to. On the whole it's better to use another class in absurd cases like this, but sometimes making another class just seems like the coward's way out.

Another good way to be organized is to split your CSS into different files based on the rules it contains. For instance, but all your layout rules in one file called layout.css, all your colors in colors.css, all your typography in fonts.css, etc. Then you at least know where you've put it.

I usually also make sections (if not specific .css files) for a couple other categories: global classes and hacks. The latter is self-explanatory and, sadly, entirely necessary. The former has things like .floatLeft and .alignRight, which I end up using a lot.

The most important thing is to start with good mockups though.
posted by Hildago at 7:52 PM on March 9, 2007

good suggestions so far. also, get firebug installed asap in firefox. it's the best css dev tool on the planet. Too many reasons to explain here -- just install it, right click on something and select "inspect element," and you'll see why.

style guids: no, i have nothing to recommend. that's because everyone has a different style and thanks to the world of blogs everyone announces theirs as the "right" way. i personally find the division of layout and style in CSS unnecessary and frustrating. others separate their entire stylesheets into structure/design/typography divisions. i do mine as a logical layer cake. first comes the global declarations (resets like img border: 0, a trusty div.clearer), then the body and #main styles, and so on.
posted by Señor Pantalones at 8:51 PM on March 9, 2007

Global White Space Reset to reduce cross-browser issues.
Undoing html.css and using debug scaffolding
Browser testing CSS and JavaScript
posted by kirkaracha at 9:56 PM on March 9, 2007

Why the attitude toward the validator?

>the Validator (the evil W3 corrections site)

It's not your enemy, you know!

I don't particularly care whether someone has separated layout and appearance, and it's not always possible anyway.

One thing that drives me crazy is people creating class and id names which are doomed to become meaningless, like "pinkoutline" or "bluebar" or whatever. The moment someone decides it's not to be pink any more, the stylesheet just got harder to understand.

As long as you're consistent and make helpful comments, I don't think there are any other particular "best practices" you need to worry about.
posted by AmbroseChapel at 10:05 PM on March 9, 2007

i.e. do you put things in a certain order in the stylesheet, etc.

Yes, but this isn't because of best-practices, it's because the definitions further down on the style sheet take precedence over definitions above them. This can lead to all kinds of confusing errors where an element's style definition is being overridden and you don't even realize it.

FWIW, FireBug is indispensable at revealing what properties are being overridden in an element's style. It's the single best tool for any and all web design that I've ever seen.
posted by Civil_Disobedient at 12:06 AM on March 10, 2007

There's a nice page called Maintainable CSS with great bits culled from all sorts of sources over at css-discuss.
posted by braintoast at 12:50 AM on March 10, 2007

Firebug & Web Developer for Firefox are a must.

I usually break up sections of a large site into their own stylesheets so you don't load unused styles on certain sections, and b/c it's easier to find related styles.
posted by hobbes8calvin at 2:23 AM on March 10, 2007

Yes, Firebug. The best client-side web development tool to come along in ages, for CSS and a bunch of other uses, as well. Hildago's advice is spot on. The more is known up-front, the more you understand the final product desired, the more painless things will be. True of any development project, of course, and not always possible for every project. Given that, my approach is generally about keeping things findable, readable and maintainable.

That said, CSS is not a perfect technology. Unintuitive behaviors and browser inconsistencies are almost guaranteed with every project. Here's some things I do to try and keep things straight:

* Liberal use of whitespace in the CSS and markup files make them easier to scan and find items once they grow.

* There's differing opinions on it, but I like to indent CSS statements to reflect the same level of nesting in the markup they apply to.

* You can combine selectors, but sometimes I don't for readability and maintenance reasons - no shame in that and you're not going to take a noticeable performance hit if you don't.

* Using IDs as selectors is often over-used. There are often other ways to reach a node in the mark-up. IDs introduce more naming and maintenance issues that might cause grief in change management. If an ID is unavaoidable - needed by a script, perhaps - then might as well go ahead and use it, however.

* As far as reasonable, I like to keep CSS statements in the CSS file in the same order as the markup appears in the markup file(s). Again, making scanning and searching easier.

* Never, ever use style attributes within the markup, but you probably already know that...

* Try as far as possible to avoid hacks - they're potential time-bombs waiting to trip us up when browsers change in the future. It's almost always a case of IE vs. browsers that aren't crap, so I like to maintain a separate IE-only CSS file, containing only the crud necessary to make IE behave, that's loaded by a conditional comment in the document head. If IE ever starts working properly, it's then just one file to delete.

* If a hack is unavoidable, put it in its own file as well.

* At the top of the main CSS file, declare all the non-uniquely-identified block-level elements you're using in a combined selector and set margin: 0px and padding: 0px, so you're starting with a level playing-field, not different browser defaults. Some like to do this with body * or the * html hack, but I'd rather declare explicitly, forcing me to think about the specific elements in use.
posted by normy at 9:02 AM on March 10, 2007

wow, no way I'm going to mark a best answer here - learned something from everyone's post, as I thought I would :)

Hildago, I too split up my selectors onto 2 lines, at least when starting out. I'm not sure about the splitting CSS into separate files - isn't it easier just to comment in them? I've heard having one global stylesheet and then several subsection stylesheets (and also any for specific media) works (what hobbes8calvin mentioned), but don't know about putting each separate kind of CSS (layout, formatting etc.) into separate files. I suppose each to his/her own.

Civil_Disobedient, point well noted re: elements taking presidence. That goes without saying, but I probably should have said that ;)

AmbroseChapel, I have a love/hate thing towards that Validator. I love accessible design, and seeing a beautiful design down by CSS makes me very happy. I can appreciate good code as a thing of beauty - but sometimes I feel like I have to wrestle with my code enough and Mr. Validator is never happy. Hopefully that will change when I just find a developer to help me ;) And yes, the whole 'name things after their colours' thing is very annoying - I try to borrow from the world of newspaper style guides wherever (i.e. 'masthead', 'img', 'pullquote' etc. etc.)

Looks like I'm going to try doing a code mockup of divs etc. with a visual mockup; since I do wireframes for a living it's just one more little thing to do, and heck, anything to convince people that wireframes are worth doing :)

Anyway, thanks so much everyone - wealth of material. MeFites never disappoint. You guys and gals rock.
posted by rmm at 1:31 PM on March 10, 2007

Take a look at Yahoo's fonts.css and reset.css. They normalize default HTML rendering across browsers, so you wont have to bother with it.
posted by cheerleaders_to_your_funeral at 3:29 PM on March 10, 2007