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.
Why is the Javascript not working (i.e. why is the menu not collapsing)?
Why is the site not being displayed correctly?
Why does the form not get sent off?
How does the design behave with different font sizes?
How does the page work without CSS, or Javascript or images?
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. It forces the current version of the browser to render pages in the same way as 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 websites properly - in standards mode – by giving them the correct DOCTYPE (see Quirksmode, http://gutfeldt.ch/matthias/articles/doctypeswitch.html.) 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.
Design Usability 
