Browsers as test platforms

In this article we will take a look at browsers from a developer's point of view. When developing for the web, it is inevitable that we need to debug and test our work. How easy or how hard is it to find the problems causing errors and how easy is it to replicate certain environment changes? Once we identified the steps we need to take to test properly, we will see if there is a chance to extend the browser to make these steps a lot easier.

Meet the cast

The development environment is an PC running Windows XP, in this case a IBM Thinkpad T40 with 1GB of Ram and a Centrino 1300MHz processor.

We will take a look at Microsoft Internet Explorer 6, Mozilla Firefox 1.0 preview release and Opera 7.50.

For testing, we will use a web site template with some HTML errors and a Javascript error.

What we want to test is:

Debugging the HTML

We will check how comfortable the source view is in the browser, and if it provides us with extra tools to check the HTML structure.

Debugging the Javascript

We will test how easy it is to trace back Javascript errors. Does the browser tell us the error? How easy is it to see the error messages?

Debugging the CSS

When using CSS seriously, we need to avoid Quirksmode at all costs. Quirksmode is a feature that was added into modern browsers to ensure backward compatibility and forces it to render pages like its predecessor. This makes it nearly impossible to predict the outcome, and forces us to keep developing for the past rather than for the future. We can force browsers to render web sites properly - in standards mode - by giving them the correct DOCTYPE [1]. To see what went wrong with our CSS, we need to find out whether the browser renders in Quirksmode or not.

Testing the accessibility of our page

To test how accessible our page is, we can take a quick look to see how it renders without CSS, Javascript or any of them. Furthermore, we want to resize the font of the browser to check if that breaks our design.

Microsoft Internet Explorer 6

Internet Explorer, or 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-colour-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 MSIE 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. MSIE menu to show the toolbar

Once visible, we can see in the status bar that a Javascript error occurred: MSIE Status bar indicating an error has occured

If we double-click this error, MSIE comes up with the message: MSIE Javascript error 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: MSIE Option to turn on Javascript alerts

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

MSIE 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 with the buggy one shows.

Checking the site's accessibility

MSIE 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: MSIE menu to disable Javascript

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. MSIE menu to disable CSS

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 menu sports and extensive Multimedia section which allows us to turn different media in the page on an off. MSIE menu to disable images

To change the font size in MSIE, 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 size and two enlarging it. MSIE dialogue to change the font size

Mozilla Firefox 1.0

The browser that has undergone many name changes (Phoenix, Firebird, FireFox) is the standalone browser of the Mozilla Suite - the same engine as newer Netscape browsers. When Netscape 4.x got axed the gecko engine emerged, driving the first ill-fated versions of Netscape 6 and 6.1 and getting better with each version. The Gecko engine is very true to the W3C standards but also quite forgiving when it comes to invalid markup, albeit not as much as MSIE.

If we want to check for W3C valid CSS and markup, Firefox is a good bet.

Debugging the HTML

Firefox does not open the HTML in Textpad or Notepad, but has an internal source viewer with syntax highlighting. This makes it a bit easier to track HTML errors. Firefox also has an extensive page information tool, which can be accessed by right-clicking the page and choosing "page info" from the context menu. Alternatively we can select Tools -> Page Info from the top menu. Firefox Page Information dialogue

To see why our FORM doesn't send of any data, we can choose the & #34;Forms" tab and see that we forgot to enter a form. If the page had a FORM, its fields would have been listed in the fields section.

To trace back the missing closing tag of the table, we can use the DOM Inspector, which can be reached via Tools->DOM Inspector or Ctrl+Shift+I. Firefox Dom Inspector

This very powerful tool allows us to inspect the structure of the HTML document. In our case TABLE should appear directly after P following the DIV with the class "multicolthree". As Firefox had to close the element on its own to be able to render it, it moved it to the end of the parent element - indicating that we forgot to close it.

The DOM Inspector is a wonderful way to trace back changes and bugs in markup. You can even use it to change and delete parts of the current cached document, which comes in handy when you want to print a page that has no real print version. Simply go to the DOM Inspector and highlight and delete all the unwanted elements before you print the page.

Debugging Javascript

Firefox does not pop up any error message when it encounters a script problem but adds it to the Javascript Console in the Tools menu: Firefox Javascript Console

We can clearly see the mistake we made and its location in the correct file. Much more we cannot ask for.

Debugging CSS

The page information dialogue mentioned above also tells us which rendering mode the browser is in: Firefox render mode information

In addition to this information, the DOM Inspector also shows you which classes and IDs are applied to the different elements, which makes it rather easy to spot faults like IDs being used more than once.

Testing for accessibility

To check our site without scripting support we have to select Tools -> Options and select the "Web Features" option. Firefox page options dialogue

Here we can easily turn images and scripting on and off. On the advanced menu we can also disallow scripts to perform certain changes like change attributes of the current window or change images.

If we want to turn off styles, we can do so via the View-> Page Style dialogue. Firefox turn off styles dialogue

Resizing the font can be done via the Text Size dialogue in the same menu or by pressing Ctrl and + respectively Ctrl and -. We can reset the font size to the default by pressing Ctrl and 0.

Opera 7.5

Opera is one of the few remaining commercial browsers (MSIE is not sold as a standalone product). For years it has been improving and in the current version it is one of the best CSS compliant browsers and has probably the fastest rendering engine. It still has some issues with DOM and dynamically generated content, but they are working on it.

Debugging the HTML

Opera shows sources in Textpad, much like MSIE, but has some peculiarity that you have to check the Frame source from the option menu even when there are no frames present. Opera View Source dialogue

You can also upload the page directly to the W3C validator.

The real power of Opera however is its user mode, which can be activated via View -> Style -> User mode: Opera user mode

This mode makes it easy for us to see the structure of the document and recognise the missing FORM and the unclosed TABLE. HTML structure shown in Opera's user mode

Debugging Javascript

The Javascript debugging console can be found in Opera at Tools -> Consoles -> Javascript console. It tells us clearly where and what the problem is:

Event thread: onload
Error:
name: TypeError
message: Statement on line 10: Expression did not 
evaluate to a function object: uls[i].parentNode.getElementByTagName
Backtrace:
Line 10 of linked script file://localhost/C:/dummyfunctions.js
  (uls[i].parentNode.getElementByTagName("a"))[0].onclick = function () 
{
return false;
}
;
Line 50 of linked script file://localhost/C:/dummyfunctions.js
  collapseNav();
At unknown location
  {event handler trampoline}

Debugging CSS

Opera does not give any indication as to what render mode is enabled. However, its rendering engine is that close to the standard that it is a good browser to test with.

Testing for accessibility

The real power of opera's user mode shows itself when you want to test for accessibility (or when you need these options to access a page). It is dead easy to turn off CSS and use high contrast modes. Opera also links all the alternative style sheets available for the page below the options of the user mode.

We can turn off images by selecting the "No images" option from the View -> Images menu, and pressing F12 or selecing Tools -> Quick Preferences will get us to the preference menu, which enables us to toggle Javascript, Plugins, GIF animation and Java. Opera preference menu

Unlike the other browsers, Opera does not only resize the font, but the whole page, including graphics, which does make a lot more sense. However, it shows some bugs when zooming complex CSS layouts and re-arranges them. You can zoom the page via View -> Zoom or with the plus and minus keys. Opera's zoom option

This feature is also very handy when debugging layout quirks.

Summary

Surprisingly, the underdog Opera is by far the superior browser when it comes to testing and debugging web pages. Its low market penetration and great CSS rendering engine makes it a bad test platform though, as things looking correct in Opera might be totally unusable in MSIE. As an overall test browser, Firefox is the better choice. MSIE needs to be on every test plan though, as it still is the most used browser, but it is time to consider moving on.

Improving the existing browsers

Both IE and Firefox can be improved using third party extensions. For Firefox there is the web developer toolbar [2], which is so packed with goodies that it would make up for an article on its own. One of its best features is the Sidebar, which allows you to see and edit the CSS files in use. Firefox updates the local copy of the document, not the one on the server, of course. Still, for debugging with third parties it is a real timesaver. CSS editing in the Firefox Sidebar

Another small but significant change for Firefox is to create a new Bookmark in our Links Toolbar with the source:

chrome://global/content/console.xul

When we tick the "load this bookmark in the sidebar" option, we can see the Javascript console next to the document instead of opening it in a new window. Adding a bookmark in Firefox to open the Javascript console in the sidebar

For MSIE, there is the accessibility toolbar [3]. It is not quite as powerful as the webdeveloper one, but makes life a lot easier, especially when testing the dependencies of the page on scripting and styles.

Furthermore, there are various bookmarklets or favelets [4][5] collections allowing for some of the functionality offered in those toolbars.

Browser wishlist

With the aforementioned extensions even MSIE is a good testing and debugging platform, but still browsers are far too forgiving to help interaction architects with their quest for a compliant and clean web.

Some of the stricter features of older browsers - Netscape 4.x not rendering unclosed tables or MSIE showing a fixed status bar and popping up error messages - got axed for seemingly better usability.

Maybe a really strict browser, or even better, the operating system refusing to render invalid HTML would make the web a cleaner and more reliable media as it is today. It would also ensure that companies need to provide quality rather than quantity in a shiny wrapper.

Links