I am doing a Saas project, and we want each customer to be able to upload a css page for "his" web site. (Although actually, all of the customer's sites are hosted by us using virtual hosting).
What are good guidelines when designing the html of a page so that css can be applied a posteriori.
Don't do it.
The customers will screw the design and will be calling you to reset it for them.
Better make a BIG customization section with LOTS of options that would only produce valid values. Allow images to be uploaded, check their size limits at the submission.
A custom CSS may also be a source of attacks. We talked about it yesterday.
Is it safe to allow users to edit css?
Anyway, this kind of customization can only be performed for relatively simple pages, before all, just the pages. We are talking here about a SaaS application which usually has a terribly complex UI trying to mimic classic desktop software. I doubt customers will be able to correctly customize a respectively complex CSS. Well, not without hiring a professional programmer that will be calling you back all the time to clear up things. It will be easier to simply offer an advanced settings screen.
You can have a look at the code at CSS Zen Garden, it's specifically designed to be stylable.
Generally, you should just use the most natural HTML elements for the function you want. Lists should be lists, links for navigation, et.c.
Use div tags to separate the contents in logical divisions To make elements easy to target, set appropriate classes and id's on them.
To make links really stylable you can simply add a span tag around the text:
<a href="#"><span>text</span></a>
This way it's easy to give it a dynamic button like look by using the "sliding doors" technique, by adding one background to the anchor tag and another to the span tag. If the link is not styled, the span tag is not affecting the layout at all.
Some might be blatantly obvious:
Name all your classes, IDs with a consistent and obvious naming scheme, but don't go naming everything, you can let smaller objects that are children to be unnamed objects if they are all identical.
Cut out Javascript that changes anything of the look of the page. Users will break it.
Don't use CSS reset stylesheets. It'll complicate things. If users are going to deal with CSS, let them deal with the cross-browser issues.
All of the HTML will be valid, won't it?
Basically, start off with reasonably semantic (and valid!) html, and be sure to use a fairly wide array of elements (don't make everything a div) and classes (sprinkle liberally where it seems appropriate. Using a variety of elements makes for more readable css and html, which is important for easy stylability.
Then, don't be afraid to add extra elements just to make styling easier. For instance, if you have a table representing a grid of some sort (i.e., not just a plain text table), and you'd like a particular data-cell to be the focus of attention, then although it may be possible to simply set a class on the td, you're better off nesting a new element within the td (and setting the class on that). Extra nesting elements like this greatly reduce the need for complex css selectors which may not even be supported across browsers. It's better for an element to have multiple classes than to have a single class with multiple meanings; and it's better for a class to have the same meaning everywhere (i.e. not to be dependent on other classes).
Your html will be an API of sorts, so keeping it comprehensible is important. Javascript makes things tricky, so if you need any, I'd try to keep javascript out of css's way - make sure than any modifications that javascript makes to the dom are consistent with your "API" - don't hardcode specific layout overrides into the javascript. If javascript needs to make a popup to display extra info, say, then simply add a <div class="js-extrainfo-pop>...</div> to the document at an appropriate location and let the css decide how to style the popup, rather than dealing with z-indexes, display: absolute etc. in javascript. That way, the client CSS need learn only one API - your html structure - rather than work around a JS-wart. The DOM is a manageable interface, javascript is quite a bit more complex.
Finally, most customers are likely to want only minor modifications to your basic layout; so don't be afraid to use tables where necessary. It's surprisingly tricky (often outright impossible) to apply grid-based layout via css without using tables. At the very least, you'll need to use a syntactic structure parallel to the table-tbody-tr-td structure, and let people style that as a table via css's display:table-* rules (which aren't supported everywhere equally well). If you're sure you need a grid, use a table and stop worrying. Real css "heroes" will override any of your "implicit" layout anyhow, and starting with a reasonable base point will make the initial unstyled page look more obvious, and will help clients make their own styling choices.
In summary,
Short tip: I think semantics are key in this approach. I've seen a lot of websites that tend to name their classes like floatleft, width100px or *right_column*. This means you are saying in the HTML how you expect the website to look like. Give the CSS classes a semantic meaning, like sidebar or widget, this makes the HTML and CSS code much more readable.
Maybe have a look at HTML5 and the new tags this will introduce? Nice blogpost can be found at Woork: CSS code structure for HTML5