You are here because you are curious about the nuts and bolts of what makes my website work. Good for you.

My old website at Cornell, which was an unholy mixture of hand-hacked HTML and FrontPage autogenerated gibberish, Sucked greatly. This has since been corrected. You too should strive to Not Suck.

Design that Sucks

Much of the web, like everything else, sucks. There are various reasons for suckage. Some things we can do very little about, such as "this site contains no useful content," a chronic problem with me. However, there are other forms of suckage that anyone can do something about, and there's no reason not to do them.

Some say that personal web sites should be exempted from meeting any sort of minimal design standards because they reflect the personality of the creator. Nonetheless, many such pages Suck. I'd rather think that they suck due to ignorance, and not because the person behind the page has a callous disregard for other people.

Eric S. Raymond has a lengthier (and even less diplomatic) list of things that suck in web pages.

People who consider themselves web designers (I don't) would do well to make sure their page doesn't suck and is designed for accessibility. There is a pretty good book available online about designing accessible sites.

How I try not to Suck

Best Viewed in Any Browser

This page is best viewed in any standards-compliant browser. The whole point of the web standards is to avoid the Bad Old Days when websites looked right only in a specific browser. If we adhere to the public industry standards, things will look reasonable in any browser (even non-traditional browsers, like text readers for the blind). This is a Good Thing, and anyone who thinks otherwise is clearly monopolistic, misanthropic, or just plain uncaring of other people.

Standards-compliance isn't rocket science. The W3C CSS1 Specification dates back to 1996. The W3C HTML 4.01 Specification has been around since 1999. The CSS Level 2 Specification has been around since 1998. This is ancient stuff, but amazingly enough, some popular browsers still don't support it fully. The only reasons I can think of for professional designers not to use these (and newer) standards involve incompetence, laziness, a callous disregard for users, or all of the above.

If you can read this, you're probably running some flavor of Netscape 4. Please, for the love of God, try to upgrade to a newer browser. Almost any recent browser will be more standards-compliant than Netscape 4. Try Netscape 7, or Internet Explorer 6, or Mozilla 1.x.

The entire website validates as W3C HTML 4.01 Strict and W3C CSS1.

Here's a good page on why we need to move to standards-compliant browsers.

Browser Compatibility

I make an effort to test this site against every browser than I have easy access to, mostly because I am curious about how badly archaic software sucks. The quality of the visual presentation is directly related to the degree of compliance with published W3C specifications. Browsers will less or no compatibility will still be able to access all content, but with lower levels of visual appeal. It really doesn't matter all that much, as most of the content is text, and it still looks passable on a text console or cell phone or pretty much anything that understands HTML. It just won't be as pretty.

Basically, Mozilla (and derivatives), Netscape, Konqueror (and probably Safari), and probably Opera are fairly standards-compliant. Internet Explorer is somewhat worse, Netscape 4.x is horrible, and if you are using Lynx you'll get some reasonable textual representation.

Browsers that are compliant enough with W3C Recommendations to enable full functionality include:

The following browsers are sufficiently compliant to have no serious visual glitches, although some elements may appear slightly different from more compliant browsers.

The following browsers are not standards compliant. It won't be pretty, but you can still read it reasonably.

The following browsers will render little to no formatting. Users with these browsers will see mostly text.

Backwards-compatibility hacking

Netscape 4.x does not recognize media="all" in a <link rel="stylesheet" type="text/css" src=...> declaration. This behavior can be exploited to only load certain stylesheets if the browser is not Netscape 4.

Internet Explorer on Windows, up through at least version 6.0, is not fully CSS2 compliant. In particular, it does not understand CSS child selectors. This can be exploited to activate rules that Internet Explorer will not see. To do this, place the declaration in a separate statement and use a child selector on the body. For example, if I wanted to hide a rule on the foo class, I would declare body>foo { ... } in my stylesheet. Internet Explorer will not see this rule, but more standards-compliant browsers will, overriding existing attributes on foo.

The Making Of...

After sufficient pain with Microsoft FrontPage borking up all the code, I went looking for something better. Sadly, everything I tried Sucked, so as the old saying goes, if you want a job done right, do it yourself. Everything was redone by hand the right way using Emacs, the One True Text Editor.

No Microsoft products were used in the creation of this website.