As a web developer, I do a lot of testing against different browsers and validating to W3C standards. These are the two things I spend most time doing when testing the HTML interface. It has become a common thing to do by most web developers no matter what kind of website they create and what tools they use.

The way most of us do it is by having a lot of different browsers open at the same time and the W3C HTML validation service web site. This approach is pretty good, but it has some serious issues.

Issue 1: Browser tests

By using different browsers as a test tool, you are pretty much covered for the everyday website development. But if you’re developing with a server-side technology such as ASP.NET or PHP, you might want to react differently to page requests, based on some server variables or http headers. It can be quite difficult to test your website in IE 5.5 on Windows 2000 if you have Windows XP installed and your website may generate different HTML based on the user-agent string.

Also, your server-side logic might react differently based on some custom headers and that’s not possible to simulate in any of the big browsers.

Issue 2: HTML validation

When developing a website, you probably built and tested it on your local machine before deploying it to a web server. If you want to do HTML validation from your local machine, you either have to copy/paste the source code or upload the HTML file directly to the W3C validator. When doing server-side development, you do not have the generated html file for upload, so you have to do copy/paste each time you want to validate. It is time consuming and annoying, but we have learned to live with it for some years now.

If you validate the html from a public web server you can just point the W3C validator to your website and hit refresh every time you make changes. The problem arises when you are building a password protected site, where only authenticated users may enter. A site like this, does not allow any validator to enter the site and do its job.

Issue 3: Load time

When you are optimizing your website for performance, you are probably interested in the page load time and the weight of your html in kilobytes. This is an easy way to test viewstate optimization in ASP.NET. None of the main browsers give you that information.

Issue 4: View the source code

Each time you make a change and want to see the html source code, you have to open the source code in a separate window by right-clicking and select View Source… or something similar. If you’re like me, you end up with a lot of Notepad windows because you forget to close them.

Issue 5: ASP.NET rendering

Some of the ASP.NET web controls render html differently based on the browser. This means that the validator service might not see the same html as a standard web browser does and because of that, does not validate correctly.

The idea

To solve all of the above issues in a way that is easy to do, with no learning curve and in one single application.

The solution

An extended web browser that can be used for server variable simulation and validation of html pages - both local and remote. I built such a browser in .NET 2.0 and called it Test Browser, because that’s exactly what it is. Here’s a screenshot.

The features include

• Turn automatic validation on/off
• Show the page size in kilobytes and the load time
• Simulate different user-agents, including GoogleBot  
• Create a list of HTTP headers to be sent on each request
• Save the list as a profile to use again and again
• Import/export the profiles for easy sharing
• Tabbed interface

The application is very simple to use and the interface very clear. I am planning on adding extra features such as a JavaScript debugger, CSS validator and a cookie watcher. If you have other ideas, please let me know and I’ll see what I can do.

Download

The application is a .NET 2.0 ClickOnce application, so it leaves no footprint in your registry and doesn’t pollute your system. It is as easy to install as it is to uninstall. The .NET Framework 2.0 is required.

Test Browse as ClickOnce (recommended)
TestBrowser.msi (437 KB)
Source code C#.zip (545,61 KB)

In the world of web developing there are many uncertain elements, but one thing you can always count on is the different rendering of HTML and CSS in the various browsers. A serious web craftsman tests for inconsistencies in Firefox, IE, Safari and Opera and makes the appropriate adjustments. That’s just something you have to do, even if your mark-up is W3C standards compliant.

Today, I came across an article describing the Gecko’s “Almost Standards” mode, which in essence says that the Gecko engine (the rendering engine used in Firefox, Mozilla and Netscape) has a mode somewhere between the Quirks and Standards mode. This “Almost standards” mode is triggered when the DOCTYPE isn’t strict. That means it is triggered by the default DOCTYPE in ASP.NET 2.0 which is XHTML transitional.

I had to try it out to believe it, and sure enough, there is a difference. This newfound knowledge will make it a little easier to make a website look good in all major browsers when the DOCTYPE is strict, because the rendering will be in Standards mode in all the browsers. It doesn’t matter if you do HTML or XHTML as long as the DOCTYPE is strict.

Here are the HTML and XHTML strict DOCTYPE definitions.

HTML 4.01
<!DOCTYPE HTML PUBLIC
"-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

XHTML 1.0
<!DOCTYPE HTML PUBLIC
"-//W3C//DTD HTML 4.01 Strict //EN" "http://www.w3.org/TR/html4/strict.dtd">

Update April 20th: Opara 8.5 has something similar to "Almost Standards" mode. I haven't been able to find any documentation, but I did some tests.