Building Extremely Backwards Compatibile Websites

Zach Flower wrote down some excellent tips for building "an absurdly backwards compatible website." (See also the Hacker News discussion.) His tips are good, but we can go to even greater extremes. My targets are the earliest web browsers: WorldWideWeb, XMosaic, Viola, and their ilk. Here's how to write for those beautiful dinosaurs.

Zach Flower's Tips

First, here are my brief restatements of Zach's very good tips:

Worry about vhosts

The earliest web browsers use the earliest version of HTTP. HTTP 1.0 and earlier contacts a server at an IP address and requests a document from it. It does not tell the server what domain that document is supposed to be from. So if your server hosts abc.com and xyz.com, what file should it send back when a browser just asks for /index.html? If you run your own host, you can work around this -- either by making your ancient-targeting site the fallback option when no domain is specified (which obviously only works for one site) or by acquiring another IP address so that each domain has its own IP. Neither is a great option, but they're the options we've got.

If you don't control your own server, you can find a host that doesn't give you a virtual domain. Realistically, that means hosting your site at something like abc.com/~yoursite rather than at yoursite.com or yoursite.abc.com. Find a tilde host! There are plenty of great ones out there.

Offer Unencrypted HTTP

Even fairly recent browsers (I'm talking a matter of years, not decades) lack the most recent TLS encryption/decryption capabilities, which means they can't connect to many secure sites. There are fairly good reasons to secure even a basic blog, but that doesn't mean you can't offer that content over plain HTTP as well. Do old devices a favor! Make it available! (You can even do this intelligently so that most browsers end up on HTTPS without the user having to pay attention to it.)

Hide Your CSS

Yes! Use CSS! Stick to semantic markup! But be aware that old browsers will simply display what you put between your <STYLE></STYLE> tags. You can mask it inline with HTML comment tags (<!-- -->) or you can import it from a separate file. I prefer the second solution, but it comes at the expense of offering styles to many versions of Internet Explorer. More on this below.

On that note, make sure your CSS (and your HTML for that matter) fails gracefully. For example, I use styled DETAILS tags on my academic page to make paper abstracts appear only when a paper's title is clicked. But DETAILS is only about a decade old. That's fine; I just count on older browsers seeing the abstracts, and I make sure the page is readable that way.

Use GIFs

Make your images .GIF format, or .JPG in a pinch. (And don't forget to give them ALT text!) All hope is lost for .PNG and other such modernisms. The good news: .GIF is a perfectly adequate file format for just about anything you might want to include an inline picture of.

Extreme Tips (or, my additions)

Now on to the hard core stuff.

Import Your CSS

CSS Hell lies between 1996 and sometime in the early 2000s. You want to make your pages look good with no CSS, with modern CSS, and, unfortunately, also with crappy, inconsistent CSS. Unfortunately (or fortunately?), targeting the insane and conflicting implementations of the early years of CSS is practically impossible. As a second best, however, you can hide it from some of the worst offenders.

I prefer to do this by importing my styles from a separate file:

<!--[if IE]><LINK REL=stylesheet TYPE=text/css HREF=/~tweedy/css/empty.css><![endif]--><!--[if !IE]><!--><style type="text/css"><!--@import "/~tweedy/css/base.css";--></style><!--<![endif]-->

• Using conditional comments, we hide styles from Internet Explorer by serving only it an empty style file. (IE for Mac is an especially bad CSS offender, and I don't care much for Internet Explorer in general, so I clear it all in one fell swoop. You can be more nuanced with the conditional targeting though.)
• Importing our CSS via an @import rather than a LINK reduces the clutter in Mosaic, which used LINK tags to represent the structure of a document split into multiple HTML files and so displays them all.
• I'll just mention that there are some arguments for not importing and using masked inline styles instead.

Use NOSCRIPT

One of my best friends is the <NOSCRIPT> tag. Only the oldest browsers lack Javascript, which means I can target them directly using this tag. Any hacks or styles that are only appropriate for ancient browsers can live here.

Need an extra line space where CSS is unavailable? No problem! Just wrap <BR> in <NOSCRIPT> tags.

Break the rules

Use (only) semantic markup, ok?! OK?!!!

But... know that there are necessarily (many) exceptions when targeting old browsers. You can break that rule sometimes, especially with NOSCRIPT already in your back pocket. Old browsers need to have the height and width of an image set in the IMAGE tag. Sometimes they need content CENTERed. Text might need to be Bold. It's the price of doing business in the '90s. (But please, stay away from TABLEs as layout machines. They don't even work in XMosaic!)

Use Javascript

Target your ancient browsers, and then use Javascript to replace things that are too out of date for modern use.

Relatedly, and perhaps surprisingly, Javascript ahem, ECMAScript is also your friend. For example, I have my email link point to a contact form, but I use (externally linked) Javascript to replace it with a spambot-shielded mailto link that works in modern browsers. I also link to a text version of my CV and use Javascript to replace it with a link to a PDF version instead. I also use Javascript to read and write URL search parameters as a way of keeping track of user stylesheet selections without resorting to cookies.

Linking your script using SCRIPT SRC='' keeps Netscape 2.x from raising errors for everything it doesn't understand. Avoiding attempted interpretation by Netscape 3.x is more difficult. I use:

if (navigator.userAgent.indexOf("Mozilla/3") != -1) { /* Hide from Netscape 3.x */ } 

to detect the browser and put the rest of my code in an else statement.

Netscape alleges that the LANGUAGE attribute can be used to target different versions of the browser, although this hasn't worked for me in limited testing. Here's the Netscape "DevEdge Documentation" for Navigator 4.0:

• Navigator 2.0 executes code within the <SCRIPT LANGUAGE="JavaScript"> tag; it ignores code within the <SCRIPT LANGUAGE="JavaScript1.1"> and <SCRIPT LANGUAGE="JavaScript1.2"> tags.
• Navigator 3.0 executes code within the <SCRIPT LANGUAGE="JavaScript"> and <SCRIPT LANGUAGE="JavaScript1.1"> tags; it ignores code within the <SCRIPT LANGUAGE="JavaScript1.2"> tag.
• Navigator 4.0 executes code within the <SCRIPT LANGUAGE="JavaScript">, <SCRIPT LANGUAGE="JavaScript1.1">, and <SCRIPT LANGUAGE="JavaScript1.2"> tags.

Ultimately, best to stick to relatively basic scripting.

One more note. Netscape 3 demands a special MIME type entry in order to not try to download your externally linked Javascript file to the desktop when the page loads:

# the following line is for early versions of Netscape
application/x-javascript			js

Ooph.

Combine Lines

This one's pretty niche.

The magic ingredient that makes this all work is the long history of practially all browsers ignoring tags they don't understand. Having said that...

MacWWW, the CERN browser for Macintosh, has the odd behavior of ignoring tags it doesn't understand but displaying a blank line if those tags are on their own lines in the HTML code. The first versions of HTML didn't even have <HEAD>, so if you want to do anything even as simple as give your document a <TITLE>, combine all those tags onto one very long line. Otherwise just think of all the visitors using MacWWW who will be greeted with too much white space!

DL 4EVA

In the beginning, HTML text was vertically spaced only by (empty element) paragraphs, never by lines. In other words, there was no such thing as a line break. And yet, even Tim Berners-Lee sometimes wanted to display text on a series of lines with no bullets, as (say) in a mailing address.

This was accomplished in the early days using description lists, which were, amazingly, part of the first HTML spec even though line breaks were not.

Here's how it works:

<DL>
<DT>Tim Berners-Lee 
<DT>Espl. des Particules 1 
<DT>1211 Meyrin 
<DT>Switzerland
</DL>

Notice that there are no descriptions (<DD>) to correspond to these 'terms' (<DT>). That's fine! What you get is a series of bits of text on subsequent lines. Without this, in very early browsers, your only other option is to accept paragraph spacing between lines of text:

Tim Berners-Lee

Espl. des Particules 1

1211 Meyrin

Switzerland

Final Thoughts

Targeting pre-1995 web browsers is clearly a fool's errand, but a fun one (for me, anyway). You can make functional, attractive web sites (if I do say so myself) while treating those visitors from 1993 as first-class citizens!

The spirit of the thing, though, can be for everyone: focus on your content, prioritize accessibility (for devices and people).

Today's web is in many ways a barren landscape full of barely useful snippets of text made to look like informative "articles" by being stuffed between advertisements and stock images. We can fight back by making our own websites look less like parallaxed travel brochures and more like the manifest pieces of human thought -- text! -- that they are.

See also: Gopher; Gemini

Relatedly: