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 identify 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.
Browsers as Test Platforms - Mozilla Firefox 1.0 (Page 3 of 6 )
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 IE. 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.
To see why our FORM doesn’t send off any data, we can choose the “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.
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.
We can clearly see the mistake we made and its location in the correct file. We couldn't ask for more.
The page information dialogue mentioned above also tells us which rendering mode the browser is in.
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.
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.
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.