You can use the suggestions you've got above to do this. However, if the HTML is under your control, I'd strongly suggest you look at fixing it so that it works consistently between IE and NN. This really shouldn't be that hard (unless you're a masochist and trying to support very old v4 browsers), especially if you get browsers to parse your page in 'Strict' mode by using the appropriate DTD.

Keep It Simple: the more things that have to happen from a browser requesting a page to the server sending it back, the more things that can go wrong. Serving flat HTML files is simple. Having client-side code call a CGI, rewrite an (arbitrary?) file is fiddly, fragile, harder to maintain, consumes more server resources and slower.

If you really can't manage to get consistency using HTML & CSS, see if you can at least handle the inconsistency purely on the client-side using Javascript.

Cheers
ViceRaid

I couldn't agree more. In fact, I'd like to see your HTML to see what you are talking about (maybe outside of the Monastery walls). I spend much of my time getting web pages to work across browsers (especially since moving to all CSS-tableless-XHTML). I'm sure there's a way to solve your problem on the client side (again, provided you aren't trying to do something crazy like make it work in <6.0 NS).

—Brad
"Don't ever take a fence down until you know the reason it was put up. " G. K. Chesterton

Hear, hear. See also Designing With Web Standards (ISBN ISBN 0735712018) for why browser-dependent hacks are evil.

HTTP::BrowserDetect

There are two different aspects here:

• For HTML tags, you should only use those standard W3C HTML or XHTML tags (not those obsoleted ones), not tags that are only defined and supported by particular browsers. There is really no point to waste time, and deal with them. None of them makes your web page much better.
• For JavaScript, deal with the differences on client side, let your JavaScript handle it. JavaScript can detect the browser type, and for different types, you might need different syntax (this is life), and also some browser do not support certain things.

In general, it is not a good idea to send out different pages from server side, simply for different browsers.

Thanks for ViceRaid to follow up and elaborate on my thoughts.

For JavaScript, deal with the differences on client side, let your JavaScript handle it. JavaScript can detect the browser type, and for different types, you might need different syntax (this is life), and also some browser do not support certain things.

This is getting OT, but when doing compatibility coding for client-side Javascript, it's generally a better idea to test for the availability of the given methods or variables you want to use, rather than parsing the UA string (on the server-side, you don't have this luxury). This, by the by, is another reason to do client-compatability coding on the client-side. Anyway, here's an (untested) example:

var foo;
if ( document.getElementById ) {
  foo = document.getElementById('foo');
}
elsif ( document.all ) {
  foo = document.all['foo'];
}
...
[download]

One of the biggest advantages of this is that it much improves forward compatibility (it should still work when Mozilla v3.0 arrives). It also works when you have a browser that has had its UA-string mangled by a vendor, but is otherwise just a vanilla version of a well-known browser engine (IE, Gecko, whatever).