8 Golden Rules of Writing CSS

• Tweet

• Tweet

Update: added 1 more rule.

CSS is not hard to learn yet tricky to master. What differentiates a veteran from a bunch of rookies is scale. The C language isn’t that sophisticated to crack — though still need quite a few months to get through the core and be properly trained — but there’s apparently huge gap between a 10-year C developer and one who’s just been doing stuff for 5 years. 5 years is hell of a long time for any language or technology. Anyone with an average brain can learn anything quite well given that much time in study and practice. But there’s always always a little more.

The road goes ever on and on.

— J.R.R. Tolkien

You know everything the C language offers and have a good command of all the features. You are also well educated in algorithms, software engineering and project management. Now you graduated after 4 years of respectable training in C. However can you write another Linux from scratch as Linus Torvalds did? No you can’t. So what separates him from you?

Scale.

These 10 rules below apply effectively in large projects consisting of tens of thousands of CSS rules. However you may benefit equally from them on relatively small projects.

1. Provide as less presentational information as possible.
   1. Keep only absolutely necessary styling rules and eliminate any that doesn’t exist for a solid reason. Redundant styling makes it a nightmare to debug in large projects.
   2. Let the browsers (computer) do the math for you, you just provide them with initial layout parameters such as width. If you find yourself doing arithmetic calculations about width, padding and border over and over, you are doing it wrong. Although it may appear all right at first, it will take considerable amount of time to alter the layout later simply because you have more than 1 places to take care of.
   3. Take height out of any element containing text inside.
   4. Redundant coding is the easiest way to bugs.
2. Keep track of everything you have done along the way.This includes how you have done the layout, what positioning techniques you have used and where. Inspect your styling every 500 rules to make sure you have a clear framework of what you are doing in the mind.When you look at the work in browsers, you know all the things you have put up together don’t come in a haphazard way but well organized and can be altered in whatever way you want anytime. It’s a state of mind that’s in control.If you find a problem solution after hours of blind struggle without knowing why or thinking that there’s no need to do that and move on, you will be in big trouble very soon.
3. Logically group your rules. I group rules in the order:
   • general styles (mostly in tag names)
     • reset
     • links
     • headings
     • inline tags
     • general form styles
     • other elements & tags
   • page layout & structure (mostly in id)
     • body styles
     • layout divisions
     • layout positioning
   • helper styles (mostly in class, named after the effect they create)
     • errors
     • notifications
     • specific button style and so forth
   • cross-page components (class or id, named after the component function)
     • most of your styles go here
   • page-specific components (same as above)
     • most of your styles go here
   • components positioning
     • cross-page or site-wide positioning
     • page-specific positioning
   • overrides
     • cross-page or site-wide override
     • page-specific override

   This is a component oriented styling structure. Alternatives always exist for different situations, such as helper style oriented styling structure.

   If the logic flow goes rather lengthy, create separate CSS files to accommodate them, logically.

4. Hacks are ok but if you find yourself abusively using them to adapt the styles to IE or any other browser, you might be doing it wrong in the first place. It’s totally possible to do things without any hacks at all especially simple undertakings but with a few unpleasant compromises.
5. For any styling component, separate its positioning styles (styles that prescribes how the component interacts with its environment) and its inherent styles (styles that the component bears wherever it goes on the page or when it’s moved to another page).
6. Reduce the length and levels of any selector wherever possible. If you don’t care about it in a large project, chances are as you write along, the length and levels of selectors will grow until you have a lot of !important here and there and you still have to keep growing them if the work goes on. That’s not a pretty sight.
7. Code simplicity is the enemy of modularization. Choose your clan wisely.
8. Cascading is your dear dear friend. Cascade it for the sake of coding ease and elegant style structure!
9. Float and Position: Avoid, if at all possible. Think twice before floating any element or make it positioned relatively or absolutely, is it REALLY necessary?

Well actually I have much more coming trivial tips just they don’t fit in the macro style I’ve laid from the beginning of this post. As many languages and software engineering itself does, CSS should nurture its own building patterns to adapt to different situations and solve specific engineering problems.