Browsers as Test Platforms - Microsoft Internet Explorer 6
(Page 2 of 6 )
Internet Explorer, IE or MSIE is still the most used browser in Windows environments. In comparison to the open source products, it is rather dusty and fails to comply with up-to-date Web standards. The thing that makes it very handy though, is that it ships with Windows - it is an integral part of it - and therefore is immediately at our beck and call (as it is loaded already in the boot-up process of Windows). It seems that IE was designed to please the user, and make it really easy for developers to do things wrong. In other words, IE will try to display anything and does not give much indication of something going wrong.
Debugging the HTML
In our example, we check the source code for problems and get Textpad as the editor when we choose “View Source” from the context menu. This non-color-coding editor will make it a bit hard to find errors, and we don’t get any indication where we went wrong. We have to rely on a better editor to check for errors, which can be quite annoying when the page is assembled from different includes.
Furthermore, there is no way to find our forgotten FORM element and unclosed TABLE unless we validate the page, or check it in a real editor.
Debugging Javascript
Debugging Javascript is even worse. Older versions of IE showed us a Javascript alert when something was amiss; nowadays we have to go through the process of selecting View from the toolbar and choose to Show the status bar.
Once visible, we can see in the status bar that a Javascript error occurred:
If we double-click this error, IE comes up with the message:
If we look into line 11 char 6 of our dummypage.html, all we’ll find is </head>. In other words, the message is not very helpful, but we can choose to have it shown to us every time by selecting the checkbox on the message window.
We can turn turn on alerts for every Javascript error by checking the option in Tools - > Internet Options -> Advanced:
This will give us a warning with the same cryptic message as above and allow us to start the MS Script debugger, should we have it installed.
Debugging the CSS
IE does not give us any indication of the render mode, neither in the browser, nor in the page properties. We are forced to check the DOCTYPE and consult a list to see which render mode we are in. The results can vary a lot, though, as a comparison of our fixed example ( http://icant.co.uk/forreview/browsertests/dummypagefixed.html) with the buggy one ( http://icant.co.uk/forreview/browsertests/dummypage.html) shows.
Checking the site’s accessibility
IE does not make it easy for us to check how our page looks like without Javascript or Style Sheets. For Javascript, we need to go to Tools -> Internet Options and select the Security Tab. Then we need to click the “Custom Level” button and scroll down a long way until we reach the option “Active Scripting” under “Scripting” to disable it
For CSS, there is no such option. The accessibility dialogue, which can be found via Tools -> Internet Options and the button “Accessibility” on the “General” tab allows us to either overwrite the style with a user style sheet or turn off the font settings – our CSS layout remains intact though.
Even creating a blank style sheet and assigning that one doesn’t work. To turn off CSS, you need an extension that does so via the DOM or cut the link to the CSS file.
Testing how the page looks without images is easier. The advanced Tab in the Tools -> Internet Options sports and extensive Multimedia section which allows us to turn different media in the page on an off.
To change the font size in IE, we need to go to View -> Text size and select the one we’d like to have. Default is middle, and there are two levels shrinking the font sizes and two enlarging it.
Next: Mozilla Firefox 1.0 >>
More Design Usability Articles
More By Chris Heilmann
/ 7 
