Obviously, it makes sense to find and deal with any existing issues in these categories -- but that's not going to be enough. There are too many ways things can go wrong when developing a site; and it can take hours to track down an issue and figure out a fix. Avoiding problems is a lot simpler and takes a lot less time.
A. Test, test, test. The only real long-term way to deal with the possible quirks between browsers is to vigorously and thoroughly test any site you're responsible for in all the major browsers, side-by-side, and see what happens. Work with your own sites across the major browsers -- don't just passively browse, but try to actually get things done and see what happens.
On Windows, it's not difficult at all to get IE 7, Firefox, and Opera all running side-by-side without stepping on each other's toes; Firefox is even available in a portable edition for those who want to run it without installing it. (Opera comes in a portable version, too.)
If you're not currently running Windows but are forced to test compatibility with IE anyway, there are a couple of solutions. A fairly elaborate series of hacks exist to run IE on top of Linux through the WINE compatibility layer, although it only works for IE 6 and lower. Another solution involves the use of a virtual-computing product like VMware or VirtualBox to run Windows itself. Interestingly enough, Microsoft provides a virtual hard-disk file that contains a fully licensed (albeit time-limited) installation of Windows XP SP2 with either IE 6 or IE 7 available on it -- useful if you don't have, say, an MSDN subscription.
Also be sure to validate any code you create, since browsers have different ways of recovering from a broken piece of HTML, and you don't want to be at the mercy of such mechanisms. While debugging an older site, I tried to figure out why a given page wouldn't load at all in Firefox, while IE rendered it spotlessly. A quick pass with an HTML validator showed the problem: a table was missing its closing < /table > tag. When I supplied the missing tag, all was well again. Apparently, IE is a bit more forgiving about tables that have missing tags, at least when dealing with the quirks-mode formatting of most existing Web pages.
B. Pick a standard and stick with it. IE may have a big installed base, but coding for IE first is not something you should do unless you have been ordered to do so. My own habit has been to use Firefox as the baseline for everything -- since more browsers tend to render like Firefox than they do IE -- and then make any IE- or other browser-specific fixes after that. If you're in the process of re-centering everything on Mozilla standards, IBM has a long and detailed document in their developerWorks library about how to transition Web docs from IE to Mozilla, including a number of general cross-browser tips.
C. Annotate and warn. If you have implemented things you want to support but simply cannot get them to work properly across the board, at least make sure the people accessing your site know about it or can look it up somewhere. If you know certain functions won't work in IE, you can use a browser-detection routine (see below) to insert a notice to the effect that some features may be degraded in certain browsers. Better to tell them up front than to let them find out on their own!
D. Pick a browser and make everyone else stick with it, too. This isn't likely to make you popular with many people, but if you have specific reasons for working on one and only one browser, it is possible to enforce this rule. Just be prepared to get plenty of hate mail, as few people like being bullied into using any specific browser.
E. Keep an eye on the future. Web "standards," and especially their implementations, aren't static things. Even a small change to the right of the decimal point can affect the way things render or behave. Stay abreast of those changes whenever you can, so that you can counter them proactively instead of reactively.