CSS positioning seems to be becoming a nightmare when it comes to IE6 support. While I am aware that the likes of 37signals have stopped making their products work with it, there remain a lot of people who stick or are stuck with the old retainer. I am one of the latter because of the continued use of Windows 2000 at my place of work, though a Windows Vista roll-out has been mooted for a while now. If nothing else, it keeps me in the loop for any inconsistencies that afflict the display of my websites. Positioning of an element within the browser window rather than within its parent element is one of these and it looks as if specifying a position of relative in a stylesheet is part of this. Apparently, it could be down to its non-triggering of IE’s haslayout property. It might be a hack but I have found that static positioning has helped. I’ll continue to keep my eye out for a better solution if it exists but the static option seems to have no detrimental effect in IE7, IE8, Firefox, Safari, Chrome or Opera.

On first sight, this probably sounds daft given how good Firefox is but you cannot ignore those surf the web using the ever pervasive Internet Explorer when doing some web development. Using virtualisation is a solution to the need but it can mean that you need to set up a web server with Perl, PHP, MySQL and the like in a virtual machine, all for a little offline testing and then there’s the potential for a lot of file copying too. Otherwise, you are trying to sneak things online and catch the glitches before anyone else does, never a good plan.

Therefore, having the ability to run IE to test your offline LAMPP set up is a boon and IES4Linux allows you to do what’s really needed. Naturally, WINE is involved so some flakiness may be experienced, even after the ever useful API library’s reaching version 1. Otherwise, all usually runs well once you work you way through the very helpful instructions on the IES4Linux website. I did get a misplaced message about the version of WINE that I was using and Python errors made a worrying appearance but neither compromised the end result: a working IE6 installation on my main Ubuntu box.

IE5 and IE5.5 are also on offer if you’re interested but, after looking at my visitor statistics, I think that I can discount these. IE7 and the work-in-progress IE8 make no appearance on the availability list. The absence of IE7 is not a big problem as it might appear because coding for IE6 sufficiently suffices for IE7, even now; IE8 may not be the same in this regard but we shall see. Even so, a later browser release does mean a more secure version and I reckon that including IE7 should be next on the project’s to do list. Saying that, what we have now is far better than nothing at all.

It’s quite hard to describe this observation in a title so here goes with a longer description in a post. One thing that I spotted with the Prosumer theme used on this blog is that the links on the horizontal navigation bar underneath the mast head were not appearing as they should. The links have been formatted using CSS to appear in boxes with borders that are more apparent when you hover over them. In IE, the top and bottom borders were missing. After a spot of digging, I came up with the line-height property being the cause and I was right: the extremities of the boxes surrounding the text were being cut off because they exceeded the allotted space. As if to emphasise that IE7 isn’t as major a leap forward from IE6 as we would have liked, the problem affected that browser as well.

Aside: Link text colours weren’t being honoured by IE7 like they are by IE6, Firefox and Opera so another tweak to the CSS was needed.

Looking through Google Analytics for my websites, I have always been struck by the lack of IE7 uptake seemingly apparent from the statistics. However, I recently discovered that there may be a reason for this. I use the Ultimate GA plugin with my WordPress blogs and that adds the JavaScript code block near the bottom of the page. However, I recently saw that giving me scripting errors in IE7 and a spot of manual coding saw it travel to the header section of the web page. That, and the deactivation of the said plugin, was sufficient to rid of the errors in question. Seeing the effect of my changes on the reported share of visitors using IE7 could be interesting. It might even boost the Vista numbers as well.

Having been exposed to an application at work that uses a lot of JavaScript, I fully appreciate what some mean when they talk about IE6’s inefficient handling of JavaScript. After seeing a web page taking an age to reload and your CPU taking a hammering because of JavaScript processing, the penny does tend to drop… Needless to say, this very much impacts the world of AJAX-driven web applications with their heavy dependence of client-side JavaScript. While IE7 does come to the rescue, there remain plenty of IE6 users still out there and this is reflect in website statistics. This reflects a certain level of inertia in the browser market that not only afflicts the uptake of IE7 but also the likes of Mozilla, Opera and Safari. It also means that anyone developing AJAX applications very much needs to continue testing in IE6, especially if the product of their labours is for wider public use. An example of such an application is Zimbra, an open source web application for messaging and collaboration, and the people behind it have generously share the results of their browser performance benchmarking. They did comparisons of IE6 vs. IE7 and Firefox 2 vs. IE7. IE6 easily came out as the worst in these while Firefox 2 was the best. I suppose that the next question to be asked centres around the type of code that is processed inefficiently by IE6. I wouldn’t be at all surprised if a list emerged but here’s one: using Microsoft’s proprietary innerHTML object to update the DOM for a web page format. Having a quick trawl on Google, this came up for mention as a cause of memory leaks. It is also a Microsoft innovation that never got taken up by those overseeing web standards, hardly a surprise since a spot of DOM scripting achieves the same end. It may be faster to code than any alternatives, and it does have some support from other browsers, but it does seem to have got a bad name and so should be avoided if possible. That said, it would be interesting to see a performance comparsion between innerHTML and DOM methods in IE6.

My installation of Firefox seems to have stopped listening to the target attribute of hyperlinks. Thankfully, the middle mouse button comes to the rescue. Clicking on a link with the middle button opens it the destination page up in a new window or tab, depending on how you set your defaults. The behaviour goes even further than this: the trusty middle mouse button does the same for bookmarks and the Google search bar; all very useful. And its not just a Firefox thing either. IE7 does the same thing for web page hyperlinks and bookmarks while in Opera, it is limited links on web pages.