ASP.NET Discriminatory By Default

ASP.NET is Microsoft’s newest web application development system. Unfortunately, in its default configuration, it seriously discriminates against non-IE browsers. The browserCaps section of the machine.config or web.config configuration files uses the User Agent string to set a number of “capability” flags – such as what level of support it has for the W3C DOM, CSS and ECMAScript. However, this file knows next to nothing about non-IE browsers newer than Netscape 4.

We ran into this problem at work – ASP.NET applications looked fine in IE, but really ugly in Firefox. This was because it was treating Firefox as a really old browser, and doing its “panels” using tables instead of divs, which didn’t work very well when you nested them or tried to put them side by side. A quick update to browserCaps, as outlined on the page linked above, fixed the problem.

It would be easy to label this as part of some sort of conspiracy. I’m not going to do that, but I think Microsoft does have a duty to fix this in the next release of ASP.NET, and/or issue a patch. After all, not doing so means that their customers’ sites look terrible in some of their customers’ browsers. And they probably won’t be too happy about that, particularly if they spend hours trying to figure out why ASP.NET is generating different and broken HTML for these modern UAs.

6 thoughts on “ASP.NET Discriminatory By Default

  1. Opera got $30m when Microsoft did this to them. Stop being so conciliatory and force Microsoft to be responsible.

  2. It’s a little more complicated than that. The original release of visual studio .net was back in early 2002.. and while the last release of visual studio was back in 2003, changing the browsercaps would have been “incompatible” for a lot of their users. Assuming you agree that 2002 was when the list was “finalized”.. do you expect them to allow developers to target netscape 6? I don’t think anyone of the people who purchased a visual studio license wanted that.

    As far as Visual Studio 2005 goes.. it goes significantly beyond just allowing for more advanced browsers, it supports targeting actual STANDARDS such as xhtml all the way up to strict – which should be interesting as microsoft’s own browser has issues at that point. See this for a good description:

    Regarding some of the other bits – such as microsoft’s client side validation code, which is also IE only as of Visual Studio 2003 (though an open source equivalent is available that works cross browser).. 2005 should resolve that too:

    I’m not even going to mention the whole thing. :)

    Hope that puts your mind at ease.

  3. I’m seriouly under the impression that we should drop UA strings all together. Or probably better would be to make them more generic. I’ve never seen 1 case were the’ve been needed. Relying on the capabilities of browsers is always better than traditional browser sniffing.

    ps. throws out a 500 response if you send it an empty UA string.

  4. Alan, a UA string is needed very frequently. For example, in order to get downloadable files with spaces in their names to work properly in PHP, you have to differentiate between Gecko, Opera and everyone else. And that’s a relatively esoteric example that nonetheless has come up in the course of web design work. Sometimes you can’t just rely on the capabilities of a browser; sometimes the browser simply implements a standard, but incorrectly. Only then is UA-sniffing needed.

    If every feature in every browser were either absent or present and working perfectly, you’d be right. But we don’t live in a perfect world.

    That set, ASP.NET’s UA sniffing definitely needs fixing.

  5. Andrew: what you say doesn’t make any sense. Surely the whole point of browserCaps changing UA strings into a set of capabilities is that it’s possible to write pages in terms of capabilities rather than particular UAs, and to add more UAs (and enumerate their capabilities) in a backwardly-compatible way?

    I’m sure VS 2005 allows targetting particular standards – but if it doesn’t know that Firefox supports those standards, it’s not very useful!

  6. Sorry I wasn’t clear. We’re really talking about two different things here – clientTarget’s versus browserCaps.. it appears anyway.

    1. The reason why your pages look like crap by default is that the majority of decisions made by server controls on what html to render is based on the determination of if it’s an uplevel or downlevel browser (based, admittedly on the browsercaps definition). VS.Net 2002/2003 had very few options by default for what target definitions were available – which makes sense because 95% of the entire global market was one browser.. but you could still “hard code” the target to always render uplevel content by setting the target. “Cross Browser compatibility” was very ugly back in 2002/2003 and this “auto detecting” uplevel/downlevel capabilities at least allowed for some dynamic/server side “browser specific optimizations” so that developers could get functional pages in two very different browsers without having to make any code changes… or they could say “I’m only going to support uplevel browsers”.. Of course, you could always force html 3.2 content to be generated by setting the target to downlevel. My statement earlier was in regards to this uplevel/downlevel issue. Changing the definition of what is automatically considered an uplevel versus downlevel browser is dangerous and could cause Microsoft’s customers problems. For example, 3rd party components that relied on the uplevel/downlevel determination would then render IE Specific content. The reason being that the definition of uplevel often meant “being IE” – see this doc:

    The really really sad state of affairs was that “uplevel” meant “about as capable as ie 4.0”, which was actually pretty prevalent at the time… but that meant to get anything truly useful, you either had to make up a new target, which really caused 3rd party products to have problems.. or set the target as ie5.. you can imagine how confusing that was.

    It’s an admittedly poor situation, but one that is corrected in visual studio 2005 by allowing you to target a standard, which is the proper approach, instead of targetting a browser. It’s not browser sniffing to say “hey, do you support this standard?”.. it just says “all browsers will get the standard content”.

    2. Your concern over properly registering browser capability such as what version of ecmascript it supports is certainly valid, but that’s an entirely different issue (and I didn’t go there! :) ). The fact that you can control what is in there means that you certainly aren’t locked in to what microsoft says it supports… At least we can be thankful for some things.
    Modifying the browsercaps, though, to start saying firefox is uplevel can cause 3rd party products issues.. just be warned.