delivering code
Probably the nicest aspect of my job is to start building a site from scratch. There's always that drive to do a better job than last time, to learn from the mistakes made. No more legacy problems or compromises and requirement changes to worry about.
These moments appear a far away utopia when you have to deliver a contained piece of code meant to be implemented in a series of websites. Instead of starting with a clean slate, you have to make sure your piece of html and css will work on every site without fail. Not an easy task, but there are ways to minimize the troubles you will be facing.
the easy way out
Of course you can always opt to include your piece of code through an iframe. You won't face any conflicts with existing css this way but iframes can put a serious strain on the people implementing them, especially when they don't know what they're dealing with. Even worse, iframes have some nasty accessibility problems. Although the iframe is probably the easiest solution, it's not the best one by far.
the way it should be
So let's assume we're delivering a clean piece of html code with all the necessary styles in a separate css file that both need to be included in the source document. The problem we're dealing with is that there's a realistic chance that your nicely tweaked piece of code will be overruled by already existing css declarations. Luckily, we can take some measures to avoid this.
1. css include
The first thing to do is to make sure your css file is included last in the source document. Assuming you've written some decent css (meaning, you set all declarations from the root element of your html snippet as to not targeting any existing code), this minimizes the chance that the already existing css will override your declarations in case of equal specificity.
2. id me
I've talked about the use of ids vs classes before, consider this a little addendum. Although it depends on the piece of code you're delivering (can it be used once or more within a single document?), it is best to id as much as possible. This way, the specificity of your css should be high enough to override most existing css declarations.
3. prefix me
There's always the possibility you choose ids or class names that are already in use on another site. To prevent this, it is better to prefix your own classes and ids. It does make your code a little messier, but at least your code will be easy to recognize and the chance of conflict with existing css will be minimal.
4. think broad
The rules above will probably protect you against most conflict situations, but the nastiest problem is one you can hardly protect yourself against. As you have no control (or even a clue) about the css declarations that exist on other sites, you have no idea what properties are specified and how those properties could harm your code.
You could fix a nice css design but what if someone put a left float on every div (an existing layout technique), or put a border on every p tag. There are numerous properties that can be assigned to an html element through css and you can't predict nor cover them all. The best you can do is provide base values for the most common properties or the ones you assume could be set already (like borders, colors etc).
and finally ...
With this all set, the only thing left is to advise the people implementing your code to use an aid like Firebug or Web Developer Toolbar whenever they encounter a problem with the code you provided. Conflicts like this can be easily tracked down with such tools. Still, with the guidelines above, you should have a lot less to worry about the next time you deliver a separate piece of code to be incorporated in one or many external sites.