HttpBrowserCapabilities
I haven't had to work with this directly that much, most of what I've done recently has been explicitly for uplevel browsers. Such a luxury. I was helping a friend with some templating code for a redesign of his site last night and two things leapt out at me.
Firstly, writing old-school 1998 html code
totally blows after you've made the transition to standards-based CSS layouts.
Ugh. If I never do another egregiously nested table, if I never do stupid gif-spacing tricks, it'll be too soon. It feels wrong the whole time and because it's so tedious by way of comparison (and because the requirements of this particular case allow for it), compromising the overall experience for, say, NN4.7 users gets real dang fluid (and his logfiles reveal that there are still too many of these poor tortured souls out there). Mostly little aesthetic stuff, mind you--but it really seems silly to obsess about design fidelity when the person's choice of browser seems to suggest they're not really about maximizing their experience. Maybe I'm ignoring a lot of captive corporate users on old browsers, maybe they should throw a junta and invite their IT management.
Secondly, ASP.NET treats pretty much anything that's not IE as a redheaded stepchild by default. No offense to redheaded children of non-nuclear families implied or intended there--I just find it a bit silly that the folks in Redmond can't admit that the latest releases of Mozilla and Opera are really better browsers than IE6 in a lot of ways. Then again, I can also understand the unilateralism, it's business.
What I still can't understand is why
cyScape is in charge of the browserCaps definitions and their updating (which they seem to be doing a real bang-up job at, since I don't recall them ever having actually been updated--nice work). There's a problem here. cyScape makes an ActiveX server-side browser detection component. A good one too, I used to use BrowserHawk, it does the job. This functionality has basically been folded in as part of the System.Web namespace as HttpBrowserCapabilities. BrowserHawk's functionality is really no longer relevant in .NET, except one part: the part where the browser definitions are kept current.
I only play a CFO on TV, but I sense a financial disconnect here. I can't imagine the browser definition subscription model is going to generate as much revenue as the ActiveX component + it's (different format) browser definition model, so what's cyScape's motivation for keeping the .NET definitions up to date and accurate? I may be wrong about the intent here, but the fact that there aren't any updated definitions doesn't detract from the point.
In any event, updating your machine.config (or overriding in a specific applications web.config) is a good thing in that it lets you treat first-world browsers as exactly that.
Lastly, I couldn't find an easy hook to check what the current page was interpreting ClientTarget was--I'm not using render methods in my base page class, it's more of a masterpage templating approach. So I can't see which version of writer I have and deduce whether I'm uplevel or downlevel. I ended up using css2 from HttpBrowserCapabilities.Items, but this feels like a hack (given the inherent gaps in accurate/timely browserCaps definitions). If anyone has any good suggestions, email me.