delivering code/how to avoid conflict
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.
I don't quite agree on your first rule. If you installed Yslow along with Firebug, you'll notice that it suggests to put it at the top of the page for a few reasons.
First it allows progressive rendering of the css, so that the browser can place the items at its right position from the start. Second it is a better experience for your users. IE blocks rendering of the page, until all CSS is loaded so that you'll see only blank pages until it's loaded. And Firefox doesn't block it, but then you'll get blocks that start jumping around the page.
The advantages are mostly visual for your users, but that seems important to me too. Read more about it at the Yahoo blog
Ps. It's pretty annoying that I have to read the markdown manual first, before I can show a link, because it removes underscores when I past it as text.
I think you didn't really understand what he was trying to say. Although what he said could be interpreted the way you explained it, but the way I see it he means that your css file should be the last one to be included inside the header, this doesn't mean you have to put it at the end of your document.
Hey Rogier,
sorry if the article was a bit unclear about that, but it's like Filip answered. You don't have to include your css at the end of the document, it simple needs to be the last css include in line (of course, preferrably in the header for the reasons you mentioned).
As for the markdown syntax, I know it's a bit of a hassle but it guarantees better quality posts. I'll try to look into the underscore problem, as that sounds like something it shouldn't be doing :)
When you talk about prefixing your classes and ids, I presume you mean something like id="mycontentfoo", class="mycontentbar"? Wouldn't it be easier to just put an id on the root of your element that identifies it uniquely and use that to select your elements? Just a thought anyway. Like the articles btw, you've described some fiddly problems well, they have been very helpful to me. Thanks.
Well yeah, that is one thing you should do, but prefixing every class and id has the important advantage that you can never run into a class or id that has already been defined. For example, you could include an element with class="langNav" in your code and css it through #baseId .langNav ... this is fine, but if the target page has a langNav of its own already within the css with properties defined that you haven't defined yourself, you'll get into trouble. Defining your own class="myprefix_langNav" fixes this, as the chance is close to nil that anyone will have used that specific class on his site.
It's not a very graceful solution, but it's sturdy. And if you want to minimize the chance of running into unexpected trouble, it's a good option.
* required fields