One of the advantages of ASP.NET is its ability to deal with the incompatibilities that exist between browsers. Because ASP.NET is a server side technology that generates web pages dynamically, it’s able to change the HTML it renders at runtime. So if I place a menu control on my page ASP.NET will render the HTML code that is specific to the browser that’s requesting the page. This is great since it frees the developer from having to deal with all the browser incompatibilities that has become the bane of most web developers.

With the release of .Net 2.0 all of the server controls are cross browser compatible, according to Microsoft, so you would think that dealing with browser incompatibilities would be a thing of the past for the ASP.NET developer. Unfortunately this is not the case. While it is true that the server controls that ship with .Net 2.0 are cross browser compatible, it doesn’t mean they will always work in the various browsers as expected. Sounds like a contradiction doesn’t it? Although .Net is quite good at rendering the appropriate HTML depending on the browser and its various capabilities, the real problem is actually determining the user’s browser and its capabilities.

The .Net framework contains a list of browser capabilities, often referred to as Browser CAPS, that’s used to help determine the browser and its capabilities when a page is requested. From this information the proper HTML is rendered for the different ASP.NET server controls. There are a lot of browsers and a lot of different versions with a lot of different capabilities so as you can imagine the information list is large and ever changing. Unfortunately, a few years back Microsoft decided to outsource the maintenance of this list to a company called Cyscape (www.cyscape.com) who has done an abysmal job at best. This shouldn’t come as a surprise since Cyscape has been hawking its own product, BrowserHawk, to solve this very same problem. If that’s not a conflict of interest I don’t know what is.

This Browser CAPS information list is not proprietary and is open and modifiable by anyone so in theory you don’t need to wait for Cyscape to make the updates and corrections. The Browser CAPS info for a .Net  2.0 installation is located (on my machine) in a folder:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers

In this folder you’ll find a list of xml files with “.browser” file extensions that contain all the information on the given browser family and its capabilities. The information here is used by all .Net web applications running on your system. If you have access to this folder you can edit these files yourself rather than wait for Cyscape to do it and have it come through as a .Net update.

If you don’t have access to this folder, for instance if you’re having your website hosted, you can also add the information to the web.config file of your website. The custom browser capability info should be placed in the system.web section of the web.config file as shown here:

< system.web >
< browserCaps >
< case match="AppleWebKit/(?’version‘(?’major’\d?)(?’minor’\d{2})(?’letters’\w*)?)" >
browser= AppleWebKit
version=${version}
majorversion=0${major}
minorversion=0.${minor}
frames=true
tables=true
cookies=true
javascript=true
javaapplets=true
ecmascriptversion=1.5
w3cdomversion=1.0
css1=true
css2=true
xml=true
tagwriter=System.Web.UI.HtmlTextWriter
< case match=" AppleWebKit/(?’version’(?’major’\d)(?’minor’\d+)(?’letters’\w*))(.* )?(?’type’[^/\d]*)/.*( |$)" >
type=${type}
< /case >
< /case >
< /browserCaps >
< /system.web >

Although this approach allows you to specifiy the browser detection and capabilities information on systems where you have restricted access, it does mean the information is not global and must be specified in the web.config file for each website on the webserver. For most people this isn’t much more than an inconvenience that’s easily overshadowed by the effort saved when ASP.NET renders the correct HTML for you.

So that leaves us with one final question, how do we know what to set for the various parameters? Unfortunately this isn’t an easy question to answer. If you’re having problems with the rendering for a particular browser the first place to look is the browser’s website. Many browser vendors have Browser CAPS settings in their support sections or can at least point you to a resource with the correct settings.

Rob Eberhardt also maintains a web page with some useful information on browser caps:
http://slingfive.com/pages/code/browserCaps/

For a more detailed treatment of how ASP.NET manages browser detection, including how you can define your own browser settings you might want to check out the following article on MSDN:
http://msdn.microsoft.com/msdnmag/issues/05/01/ASPColumn/

It’s unfortunate that Microsoft has outsourced this very important piece of work to a company with an obvious conflict of interest. This move has decreased the productivity gain from using a supposedly cross browser capable web development platform as well as increased the frustration of many .Net developers. Having said that, and I’d hate to support Cyscape for their lack of support on this issue, but if you really need to solve the browser detection problem and trying to keep up with all the changes is too time consuming and costly, then BrowserHawk may be the answer to your problems.

Quick, what’s the difference between these two lines;

What You See Is Not Always What You Get!

What You See Is Not Always What You Get!

Depending on your browser and personal settings, you may have noticed a size difference or perhaps the fonts are different. Regardless, the odds are you missed one of the most important differences, the fact that the first line has meaning and the second does not … well at least to a search engine.

The difference is in the programming or, more accurately, the markup. Whatever you want to call it, the underlying HTML code that is used to make this page can have a significant impact on how a search engine indexes the page, and therefore how well your page performs in the search engines.

The first line used an <h3> tag, telling the search engine this is a header, that it has important meaning pertaining to the content of the page. Here’s the actual underlying HTML:

<h3>What You See Is Not Always What You Get!</h3>

The second line, although it appears important visually, has no special meaning to a search engine. Here’s the underlying HTML code :

<p><strong><span style="font-size: 1.4em;">What You See Is Not Always What You Get!</span></strong></p>

So what does this mean in the end? It means that what you see is not always what you get. Two identical looking pages created by two different people can have significantly different results with search engines. When a search engine indexes a page it crawls through the underlying HTML code for the page and uses special markup tags, such as the <h3> tag, to try and deduce meaning and the relevance of certain words and phrases on the page. The <h3> tag has semantic meaning for the search engine. Search engines plug this information into their page ranking equations which are used to determine the page’s rank. The page that was styled with font-size selection (the second example above) provides no additional semantic meaning for the search engine and is therefore a miss opportunity providing little or no impact on it’s ranking in the search engine.

The example above, with the <h3> tag, is a very simple example with only one of the many HTML tags used to create web pages. A very common problem in the web design industry centers around the lack of understanding of the importance of the web page’s underlying HTML code. There are many WYSIWYG (what you see is what you get) tools used by designers that allow them to create great looking pages without having to understand how HTML works because the tool produces the HTML for them. The problem, as many companies are finding out the hard way, is that these tools do not always produce search engine friendly HTML code. I’m not suggesting that these tools can’t do this to some degree, but the tool will likely miss many opportunities for optimization and is therefore no substitute for a solid understanding of HTML and the way search engines interpret it.

Ensuring good search engine practices are being followed during initial development will always be more cost effective than trying to fix the problem after the website has been launched and no one shows up to view it.