After much struggle I've finally managed to get my blog to support comments and TrackBacks. (This is what I get for using "roll your own" blogging software). I'll blog some more later about how I did this, for any Blosxom users who happen to be interested; in the meantime please report any problems to me, either as comments on this post (if you're able to) or via email.
UPDATE: I now have a blog post describing the new Blosxom plugin I wrote to support comments and TrackBacks.
As many people can attest, sometimes you spend more time (and have more fun) tinkering with the underpinnings of a web site instead of actually writing new content to be posted on it. In that spirit, here is my current list of things I'm planning to add to or change about my web site and blog.
(I've left old items in place but simply marked them as deleted.)
The following are "must-haves":
.html in URI rewriting,
will use .var files if I ever need more than that)*.bak)make
remote-clean).xhtml vs .html based on Accept header?@import to
hide from Netscape Navigator 4.x)SEQUENCE file to generate prefixes on the fly when
copying over new or modified plugins)The following are desirable but not necessarily "must-haves":
Accepts: application/xml+xhtmlLast-modified headerETag headerExpires headerCache-control headerContent-length headerIf-modified-since check ourselvesIf-none-match check ourselvesETag as strong validatorIf you'd like to receive full-text articles from this site as they are published, you can subcribe to one or more of the following feeds, in the formats indicated; simply cut and paste the URLs into your feed reader of choice. The Atom feeds are preferred; I maintain the RSS feeds only for older news aggregators that are not yet Atom-enabled.
Note that I don't post new articles that often, so you should set your feed reader to check no more than once a day.
The basic principles I tried to follow in creating the this site were as follows:
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!)
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.)
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
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
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.)
This site is a mixture of static content and dynamic content served through the Blosxom blogging system. I use various URI rewriting rules and a number of Blosxom plugins (some slightly hacked) in order to implement the site according to my personal design philosophy.
As mentioned above, my site is (for the most part) powered either directly or indirectly by Blosxom. I use three different approaches to serving site content:
All weblog pages (including the site home page) are dynamically generated by Blosxom.
Most remaining (non-weblog) pages, eventually including all my writings, are statically generated by Blosxom, with the resulting HTML files then copied into the document root directory.
The remaining web pages and other files (e.g., images, PDF files, tarballs, and the like) are traditional static web content. Over time I'll migrate as many of these files as possible into Blosxom (among other things, so I can take advantage of Markdown for text formatting).
The site is hosted by an Intel server running Apache and Linux; since I administer the server I have complete control over the Apache configuration, and implement extensive URI rewriting to integrate the three types of content together in a reasonably seamless manner.
I use Subversion to maintain a version-controlled repository of all the files needed to (re)create the site. (One of the reasons I chose Blosxom was because it stores weblog content as regular text files in the file system--as opposed to in a relational database like a lot of other blog software--and thus is very appropriate for use with a version control system.) I then use GNU Make to automate pushing new content to the site or updating existing content.
My overall goal is that URIs used to request site content should be
entirely independent of the techniques used to serve the content; I
use URI rewriting to achieve this goal. In general, if a requested URI
refers to existing static content on the site then that content is
returned directly by the web server; otherwise Blosxom is invoked to
resolve the URL and generate the appropriate content. However there
are exceptions; for example, we force URIs referring to certain
pre-existing directories (e.g., /mozilla) to be instead interpreted
as Blosxom categories.
I implemented the URI rewriting rules directly in the httpd.conf
Apache configuration file (actually, in a file included by that
file). For more information, including the actual rewriting rules, see
my discussion of URI rewriting and canonical URIs.
I wrote two Blosxom plugins to implement my chosen URI scheme. The
extensionless plugin allows use of URIs without file extensions
to refer to individual entry pages. The canonicaluri plugin forces
redirects on category and date-based archive pages if the URI omits a
trailing slash, in order to emulate standard Apache behavior for URIs
referring to directories; it also forces a redirect if a URI for an
individual entry page includes a (spurious) trailing slash or an
unneeded .html extension.
I implemented the site layout using the techniques described in the article "Creating Liquid Layouts with Negative Margins" published on the A List Apart site. However I didn't implement the full set of techniques because I wasn't using background colors or images.
Here I document the way in which I use URI rewriting (along with redirection and a couple of Blosxom plugins) to help implement my personal design philosophy for my web site. My goal is to create a unified URI space within which static and dynamic content can transparently co-exist, with publicly-visible URIs for human-readable content (i.e., HTML pages) having a canonical form that omits file extensions or other content type specifiers.
Achieving this goal requires solving two separate problems: intermixing dynamic and static content (in my case, Blosxom-generated and non-Blosxom content) in the same URI hierarchy, and recognizing and enforcing preferred canonical forms for URIs.
As an example of freely intermixing dynamically-generated content and
static content (e.g., images) within the same URI hierarchy, consider
a Blosxom-based web site where http://www.example.com/foo is a
Blosxom category, /foo/bar.html is the HTML page displayed for an
individual Blosxom entry in that category, and /foo/baz.jpg is an
image referenced by that entry. (We assume that the site is already
using one of the suggested techniques for hiding the
/cgi-bin/blosxom.cgi part of the URI.) With Blosxom there are at
least two possible approaches to support such intermixing.
One approach would be to invoke Blosxom (i.e., blosxom.cgi) for each
and every URI processed, and then to use the binary plugin or the
static_file plugin based on it; these Blosxom plugins check to see
if a requested URI corresponds to an existing file in the file system
and, if so, they return the file's contents as the output (as opposed
to trying to generate a Blosxom page).
The second possible approach is the reverse: Have Apache serve up
existing files (and indices for existing directories), and invoke
Blosxom only when the URI references a file (or directory) that
doesn't exist. This is the approach I've taken, for various reasons;
in particular, I wanted to avoid the overhead of invoking Blosxom for
each and every URI. This approach is also compatible with a strategy
of converting all or part of the Blosxom-managed content into static
files. For example, one could run blosxom.cgi in static mode to
generate files and directories under the Apache document root; Apache
would then serve up those files and directories just as it would
non-Blosxom content.
We want to enforce the following rules for how URIs should be represented:
URIs used to access HTML content for directories, Blosxom
categories, and Blosxom date-based archive pages should have no
index.html component and one (and only one) trailing slash:
http://www.example.com/foo/
http://www.example.com/foo/2004/11/14/
URIs used to access HTML content for static web pages and individual
Blosxom entries should have no .html extension and no trailing
slash:
http://www.example.com/foo/bar
URIs used to access all other (non-HTML) content should have
filename extensions; index.* components should be included for
directories, Blosxom categories, and Blosxom date-based archives,
etc.:
http://www.example.com/foo/baz.png
http://www.example.com/foo/index.rss
http://www.example.com/foo/2004/11/14/index.rss
Enforcing these conventions is relatively straightforward: if a requested URI does not follow the above rules then we simply force a redirect to the canonical URI. However determining whether a URI is already in the proper canonical form or not is less straightforward, especially when we intermix Blosxom and non-Blosxom content.
For example, if the URI http://www.example.com/foo/bar is requested
then we have to do the following checks:
/foo/bar an existing directory?/foo/bar.html?/foo/bar a Blosxom category?/foo/bar.html?In practice we do these checks in the order shown, both to eliminate
ambiguity (for example, if there's a directory /foo/bar and also a
Blosxom entry /foo/bar.html) and also because it's easier to
implement: The first two checks are done by Apache in the course of
doing URI rewriting, and the second two checks are done by a Blosxom
plugin once the URI has been passed off to Blosxom for processing.
Here's the overall strategy we follow in doing URI rewriting:
We divide requests into those that can be satisfied by returning a
static file or directory index and those that are for
dynamically-generated content; the latter are rewritten into URIs
that invoke the necessary CGI script (blosxom.cgi). Note that in
some cases we can make an immediate determination as to whether
content is static or dynamic, while in other cases we have to wait
for the results of subsequent URI rewriting rules.
If a request references an existing directory then if necessary we force a redirect to the canonical URI for the directory, namely a URI with one (and only one) trailing slash after the directory name.
If a request is for an existing index.html file then we force a
redirect to the canonical URI for the directory in which that file
is located.
If a request is for any other existing HTML file then we allow and
require that the .html file extension be omitted. If the .html
file extension is included in the requested URI then we force a
redirect to the canonical URI for the file, namely a URI that omits
the .html file extension and has no trailing slashes.
If a request is for an existing file (or a symbolic link to a file) then it is handled by Apache in the normal way. Any other requests are passed to Blosxom for processing.
Blosxom (actually, a Blosxom plugin) then performs its own set of checks on URIs, and rewrites URIs and/or forces redirects if needed.
Before I discuss the URI rewriting rules themselves, here are various
points to keep in mind when reading the rules; some of these points
are not necessarily immediately apparent from reading the
documentation for the mod_rewrite module and the
Apache URL Rewriting Guide:
In our case we have root access to the system and can put our
rewriting rules in the master Apache configuration file
(httpd.conf). These rules will not work as is if you do not have
root access and have to put your rewriting rules in a .htaccess
file. (I don't have time to revise the rules to work for the
.htaccess case, but perhaps someone else can do so; unfortunately
URI rewriting in a .htaccess file is much more complicated than when
done in httpd.conf.)
RewriteRule directives are evaluated in order looking for a match of the URI against the left-hand side of the RewriteRule directive. RewriteCond directives are looked at only if the corresponding RewriteRule directive matches. If the left-hand side of the RewriteRule directive matches and the corresponding RewriteCond directives (if any) evaluate true, then the URI is rewritten into the form specified by the right-hand side of the RewriteRule directive. Otherwise Apache just goes on to the next RewriteRule.
The URI matched against the RewriteRule directives is not the full
URI but rather just the path component of the URI; it does not
include either the hostname part or any query string. Thus, for
example, if the original request was for
http://www.example.com/foo/bar?flav=baz then the RewriteRule
directives will be matched against /foo/bar. (At least this is
true in my case; this works slightly differently if you have to put
your rules in a .htaccess file.)
Rule matching is done using regular expressions modeled on those in
Perl. However Apache doesn't support the full range of Perl regular
expressions, and in particular doesn't support any options to
address the "greedy matching" problem. For example, if you match
URIs against an expression like ^(.*)//?$ (for example, to detect
excess trailing slashes) then for a URI like /foo// Apache will
assign $1 to be /foo/ instead of /foo as we'd like. We have to
hack around this problem as described in the next section.
Once we have rewritten a URI to our satisfaction we normally want to
stop URI rewriting at that point, and use the the L ("last") flag
to do this; otherwise Apache would continue evaluating RewriteRule
directives looking for further matches. However using L by itself
is normally not sufficient to get Apache to do the right thing;
typically we have to include other flags as discussed below.
Normally once rewriting ends Apache will simply take the (possibly
rewritten) path component of the URI and append it to the defined
"document root" value (i.e., the directory where static web content
is located). This causes a problem if the URI actually refers to a
path for which an Apache Alias or ScriptAlias directive is
defined. (For example, on my server /cgi-bin is not in the main
document root, but is located elsewhere as defined by a ScriptAlias
directive.) To fix this we use the PT ("pass through") flag where
needed to tell Apache to first pass the URI through to the
mod_alias module.
If the URI refers to an existing directory then after the first
round of rewriting ends the Apache mod_dir module will initiate
so-called "subrequests" for URIs with index.html, etc., appended,
and each subrequest will start a new round of rewriting. We don't
want to have any of our rewriting rules invoked in that case (among
other things, this can lead to problems with looping), so we also
use the NS ("no subrequest") flag to note that our rules should
not be invoked for such internal subrequests.
In some cases we don't simply want to rewrite the URI, we want to
correct perceived mistakes in how the URI was originally
requested. (For example, we want all URIs referring to existing
directories to end in one--and only one--trailing slash.) For these
cases we use the R flag to tell Apache to redirect the user's
browser to a new and corrected URI. (We actually use R=301 to
specify the HTTP code returned, in this case a code meaning "the URI
has permanently moved".) In combination with the L flag this
immediately ends rewriting for the original URI; a new round of
rewriting starts once the browser requests the new URI.
Here are the actual Apache URI rewriting rules we use, in order of evaluation and application:
We first enable the rewriting engine and specify a location for logging rewriting actions:
RewriteLog logs/hecker_error_log
RewriteLogLevel 0
RewriteEngine on
Note that RewriteLogLevel should be set to a non-zero value to enable logging; a loglevel value of 9 produces lots of output and can be very useful when debugging rewriting rules and/or learning how rewriting works.
Also note that the RewriteBase directive is not needed here
because we are specifying rewriting rules in the httpd.conf
configuration file; RewriteBase is typically needed only when
specifying rewriting rules in a .htaccess file.
We start the process of handling trailing slashes by stripping all but the last two trailing slashes off of all URIs:
RewriteRule ^(.*)/// $1// [N,NS]
The form of this rule is a hack to get around the "greedy matching"
problem described above, which prevents us from using the regular
expression ^(.*)//+$ for this purpose. For any URI ending in at
least three slashes, we rewrite the URI to remove a trailing slash
and then use the N ("next round") flag to restart rewriting from
the beginning. Since this is the first rule this simply repeats the
rule until no more than two trailing slashes remain on the URI.
Why stop at two, as opposed to removing all but one slash? Because we want to keep track of URIs with excess trailing slashes and force a redirect further on down; hence we leave at least one excess slash on the URI.
We protect against potential XST cross-site scripting attacks by
rejecting all HTTP requests with either the TRACE or TRACK
methods. (See the relevant WhiteHat Security press release
and a related VulnWatch list posting.) The F flag causes
Apache to immediately send back an HTTP response of 403
("FORBIDDEN"). (The L flag is not needed here because the F
flag causes rewriting to stop automatically.)
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F,NS]
We eliminate duplicate trailing slashes at the end of URIs by redirecting to a new URI with only one trailing slash, to enforce canonical forms for directory URIs and also get rid of some potential problems when requesting Blosxom pages.
Note that the first rule above guarantees that by the time we get to this rule we'll never see more than two trailing slashes on a URI.
RewriteRule ^(.*)//$ $1/ [L,R=301,NS]
We don't attempt to do rewriting of URIs that are handled
separately and do not correspond to either Blosxom content or
content in our document root. In particular, we don't attempt to
rewrite /cgi-bin/... or /usage/... URIs (for which we define
aliases for the virtual host associated with the site) or
/icon/... URIs (for which httpd.conf defines a server-wide
alias). Instead we just pass these URIs through to be handled by
mod_alias.
Note that there is also a server-wide alias for /manual/ but we
ignore this since we aren't serving up a copy of the Apache
documentation. (We include /icons/ because it is needed for
auto-generated directory listings.)
RewriteRule ^/(cgi-bin|icons|usage)(/.*)?$ - [L,PT,NS]
We have Blosxom override the directory index for / (the home
page) and other existing directories that should be treated as
Blosxom categories instead. (References to other stuff under those
directories, including index.html pages, is handled below.)
Note that these rewrite rules must come first in order to handle these special cases before we check for existing directories in general. The URIs may or may not have a trailing slash; we need to handle both cases. We pass any trailing slash on to Blosxom, which can then force a redirect if the trailing slash is omitted; we do it this way (rather than forcing a redirect here) so that such redirection can be done consistently for all Blosxom categories.
Also note that in order for Blosxom to produce the correct results
the directories in question should not have any index.* files
within the directory. Further on down we explicitly handle the case
where an index.html page is requested (by redirecting to the
canonical URI without index.html) but references to other
index.* pages (e.g., /misc/index.rss) will not return the
corresponding Blosxom page if a file of that name is already
present in the directory.
RewriteRule ^(/?)$ /cgi-bin/blosxom.cgi$1 [L,PT,NS]
RewriteRule ^/(blosxom|misc|mozilla)(/?)$
/cgi-bin/blosxom.cgi/$1$2 [L,PT,NS]
We next check to see if the URI corresponds to an existing directory under the document root. If so and the URI has a trailing slash then we simply stop rewriting and use the URI as is; otherwise we add a trailing slash and force a redirect to the new URI.
Note that we can't use %{REQUEST_FILENAME} in the directory
existence check because that variable has not yet been set; hence
we have to explicitly append the URI to the document root pathname.
ReWriteCond %{DOCUMENT_ROOT}/$1 -d
RewriteRule ^/(.*)/$ - [L,NS]
ReWriteCond %{DOCUMENT_ROOT}/$1 -d
RewriteRule ^/(.*)$ /$1/ [L,R=301,NS]
If the URI is explicitly requesting an index.html file for an
existing directory (e.g., /foo/index.html) then we force a
redirect to the canonical URI for that directory (e.g., /foo/).
Note that we catch the case where the URI (incorrectly) includes a
trailing slash (e.g., /foo/index.html/), and redirect that to the
canonical URI as well. Note also that skipping this rule on
internal subrequests is particularly important; otherwise we'd
cause major looping problems with URIs requesting directory
indices.
ReWriteCond %{DOCUMENT_ROOT}$1 -d
RewriteRule ^(.*)/index\.html(/?)$ $1/ [L,R=301,NS]
We check to see if the URI is explicitly requesting an existing
HTML file (e.g., /foo/bar.html where bar.html exists). If so
then we force a redirect to the canonical URI for the file, without
the .html file extension (e.g., /foo/bar).
As with the previous rule, we properly handle the case where the URI (incorrectly) includes a trailing slash, and we make sure to avoid problems with internal subrequests for directory index URIs.
Finally, note a minor bug in the rule: It incorrectly rewrites a
URI like /foo/.html that references a hidden file named .html;
I chose to ignore this uncommon (and arguably nonsensical) case.
ReWriteCond %{DOCUMENT_ROOT}/$1.html -f
RewriteRule ^/(.*)\.html/?$ /$1 [L,R=301,NS]
We check to see if the URI corresponds to an existing HTML file
after adding a .html extension. If so, we rewrite the URI to
include the extension and pass it through to Apache.
Again we properly handle the case where a trailing slash has been
incorrectly added. Also note that we use the OR flag on the
RewriteCond directive because we are checking to see if the URI
references a regular file or a symbolic link; by default all
RewriteCond directives must evaluate true in order for the
corresponding rewriting rule to be invoked.
RewriteCond %{DOCUMENT_ROOT}/$1.html -f [OR]
RewriteCond %{DOCUMENT_ROOT}/$1.html -l
RewriteRule ^/(.*)/$ /$1.html [L,R=301,NS]
RewriteCond %{DOCUMENT_ROOT}/$1.html -f [OR]
RewriteCond %{DOCUMENT_ROOT}/$1.html -l
RewriteRule ^/(.*)$ /$1.html [L,NS]
We check to see if the URI corresponds to any other (non-HTML) existing file or symbolic link and, if so, we force a redirect if a trailing slash is present.
RewriteCond %{DOCUMENT_ROOT}/$1 -f [OR]
RewriteCond %{DOCUMENT_ROOT}/$1 -l
RewriteRule ^/(.*)/$ /$1 [L,R=301,NS]
Finally, we pass the URI on to Blosxom if it does not correspond to an existing (non-HTML) file or symlink.
RewriteCond %{DOCUMENT_ROOT}/$1 !-f
RewriteCond %{DOCUMENT_ROOT}/$1 !-l
RewriteRule ^/(.*)$ /cgi-bin/blosxom.cgi/$1 [L,PT,NS]
This concludes the rewriting rules.
Once Apache has concluded all rewriting (including further rewriting done for new requests due to redirects) all URIs should be in one of the following forms, and are handled as indicated:
Canonical URIs for existing directories (e.g., /foo/). Each such
URI is subsequently processed by the mod_dir module, which will
attempt to look for a directory index file as specified by the
DirectoryIndex directive. The mod_dir module may generate
internal subrequests, e.g., for /foo/index.html, but these will
not invoke our rewriting rules.
If mod_dir cannot find an index file then a directory listing will
be generated by the mod_autoindex module if the
Indexes option is specified for the Options directive.
URIs for existing HTML files (e.g., /foo/bar.html) rewritten from
the canonical form of such URIs (e.g., /foo/bar). Each such URI is
handled normally by Apache (without going through mod_alias,
since there's no need to do so).
Canonical URIs for existing non-HTML files (e.g.,
/foo/baz.png). Each such URI is handled normally by Apache (again
without going through mod_alias).
URIs to be handled by Blosxom (e.g.,
/cgi-bin/blosxom.cgi/foo/). Each such URI is passed to mod_alias
(to determine the location of the cgi-bin directory) and then the
blosxom.cgi script is invoked with the path specified (e.g.,
/foo). Note that the path in question is not necessarily (yet) in
canonical form, except that it is guaranteed not to have more than
one trailing slash.
Other (non-Blosxom) cgi-bin URIs or other URIs needing further
translation (e.g., /icon URIs for images in auto-generated
directory listings). Each such URI is passed to mod_alias.
Once a URI is passed to Blosxom then we have to do the same sorts of URI checks, rewriting, and/or redirection done by the Apache URI rewriting rules. We divide this work into two separate plugins:
The extensionless plugin checks requests for which the requested
URI lacks a flavour extension (e.g., /foo/bar) and adds the
appropriate flavour extension (.html in our case) to the variable
$blosxom::path_info if there is an individual entry corresponding
to that URI.
The canonicaluri plugin checks URIs to see if they are in canonical form and forces a redirect if necessary.
For more information see the documentation for those plugins.
I've tried to make this site accessible to as many people as possible; here I describe the accessibility features of this site. (This statement is based on Mark Pilgrim's accessibility statement.) If you have any questions or comments about the accessibility of this site, feel free to email me at hecker@hecker.org.
Most browsers support jumping to specific links by typing special key combinations defined on the web site. On Windows, you can press ALT + an access key; on Macintosh, you can press Control + an access key.
The home page and all archives define the following access keys:
(Note that I didn't define an access key to skip to the main content because the main content is already the first thing on the page.)
I intend to ensure that all pages are Bobby AAA approved. More on that later as I complete the necessary work.
I intend to ensure that all pages are Section 508 compliant. More on that later as I complete the necessary work.
The home page and blog archives validate as HTML 4.01 Strict. (Some older pages on the site have not yet been modified to validate properly.)
The home page, blog archives, and other pages use structured semantic markup. For example, on pages with more than one entry H2 tags are used for individual post titles, so that JAWS users can skip to the next post with ALT+INSERT+2.
All blog archive pages have rel=home links to aid navigation in
text-only browsers and screen readers; I may add rel=previous,
next, and up links in the future. (Unfortunately prev and
next in particular are not simple to implement in Blosxom, the
blogging system I'm using.) Mozilla users can take advantage of
this feature by selecting the View menu, Show/Hide, Site Navigation
Bar, Show Only As Needed (or Show Always). Opera 7 has similar
functionality.
The home page and all archive pages include a search box (access key 4).
Many links have title attributes which describe the link in greater detail, unless the text of the link already fully describes the target (such as the headline of an article).
Whever possible, links are written to make sense out of context. Many browsers (such as JAWS, Home Page Reader, Lynx, and Opera) can extract the list of links on a page and allow the user to browse the list, separately from the page.
Link text is never duplicated; two links with the same link text always point to the same address
There are no "javascript:" pseudo-links. All links can be
followed in any browser, even if scripting is turned off.
There are no links that open new windows without warning.
This site and all its archives use cascading style sheets for visual layout.
The style sheets for this site do not specify a base font size, and use relative font sizes to specify the appearance of headings and related text. Text on this site should be resizable in any browser that permits text resizing.
If your browser or browsing device does not support stylesheets at all, the content of each page is still readable.
In creating this site I made use of Mark Pilgrim's "Dive Into Accessibility" book and related materials. See the book for a complete list of other references.