You’re viewing an archive of outdated material. Visit The Web Standards Project’s updated site to learn about our current mission.



Browser Upgrades. Standards now.

Cut ’n paste fun! Add this banner to your site, and link up.

NYPL XHTML Style Guide

Getting started with valid XHTML and CSS

W3C HTML Validator

(also validates XHTML)

W3C CSS Validator
W3C Accessibility Guidelines
Bobby Accessibility Validator
Tantek Çelik’s CSS box model hack
A List Apart’s Web Designer's Journey
BlueRobot’s CSS Layout Reservoir
Glish’s CSS Layout Techniques
Glish’s CSS Layouts: The Good, the Bad, and the Ugly
Owen Briggs’s Little Boxes visual layouts page
Owen Briggs’s Box Lesson Problem & Workaround Set

The WaSP thanks David Eisenberg, Tantek Çelik, and Jim Heid for research, suggestions, and moral support.

CAST OFF YOUR CHAINS! Well, anyway, quit spending so much time worrying about backward compatibility that your sites end up lacking forward compatibility — the ability to remain viable in upcoming browsers and devices.

For instance, is an attractive and expensively produced site designed to the quirks of 4.0 browsers and not updated since. As a result, users of newer, more compliant browsers are actually sent away (or told to get an old browser if they wish to see the site). This kind of coding does nobody any good: not the site’s owners and not web users.

If you're confused about (X)HTML, CSS, and validation, read the NYPL Style Guide. If you don’t understand the premise of authoring to common standards instead of to the peculiarities of individual browsers, read “Why Don’t You Code For Netscape?” at A List Apart.


Two methods are described below. One might be better suited to your site than the other. You can also evolve your own techniques. This page is just a starting point.

Method 1 (DOM SNIFF) is radical and is not appropriate for every site. What it does is redirect non–compliant browsers to an “upgrades” page—yours, or ours. If you use this method, we encourage you to create your own upgrades page, tailored to the needs of your particular audience.

Method 2 (INVISIBLE OBJECT) enables all visitors and devices to access your site’s content, but alerts visitors using non–compliant browsers to the existence and ready availability of better browsers. Used in combination with techniques (such as the atimport method) that protect bad browsers from Style Sheets they can’t handle, this can be an effective means of serving all users while encouraging upgrades and supporting standards.



After creating a valid web page, insert this script in the <head> of your document or somewhere in your global JavaScript file:

if (!document.getElementById) {
    window.location = 

In a global .js file, the code would look exactly like it does above. If you're inserting the script on an individual page, of course, you would type it between <head> and </head>. In HTML 4 or XHTML 1 Transitional documents, it would look like this:

<script type="text/javascript" language="javascript">
<!--  //

if (!document.getElementById) {
    window.location = 

	// -->

In STRICT documents, you’d either use a global .js file, or insert this:

<script type="text/javascript">
<!--  //

if (!document.getElementById) {
    window.location = 

	// -->

If you prefer, you can just as easily send visitors to an upgrade page on your own site:

if (!document.getElementById) {
    window.location = 

If you're creating pages that rely heavily on the W3C DOM and ECMAScript, those pages could fail in non-compliant browsers. On such a site, this technique would protect folks from viewing content their browser can’t handle.


If your pages don’t rely on advanced, standards–compliant scripting, using this technique might win you more enemies than friends, and you might prefer the “kinder, gentler” OBJECT method described later on this page.


W3C DOM–capable browsers will ignore this bit of fluff, because getElementById is a DOM method. Non–DOM-capable browsers will redirect the visitor to our Upgrade page ... or yours. There is no need to create a long, complex browser detection script because you’re not testing for browsers any more—you’re testing for compliance with W3C recommendations.


It’s foolproof in any JavaScript–capable browser, so long as the web user has not disabled JavaScript. You won’t have to worry about anyone in your audience seeing web pages their browser can’t handle. You might have to worry about a few angry letters, though.


Like we said, you might get a few angry letters. For that reason, we generally recommend the kinder, gentler, OBJECT method shown below. If you prefer to take a “belt and suspenders” approach, you can combine both methods.


This method lets everyone access your site, but alerts audience members using older browsers to the availability of standards–compliant ones. If you’ve separated style from structure by using CSS for layout and (X)HTML for markup, this method will also let users of older browsers know why the site looks different, while reassuring these users that you have no intention of abandoning them. The message is hidden from folks who use browsers that comply with W3C recommendations and have CSS turned on.


After creating a structurally valid HTML 4.x, XHTML 1.0, or XHTML 1.1 page, add an “ahem” declaration to your global Style Sheet, like so:

.ahem {
	display:	none;

Naturally, you can call it anything you like. You can call it “invisible.” You can call it “clauderains.” We just kind of dig “ahem.” Then in the <body> of your page, write something like this:

<h1 class="ahem">
This site will look much better 
in a browser that supports 
<a href=""  
title="Download a browser that 
complies with Web standards.">
web standards</a>, 
but it is accessible to any browser 
or Internet device.

The message will be hidden from CSS–compliant browsers as long as CSS is turned on. There is no possibility of crashing any browser, because all you’ve done is add a CSS class to an HTML headline. If you find it more appropriate, you can use a <p> or any other HTML element instead of an h1. We’re told that some versions of Netscape 4 on some platforms fail to support the “invisible” attribute when it is applied to a div.

If you’ve crafted your message carefully, it will not offend anyone. However, you may prefer to hide the message from standards–compliant (but limited) user agents like Lynx and iCab, from Palm Pilot and similar device users, and from those who use current browsers with CSS turned off. If so, in an HTML document, you might use an IFRAME instead of a <p>.

When doing something like this, consider your audience before anything else. What kind of message is likely to encourage them to visit your Upgrades page? What kind of message might turn them off? We think the following is a good one, but we encourage you to fine–tune it or replace it with your own:

This site will look much better in a browser that supports web standards, but is accessible to any browser or Internet device.

CSS browsers will read the Style Sheet, will see that the text is supposed to be invisible, and therefore will not display it. Older browsers will.


It’s kinder and gentler than forcing your visitors to go somewhere unexpected, and it leaves them with the choice. If visitors prefer to view your content in their old browser, they still can. The other nice thing about this method is that it works even when visitors have JavaScript turned off.


It takes guts to turn off your design in browsers that can’t handle it. And no matter how politely you word your “upgrade” message, some visitors will see it as an intrusion (and will see your having turned off the design as a “punishment”).

Supporting standards is easy: author to (X)HTML, CSS, and other specs, and validate your pages before publishing them. Handling the complex needs of your audience is not as easy. Good luck!

And now back to our regularly scheduled program.

» What is this? ::: » More info ::: » Browser Upgrades home

The Web Standards Project.