I was away in Berlin for a few days, delivering a DOM Scripting workshop to the good people at Aperto. I had a good time, made even better by some excellent Spring weather and the opportunity to meet up with Anthony and Colin while I was there.
I came home to find that, in my absence,
rev="canonical" usage has gone stratospheric. First off, there are the personal sites like CollyLogic and Bokardo. Then there are the bigger fish:
Excellent! I’d just like to add one piece of advice to anyone implementing or thinking of implementing
rev="canonical": if you are visibly linking to the short url of the current page, please remember to use
rev="canonical" on that
A element as well as on any
LINK element you’ve put in the
HEAD of your document. Likewise, for the coders out there, if you are thinking of implementing a
rev="canonical" parser—and let’s face it, that’s a nice piece of low-hanging fruit to hack together—please remember to also check for
rev attributes on
A elements as well as on
LINK elements. If anything, I would prioritise human-visible claims of canonicity over invisible metacrap.
Actually, there’s a whole bunch of nice metacrapital things you can do with your visible hyperlinks. If you link to an RSS feed in the
BODY of your document, use the same
rel values that you would use if you linked to the feed from a
LINK element in the
HEAD. If you link to an MP3 file, use the
type attribute to specify the right mime-type (
audio/mpeg). The same goes for linking to Word documents, PDFs and any other documents that aren’t served up with a mime-type of
text/html. So, for example, here on my site, when I link to the RSS feed from the sidebar, I’m using
href="/journal/rss" rel="alternate" type="application/rss+xml". I’m also quite partial to the
hreflang attribute but I don’t get the chance to use that very often—this post being an exception.
rev="canonical" convention makes a nice addition to the stable of nice semantic richness that can be added to particular flavours of hyperlinks. But it isn’t without its critics. The main thrust of the argument against this usage is that the
rev attribute currently doesn’t appear in the HTML5 spec. I’ve even seen people use the past tense to refer to an as-yet unfinished specification:
rev attribute was taken out of the HTML5 spec
As is so often the case with HTML5, the entire justification for dropping
rev seems to be based on a decision made by one person. To be fair, the decision was based on available data from 2005. In light of recent activity and the sheer number of documents that are now using
rev="canonical"—Flickr alone accounts for millions—I would hope that the HTML5 community will have the good sense to re-evaluate that decision. The document outlining the design principles of HTML5 states:
When a practice is already widespread among authors, consider adopting it rather than forbidding it or inventing something new.
The unbelievable speed of adoption of
rev="canonical" shows that it fulfils a real need. If the HTML5 community ignore this development, not only would they not be paving a cowpath, they would be refusing to even acknowledge that a well-trodden cowpath even exists.
The argument against
rev seems to be that it can be confusing and could result in people using it incorrectly. By that argument, new elements like
footer should be kept out of any future specification for the same reason. I’ve already come across confusion on the part of authors who thought that these new elements could only be used once per document. Fortunately, the spec explains their meaning.
The whole point of having a spec is to explain the meaning of elements and attributes, be it for authors or user-agents. Without a spec to explain what they mean, elements like
A don’t make any intuitive sense. It’s no different for attributes like
rev. To say that
rev isn’t a good attribute because it requires you to read the spec is like saying that in order to write English, you need to understand the language. It’s neither a good nor bad thing, it’s just a statement of the bleedin’ obvious.
Now go grab yourself the very handy bookmarklet that Simon has written for auto-discovering short urls.