How to write CSS for a dynamic site

I have done my share of custom facelifts for Webcrossing sites.  Webcrossing is (justifiably) known for being extremely customizable, and many customers are excited that they can pretty much design what they want.

What this means in practical terms is:

1. Customer contracts with web design firm to design the site
2. Designer designs something awesome
3. HTML/CSS jockey translates that vision into actual HTML and CSS, typically creating at most a handful of critical representative pages to be used as style examples for all other pages
4. HTML/CSS is handed over to us to integrate into Webcrossing
5. We carve it up into pieces corresponding to the built in functions we want to override, and new functions we need, and set about making it dynamic

"Dynamic" is, of course, the operative word here.  Dynamic means that you have to be prepared for anything. Titles may not be same length as in the jpeg mockups from the designers, numbers might have any number of digits, usernames might be unreasonably long, and users may not have used semantic or even halfway correct HTML in their posts. Besides those issues, there are large chunks of UI (that you've probably never seen) that have to look nice, but which will not specifically be styled by your shiny new CSS.

What's a CSS-ologist to do?

Fear not. Here are my suggestions for writing CSS for a dynamic site, gleaned from experience with various integration projects:

1. It seems obvious, but from my experience I guess it isn't: Don't assume (unless you have asked and received confirmation) that any bit of user-provided text or other dynamic values (usernames, post view counts, posts, user bio material, etc.), are going to be exactly the same length. Provide a way for either graceful expansion or graceful truncation.
2. Remember that the site will have large chunks of UI and lots of pages which are controlled by your CSS but which you aren't styling directly. In other words, try to ensure that the default font size is reasonable, that the default styling for lists is reasonable, that headings and their various margin and padding values are OK without specific styles being applied to them, and that user-generated HTML looks presentable as is.
3. Be careful with "reset" CSS. It is undeniably useful, but it may remove defaults like required table borders or destroy the look of lists on existing pages that were not scheduled to be reworked.
4. Don't write your selectors in a way that various styles can't easily be re-used elsewhere on the site on pages you haven't specifically styled. For example:
   
   #banner .nav-links ul#sub-navigation { ... }
   
   is impossible to reuse anywhere except on a <ul> with an id=sub-navigation inside the banner and inside the nav-links class within the banner. So if I want to re-use that look elsewhere on a <ul>, guess what, I have to rewrite some CSS. 
5. Don't make containers a fixed height if you aren't sure what is going to go in them. 
6. Be careful with fixed widths on containers if they might be re-used elsewhere.
7. If the site has user-provided photos or avatars, don't assume they will always be a certain size or even that they are all the same size.  At least inquire what the status is of current user photos and what the site owners' plans are going forward. Will they all be replaced with images of the correct new dimensions? Or are you obligated to attempt to provide a way for old avatars to still look OK even if they are 100 wide by 200 tall and the space you have allocated is 150 by 150.
8. If you use sprites for icons, leave enough vertical space between icons in the sprite file so if the title next to which the icon sits wraps to two or even three lines, you won't have stray icons appearing on lines 2 and following.  If you don't, I have to break out that icon into a separate file and then call that individual icon in the CSS instead of the sprite file, which obviously defeats the purpose. Or alternatively, using Photoshop, I have to move around the icons in the sprite file and then rewrite a bunch of CSS sprite background positioning rules to adjust for that.  And that is unlikely to happen, honestly. 
9. On a site where users are allowed to post HTML, don't surround user post bodies with <p>...</p> tags.  That page's HTML will not be anywhere near valid if the user puts headings, divs, tables, etc. inside those measly paragraph tags.  Make a nice div instead to surround your user post bodies, so users can put whatever they want to inside there. 

If the HTML and CSS experts are aware of the issues involved with designing a dynamic site, the customer can probably save some money on integration costs because there is less re-working of the CSS after the fact.