Wednesday 31 October 2007

Whose Problem is it anyway?

As a developer I on a daily basis make assumptions. These assumptions often vary from whether some sort of functionality is required or if SQL is the best database for the job, or if IE supports a JavaScript event or CSS selector. Now the problem with this is that sometimes our assumptions are wrong. For Me this has happened Multiple times in the last few days, in one case I had assumed that IE understood the 'onChange' event and the ‘target’ DOM attribute. Sadly this was not the case and as a result a JavaScript script I had made only worked in FireFox. This then lead to me wasting another hour rewriting the code so it worked in IE. The issue for me was that IE treated ‘on Change’ events on input fields as ‘on blur’ which lead to the event listener never firing the attached code. Also IE has the ‘original target’ attribute and not ‘target’, most annoying.

Who's to blame?

So whose problem is this? Me as the developer? lE for not supporting all DOM events and properties ? FireFox for supporting the W3C spec? Or even the end user for using a browser as buggy as IE? Of course the problem really lies with the developers. In this day and age it's our job to be aware and able to cater for browser inconsistencies. It's part of being a good developer, and it’s what we’re paid for. We should not rely or make assumptions on how something should work, we should spend a little extra time to ensure our code is consistent and cross browser compatible.

What can we do

In my opinion, check for browser inconstancies should be part of our development cycle. We should try to foresee these issues and ensure appropriate action and code is written to handle unforeseen circumstances. Even if we just catch the error and report in a friendly way that this functionality won’t work. The same principle should be applied to data, all too often we assume data will be neatly given to us in a clean format and that foreign keys are nice int key values so we can perform simple look ups or key bag techniques. This isn't always the case, especially when working with older systems or other developer’s / companies that have a different coding standard than your own. The key to working with data is to know your data, I have touched on this before when I was writing about my Google Data code, unless you know what data you are going to receive and use within your application and how you can use it, your application will never stand the test of time. So what this really comes down to is that as developer's we must stop assuming and check web browsers behaves as we think it should or does. We must check that any data we use will always be in the format we expect, and we must ensure we document our code. If we don’t document our code other developers that may have to / want to use our code won't have to mane assumptions about how our code works and will be able to concentrate on things that really matter, coding, not bug fixing!

1 comment:

xyz said...

Good post! I think that you will find many of the posts over on this blog to be handy.

http://webbugtrack.blogspot.com/

They point out those horrible JavaScript bugs in IE and other browsers, as well as a workaround wherever possible.

cheers,
xyz