The Fragile Link vs. The Sloppy Link, or, Ode to Links

One of the doyens of the web is worrying about “link rot.” Link rot and crappy URLs (or whatever TLA they’re going by at the moment) are a terrible plight on the web. Amazon, of all places, still manages to have crappy looking URLs even though they seemed to have added in book “slugs.” Blogging software, so far, has been the most consistent in it’s success of making URLs that make sense to humans, most notably WordPress.

Now, as Koranteng can tell you, I have no problem asking questions like “is the head of a needle wide enough to warrant a closing tag, or is it so small you need an empty tag?”

Thinking You’re a Whole When You’re Really a Part

Here’s one that’s vexed me over the years:

• You have id and name.
• Both conveniently allow you to create anchors, so you could create URLs directly to sections in your content.
• I hear that id is cooler than name, esp. in XHTML 1.0.
• The value of a name or an id has to be unique within the scope of the entire page. Otherwise, how do you figure out which one to go to?
• Blogging software will list a post on it’s own, or, in a long list of other posts.
• So, if I start adding name‘s and id‘s to my posts — which I’d love to make myself starting doing, at least to the headers — eventually, I’m going to start creating pages where there are name‘s and id‘s with the same value.

For example, I may write two separate posts on linking. In each, I write up a section about using links as jokes. I label that section:

<h2 name="links-as-jokes">Nerd Humor</h2>

Then, when those two posts appear on the main or archives page with each other, I’ll have broken the sacred trust with the spec! Ack!

Hobos and Home Owners

But, back to links. Tim has a fantastic point about link rot. I’ve fretted about the life-span of links I use since writing HTML. My problem with linking to wikipedia, which I always want to do for exactly the reasons of stability that Tim points out, is that it’s boring. Not boring by nature, but relatively so. I use links, and obviously, the page that link leads to, as part of the content I’m working on. A link might:

• Help me when I’m lazy or want to keep a post concise. Why explain what ITIL is when I can link to it.
• I want an unbiased (save it!) write-up.
• Or, I want myself to look unbiased in my linking. If I only linked to RedMonk clients, things would start to get fishy.
• I’m feeling nasty and want to link to something with-out giving link-juice to the subject.

On to the idea of permanence, though. Who hasn’t been hit by that? I’m sure I’ve brought down pages and moved links around myself. There seems to be two camps when it comes to the transient vs. permeant status of links. Tim likes things to be permanent, as with most of the elders of the web who remember it’s origin as a body of record vs. entertainment. That link should last. This makes sense, an author looks silly to their readers if a link gives you the deadly 404.

The Twitter Example

I’d say I’m in the permanent camp myself. As I alluded to above, links to me are often like memory and, better, pointers to specific moments in time. For example, though they make it a bit difficult to ferret it out, you can link to any status update in Twitter. That makes it handy to connect together a “tweet” to a post or anything else.

What would otherwise seem ephemeral and useful for only a moment becomes useful “forever”: “going to lunch,” “up early,”, etc. (question, do the quotes belong in the link or outside? “fighting with logons” vs. “fighting with logons?.” Now, those are kind of silly examples of something you’d care about being permanent, but they work well as fodder when you’re writing in that ongoing narrative/flow style of blog posts where your jumping in and our of conversations. Updates link this one are much more interesting.

As a side note, being URL addressable is one of the things that makes web-heads like me get excited about any system. Perhaps, it’s one of the reasons that Flash heavy web apps give me a slight feel of unease. Sure, you can do the application such that things are URL addressable, but I’m not sure that’s the norm, default, or expected behavior. It’s certainly a worst practice on straw-man Flash sites so it’s something to guard against.

Back to the Point

I’m being lazy here as (a.) Tim’s original post is from over a week ago, and, (b.) I haven’t read through all the comments or new posts to see what the resolution is, though, scrolling through I saw “RDF,” “OASIS,” and “Socrates” which made me think “uh-oh.” But, my suggestion is to just use Grease Monkey to solve this problem.
move it to the client with grease monkey.

The idea would be this: if a link has gone dead, the Greasemonkey script would re-link bad links to a wikipedia entry. Now, we could get all nutty with “levels of indirection” sprinkled with simplicity and add in rel keywords (describing the relationship intended?) to help the script find the right entry in wikipedia, but just using the link text would be “good enough” in my book.

The thing I’d want to avoid in the operational thinking of choosing a link is feeling like I had to link to wikipedia for permanence (in the current time at least) when another link would be funnier or otherwise work better, even though it felt transient.

Sure, that will only solve the problem for the people who use it Greasemonkey. I suppose you could add such stuff on the server side, scanning old blog entries and updating links as the original ones went dead. Greasemonkey would be more interesting as it’d mean I, or you, could use it on any site. Maybe it’s time for Fourth Voice…?

Disclaimer: Sun, where Tim works, is a client.

Technorati Tags: greasemonkey, hobos, html, linking, links, pdf, twitter, wikipedia