Consulting Journal: Trends - More on the death of IE

Trends: More on the death of IE

by David Blakey

Will it matter if IE dies? Yes, because its bugs and workarounds will have a lasting effect.

[Monday 19 July 2004]

In an earlier article, I wrote that I believe that Microsoft's Internet Explorer (IE) will decline and eventually fall into disuse. I argued that Microsoft appears to have lost interest in it, having made few changes to keep it in line with changing HTML and CSS specifications.

One response to this has been: so what?. If IE died, there are other browsers available for a variety of platforms, and people and organizations could change over to one of them.

Unfortunately, I do not see the situation as being quite so simple.

The history of browsers

When MOSAIC was first developed, the specifications of HTML included only a few tags, as they were then called. Web pages were mainly text-based, with few logos and little positioning. The pages were mainly academic papers, with main headings (<h1>) and a variety of subheadings (<h2>, <h3>, etc) and most text in paragraphs. Simple tables were also used. At that time, paragraphs were rarely enclosed in <p> ... </p> tags. Most spacing was done by breaks (<br>).

This continued with Netscape Navigator, the successor to MOSAIC, and with the other browsers. At the same time that JavaScript started to appear, some browsers implemented tags that were unique to them and that were not included in the specifications.

By the time that early versions of IE appeared, the World Wide Web Consortium (W3) began to exercise stronger control. W3 began to publish a succession of specifications and proposals that led to HTML 4.01. Meanwhile, the Web had become much more graphical than textual, with tables used to position both graphics and text. The classic Web page design that includes a banner and a sidebar had become established, and W3 responded with stylesheets, as it encouraged the separation of design and content. This led to CSS, in its various versions.

Where we should have been

Today, we should be at a point where the major variable on a Web page is its content, with the design of that page subject to styles that apply to an entire site. We should have browsers that comply with the specifications for HTML and CSS.

Where we are

I wrote my first computer program decades ago. I know that the disciplines of testing software and ensuring software quality are complex and rigorous. These disciplines involve time and effort. Testing software takes much longer - up to ten times longer - than designing and coding software. That is, of course, assuming that the software is tested and that the testing is done properly.

Much coding on Web pages has never been thoroughly tested. Often, the coding has not even been checked to see if it complies with current specifications. Many Web coders have taken the easy option of using frames and tables instead of current methods for positioning elements on a Web page. Many Web coders use HTML elements and attributes that have been deprecated in favour of the current specifications. Many Web coders have developed pages that will only display correctly using Internet Explorer.

There is an enormous gap between the practices in computer programming for back-end mainframes and those in Web coding. The gap is exemplified by the last statement of the previous paragraph: many Web coders have developed pages that will only display correctly using Internet Explorer. What testing that have done has been done only using IE, and then probably only using the Windows version.

IE is notorious. Its main cause for notoriety is its vulnerability to attack, with Microsoft having to issue patches to it continuously as new problems are found. But it has a notoriety among Web developers because of a set of other bugs that affect how it renders Web pages.

The most famous bug was in IE 5.5, which miscalculated the amount of space that is occupied by an element's width, padding, borders and margins. This resulted in workarounds so that pages would display correctly in IE 5.5. The most famous workaround to this most famous bug worked because of another bug in IE 5.5.

Another famous bug, known as the peekaboo bug, still exists in IE 6.0.

And you may recall, from my earlier article, how I have had to include a special stylesheet for IE because it does not render the <q> element according to current specifications, while other browsers do.

The result of all this is that Web coders have taken one of two different directions. The first direction is that of the lazy who have coded Web pages so that they will only work properly in IE; their pages will often not render correctly in other browsers, because those browsers do not have bugs that the coding depends upon to work. The second direction is that of the diligent who have coded Web pages according to the specifications and who have then tweaked their code so that it will work in almost any browser.

If IE does die, it will leave two legacies: Web pages that will not render in other browsers and Web pages that will contain redundant code to work around the bugs. At least the second set of pages should work. The problem with these pages is that some of the strange code used in them may not be understood by those who have to maintain them in future. And one rule of programming is that if you do not understand the code, you leave it alone.

The future

I hope that a new generation of Web coders who have the disciplines of programmers will emerge, and that they will have the knowledge and skill to repair the damage that IE and its proponents have done to the Web development industry. As long as IE and its bugs and its workarounds still exist, this will not happen.

[ List articles on Trends ] [ View printable version ]