Grauw’s blog

In response to the table sorting JavaScript I created for use on the section about anime on this website, Jep, a colleague of mine, wrote a little blog post about it. In which he wonders about compatibility issues:

...because IE doesn’t have a getAttributeNS – you can only do getAttribute("chicken:feed") – which means you have to manage the namespace handling. I don’t know what to think about that. Do you really want to handle namespaces? Or can you just do getAttribute("g:sort") and be happy with that.

Well, I guess that is true. As far as the DOM1 is concerned (in which getAttribute is defined), namespaces don’t exist. For that function, the g:sort attribute is just that – g colon sort –, and that is why getAttribute("g:sort") works.

However, because the page is loaded as XML (in browsers which support it, IE not included), and I use namespaces, it is better to use getAttributeNS. That method allows the user to be free in what prefix he uses, instead of binding it to one specific namespace prefix (‘g:’) and not really using namespaces at all. And that’s not in the spirit of XML... ;p.

Maybe I’ll make it use getAttribute as a fallback some time in the future though, I want to look at some methods to speed up the sorting for large tables anyway, and publish and document the script.

Anyways, there are two reasons for me not to really care as much for IE. First of all, this is just some experimenting for me. I like new technologies like CSS and XML, and like to do things which are ‘cutting edge’. Using getAttributeNS may not be strictly necessary from a practical point of view, it is the proper thing to do and it works (albeit not everywhere), so I’m using it.

The second reason is that I just really like the idea of progressive enhancement (sometimes also called MOSe). This means that I let the site itself, and the most important thing, the content, work in all browsers. This includes IE, Lynx, and even the most barebones mobile phone HTML browser. It’s just that better browsers get all the candy :).

The contents – the table – is what the page is about. Users of ‘better browsers’ get the ability to sort it, which can be convenient, but is not essential to the webpage. I would really like to stress this point, as I think it is very interesting. I mean, be honest, does the lack of sortability in IE really degrade the value of the page? I don’t think so, at all. Besides, a browser is just a tool, if people desperately want the table sorting to work they can always get the right tools for the job (just like I am sometimes forced to use IE).

I apply this methodology of progressive enhancement quite often. Other examples can be found in various places on this website: IE shows an ugly logo with a grey background, other browser a nicely blended one with shadows. I use the <abbr> tag when appropriate (<acronym> is obsolete), so what if IE users don’t get that tooltip. Non-IE users get multiple stylesheets to choose from. The main stylesheet looks actually pretty lousy in IE (even when I’m already using a number of IE hacks), but it works. I must say I have done a better job with this on other occasions, but for this site I just don’t feel motivated to bother, I have better things to spend my time on.

And as this is a personal website, I can afford such a methodology ;). Although I think in small amounts it could be done for larger-scale commercial or community sites as well, it’s not as if the IE users will notice... With non-IE browsers taking a growth spurt lately, this is getting more and more realistic.

Basically it is the reverse of the situation today (although things are getting better), where some sites offer IE-optimized stuff and a piped-down version for other browsers. Take a look at Microsoft’s MSDN Library for example. As is often the case, that one approaches a high annoyance level from a usability perspective because the non-IE version is, well, just too bothersome to use...

And, I think in my case it is more justified :). If you look at MSDN or any of those other IE-optimized sites (Sony’s Connect comes to mind), those are not IE-only because it is impossible to do in other browsers (usually it’s easier!), it is just because of laziness and the unwillingness to create two implementations. Because that’s what you get when having to deal with a very buggy and nonstandard implementation by a monopolist browser manufacturer, which let the product stagger to a halt after it swooped away all competition, lacking any further incentive to innovate.

With regards to Safari compatibility, I don’t know what it does (kinda hard to test), but if it doesn’t work, I can rest assured that their browser is still very much in development, and the minute they implement the XML DOM properly it will start to work.

For me, it is just a matter of wanting to do things according to standards and create maximum browser- and future-compatibility. Not creating specific fixes for IE is not because I have a grudge against IE out of principle, but just because I don’t always want to bother, especially if it doesn’t shut anyone out.