UPDATE 2023-03-27: This page is obsolete, as it refers to a prior version of this blog. However, it may be of historical interest.

The basic principles I tried to follow in creating the this site were as follows:

  • The site should be entirely text-based, with minimal or no use of graphics.
  • All web pages on the site should validate as HTML 4.01 Strict.
  • All web pages on the site should be accessible using URIs that hide the details of the particular content type or page generation mechanism associated with the page.
  • The site should be a transparent upgrade from my previous site (created a few years ago), so that all previous URLs should continue to work.

The following sections expand on these points:

Text-based site

When it comes to designing a web site, I have an unfortunate problem: I very much appreciate good graphic design but am utterly incapable of actually doing graphic design. I guess I could try stealing (I mean, “taking inspiration from”) someone else’s design, but unless I did a literal copy I’d probably mess up the design in the process of reusing it.

I’ve therefore decided to avoid the problem entirely and just create an entirely text-based site using a minimal design, minimal enough that hopefully I won’t screw it up too badly. As a side benefit this means that the site should load faster; this may help offset the penalty of doing URL rewriting and dynamic page generation for the weblog.

(Note that if some graphic designer out there wants to help me create a better looking site, whether on a volunteer basis or for a fee, I’d be happy to entertain any offers!)

Use of HTML 4.01 Strict

Since I volunteer for the Mozilla project I feel it’s incumbent on me to support the use of web standards; this would also show off the standards support in Firefox and the browser component of the Mozilla Suite. I then faced the choice between using HTML 4.01 or XHTML 1.0 (or XHTML 1.1 if I wanted to be truly au courant).

In the end I was swayed by Ian Hickson’s comments on XHTML and decided to use HTML 4.01 Strict. I did do some experiments in serving HTML or XHTML depending on the browser; in particular, I implemented a test Blosxom plugin to do content negotiation and send back content of the appropriate type depending on what the browser would accept. (The plugin works by checking the HTTP Accept header and tweaking the Blosxom ”flavour” value appropriately.) However in the end I decided it wasn’t worth the trouble.

(Briefly, the problem is that some browsers that can properly interpret the XHTML content type application/xhtml+xml, like Safari and Opera, don’t indicate an explicit preference for that content type over the HTML content type text/html. But if a browser doesn’t indicate an explicit preference then we have to send HTML; otherwise we’d break Internet Explorer. So we can’t take advantage of the XHTML support in Safari and Opera without doing browser sniffing; the more “pure” approach using just content negotiation works only for Mozilla, Firefox, and other browsers that explicitly indicate a preference for XHTML.)

Cool URIs

My guides in designing a URI scheme have been Tim Berners-Lee’s essay “Cool URIs don’t change” and Jakob Neilsen’s essay “URL as UI.”

I haven’t taken all their advice; in particular, I didn’t want to implement the full date-based URI scheme recommended by Berners-Lee, or the use of a spell-checking web server as recommended by Neilsen.

These are the principles I’m trying to follow:

  • allow file extensions to be omitted on all site URIs, e.g., .../site/design-philosophy instead of .../site/design-philosophy.html

  • use only lower-case alphanumeric text in URI path components, with a hyphen used to separate words, e.g., design-philosophy instead of design_philosophy, DesignPhilosophy, or (worst of all) design%20philosophy.

  • hide the fact that Blosxom (or some other mechanism) is being used to generate pages, e.g., .../site/design-philosophy instead of .../cgi-bin/blosxom.cgi/site/design-philosophy

  • use a flat one- or two-level hierarchy for organizing the site, e.g., .../mozilla/foo instead of .../computers/internet/browsers/mozilla/foo

Transparent upgrade

I’ve had my web site active for several years, and in some cases I’ve published articles that other people have linked to. I wanted to turn my home page into the index page for my weblog, and have category index pages under that, e.g., http://www.hecker.org/mozilla/ for my Mozilla-related blog postings. However at the time I needed to ensure that the URIs for existing directories and files would still work.

In particular, I wanted to ensure the following:

  • all URIs for existing documents (e.g., http://www.hecker.org/info/bio.html) would continue to return the appropriate document
  • all URIs for existing directories (e.g., http://www.hecker.org/writings/) would return either the existing index page or (optionally) an index page for a blog category (e.g., http://www.hecker.org/mozilla/)
  • all other URIs would be considered as requests for blog-related pages

Implementation

See the site’s colophon for more information on how I put the above philosophy into practice. (In short, it involves using the Blosxom blogging system and lots of URI rewriting.)