text-transform:

I’ve been working on an internal project lately where I am the only presentation-tier developer, which is not unusual here. What is unusual is that the application is lots of JavaScript and Ajax; most of our stuff leans far more heavily on server-side Java.

There are certainly still differences in browser implementations; heck, dealing with cross-browser CSS is a lot of What I Do^™. And there are certainly differences with JavaScript methods as well. However, the brand-name JavaScript libraries exist, in part, to flatten out and deal with the latter. If you’re using one of those libraries, you can rely on it to account for those differences under its hood.

Thus it was with some surprise that I saw a code check-in yesterday that added client-side browser sniffing… and if you were on anything other than IE, would prohibit you from logging in.

After cleaning up the pile of exclamation points that streamed forward from my eyeballs and littered my desk, I began investigating. It seems that in developing the app, the team had hit a few points where IE and Firefox were behaving differently with regards to JavaScript. The team was concerned that having to do cross-browser development would add lots of development time, and since this is an internal project (and thus we can dictate what browsers are permitted), the team decided to settle on one browser, picking IE.

I feel pretty strongly about browser agnosticism, and also feel pretty strongly that browser-sniffing code is inevitably fragile and tricky (I prefer “duck-typing” based on feature). More importantly, I argued, while there are browser differences with JS, if you’re using a library (which we are, namely jQuery), those things don’t tend to come into play unless you’re dealing with something complicated. If you’re coding up Google Maps, sure — but our application is fairly modest and not at all bleeding-edge. The browser differences we were encountering involve straightforward features, the kinds of things that the libraries should be accounting for… so this suggested there’s an underlying, deeper problem. Blocking a browser to avoid these issues would just be putting a band-aid on a deep wound.

Sure enough, the problems were easily remedied. In one instance, the code was checking to see if a form field was enabled by seeing if the field had a value of “enabled”. The issue? The code should be checking for a boolean of true or false, not a string value of “enabled”. One of the browsers would let you get away with this; the other would not. Changing the code to check for a boolean solved the problem. In another case, updates to a page were showing up in Firefox but not IE. IE, it turns out, was caching Ajax data; a jQuery setting of "$.ajaxSetup({ cache: false });" took care of it.

Once we checked in with the business owner about browser preferences, fighting for browser agnosticism turned out to be the right thing to do. We learned that half the user base for this application uses Firefox, and we’d really have annoyed them if we’d forced them to use IE for this application. The browser-sniffing code got removed today, as did the prohibition on non-IE users. Glad I took a stand!

The lessons here:

• Use a JS library, and take advantage of its features often. Let it deal with the annoying browser issues.
• If you’re using a library and encounter a cross-browser JavaScript problem, more often than not this suggests an issue with your code, not the browsers.