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:
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.)
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.,
use only lower-case alphanumeric text in URI path components, with a hyphen used to separate words, e.g.,
DesignPhilosophy, or (worst of all)
hide the fact that Blosxom (or some other mechanism) is being used to generate pages, e.g.,
use a flat one- or two-level hierarchy for organizing the site, e.g.,
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.,
- all other URIs would be considered as requests for blog-related pages
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.)