OOCSS and HTML semantics

If you deal with CSS at all, I urge you to watch the video of Nicole Sullivan’s presentation at Webstock this year (and follow along with the slides on Slideshare). It’s only half an hour long, and it is an eye-opening summary of the problem of massive, sprawling CSS.

One of the core principles of progressive enhancement as a technique for web development is the separation of content (HTML), presentation (CSS), and behaviour (JavaScript). The CSS Zen Garden is the canonical shining example of how CSS can be used to completely transform the appearance of an HTML document, without having to make any changes to the underlying HTML. The problem is, this is an unrealistic example.

In the real world, we have to deal with documents and designs that change from month to month. If you are laying down a one-off site, then your CSS can be as weird and sprawling as you like, but many of us don’t have that luxury. Our CSS has to be comprehensible to our colleagues, our successors, and ourselves in 12 months’ time. It has to be structured and meaningful, and you shouldn’t have to understand all of it, or use a debugger (web inspector/Firebug) just to make a simple change.

The principle of separation of content and presentation says nothing about how to keep your CSS organized in a highly fluid environment. Just because the ground rules of CSS are easy to understand, doesn’t mean that it is easy to work with in the large. When it comes to modularity and re-use, CSS as a language doesn’t even have variables, for goodness’ sake.

My own take on this, a few years ago, was to advocate a highly modular way of writing CSS, where each “content block” (a header, a sidebar list, a blog entry) uses a completely isolated set of CSS rules. By isolating each content block, you don’t have to go hunting all over the place to find the style rules that apply to the block you’re working with, and you know that any changes you make won’t impact the rest of the site.

But as Nicole points out in her presentation, this is exactly what leads to massive CSS code bloat, and sites that declare font-size:12px 700 times. In general, more code means more bugs. On the web, more CSS code means increased download times. And although JavaScript is more often the performance killer for a typical web page, complex CSS can have a significant impact on page render times, and poorly considered CSS changes triggered by JavaScript can trigger expensive reflows.

It has taken me a while to understand the lessons Nicole has been teaching, but I now generally prefer the object-oriented style of writing CSS, although I don’t always use the full OOCSS framework itself. (I’m also not mad about the “object-oriented” name, because I think it gives the wrong impression. It is defintely about objects, but “object-oriented” has too much other baggage. I often find it easier to explain the concept as “inside-out” thinking instead of “outside-in”.)

One of the hardest hurdles to leap in coming to like OOCSS was the somewhat heretical notion of adding “non-semantic” container elements and apparently “presentational” classnames to my HTML. What finally reversed my discomfort was the realization that “semantic HTML” is not just one thing. There are, in fact, many different layers of semantics that go into HTML, and in fact belong in there:

  • Structural semantics are represented by the core HTML elements that define the document outline: headings, paragraphs, lists, tables. HTML5 adds articles, sections, figures, and other sexy stuff. To be honest, these new structural semantics have always been my favourite part of HTML5, because they make it more flexible to represent old-fashioned documents, and make it more likely that what we humans write now will be readable and comprehensible in the really long term.
  • Ontological semantics are layers of domain-specific meaning that add information about what a piece of structural markup is in the world beyond the document outline. A <section> might represent someone’s contact information, an event, or a menu of options. Microformats and ARIA roles are just a couple of widely used examples that happen to be standardized. No doubt you have come across many other examples of site-specific semantic classes, like <section class="account"> or <ul class="orders">.
  • Visual semantics represent the intent but not the implementation of the visual hierarchy of a document. This is the difference between <div class="rounded"> and <div style="border-radius:5px">. Or, to take a concrete example from the OOCSS framework, why it’s okay to do something like <h2 class="h3">. What you are saying with that piece of markup is that structurally, this header is at the second level of the document outline, but visually it should be less important — perhaps because the section in which it appears is located in a sidebar rather than in the main body.

Just because you use visual semantics does not mean you have to abandon ontological semantics. The two complement each other very nicely. But favouring visual semantics for styling (ideally derived from a style guide) means you can minimize your CSS by writing one-off rules like this:

h3, .h3 {
    font-size: 146.5%;
    font-weight: normal;
    font-style: normal;
    color: #DF2B72;

instead of repeating yourself in location-dependent styles like this

#order h3 {
    font-size: 146.5%;
    color: #DF2B72;
#sidebar .upsell h2 {
    font-size: 146.5%;
    color: #DF2B72;

The really hard part about doing it this way is finding the right balance, the right level of granularity in how your objects are made up of other, smaller objects. This is not an exact science, and there are no canonically right answers. What feels like the right level of granularity to me, might feel freakishly over-specific to you. What we can probably agree on, though, is that if you end up specifying a classname for every property + value combination on each element, you’ve gone too far:

<p class="color-red size-xl margin-20 padding-10
background-white weight-bold bg-img-monkey bg-pos-topleft">

Have a look at Nicole’s two articles about granularity and the media object for an illustrated example of how to think about HTML+CSS object composition.

Finally, I’ll bring out one of my favourite quotes: “There are only two hard things in Computer Science: cache invalidation and naming things.” Object composition is all about naming things; this makes it hard. But not impossible, and certainly very worthwhile once you get the hang of it.

jQuery Mobile doubts

jQuery Mobile has just hit its beta 1 milestone, and there is much rejoicing. But having worked with the framework for a little while now, I’m having serious doubts about its suitability for mobile web applications at all. This isn’t a “jQuery Mobile considered harmful” piece; I just want to explain my own concerns.

The way I see it, the jQuery Mobile framework consists of four sub-frameworks:

  1. jQuery. jQuery Mobile is not a standalone library; it requires the jQuery core library.
  2. A CSS framework for styling elements to look like iOS-ish native controls
  3. A widget framework that automatically builds the (complex) HTML required by the CSS framework from (simple) declarative HTML.
  4. A client-side page navigation framework

Combining the CSS and widget frameworks allows you to write simple declarative code like this:

<a href="somepage.html" data-role="button">Button</a>

which gets turned into this:

<a href="somepage.html" data-role="button" data-theme="c"
         class="ui-btn ui-btn-corner-all ui-shadow ui-btn-down-c ui-btn-up-c">
  <span class="ui-btn-inner ui-btn-corner-all">
    <span class="ui-btn-text">Button</span>

and is rendered like this:

The widget framework also allows you to create page and dialog widgets, that act as isolated screens within your application: only one is visible at a time.

<div data-role="page" id="index"> 
  <div data-role="header">Home</div> 
  <div data-role="content">
    <a href="#monkey" data-role="button">Monkey</a>
<div data-role="dialog" id="monkey"> 
  <div data-role="header">Your monkey</div> 
  <div data-role="content">
    <img src="http://example.com/monkey.png" />

These page widgets can be declared inline in your code (as shown above), built dynamically with JavaScript, or loaded from a remote server or from the local file system with Ajax. The page navigation framework takes care of hooking up the pages and dialogs, so that when you click on the “Monkey” button, the home page is hidden, and the monkey dialog is displayed. Very importantly, the framework takes care of browser history while navigating from page to page, so that the native back button works correctly. (Still buggy in beta 1, but I’m sure they’ll fix it.) It can also provide pretty animations for transitioning between pages.

Problem 1: “native” UI

If you’re happy sticking with the visual style of the framework, that’s fine. The jQM team has put a lot of work into making the UI components look very slick (and iOS-ish), and compatible across a wide range of browsers. But should a web application’s greatest aspiration be to look as much like a native app as possible? No. Remember building web apps to look like native Windows XP applications? Those were the bad old days.

The basic theme includes five colour swatches that you can apply and extend. But adapting the existing controls beyond just their colours and icons is more difficult precisely because they are generated from declarative markup, and the widgets only grant you limited options for tweaking their output. Of course, you are always free to bypass the widget system altogether and write your own markup using and CSS, and mix in classes from the CSS framework when appropriate.

Problem 2: Ajax navigation

Despite how easy Mark Pilgim makes it look, implementing a framework that gives you all the benefits of Ajax partial page loading, while at the same time maintaining fully linkable URLs is non-trivial. jQuery Mobile hasn’t tackled this yet. As you navigate between pages, you end up with hash-based, JavaScript-dependent navigation, which is bad.

So why do this in the first place? Why not just put each page on a separate URL, in the traditional web style, and ditch the client-side navigation altogether? Would jQM not work just as well as a CSS + widgets framework?

I don’t think so, because of speed — or rather, the lack of it.

Problem 3: size and speed

jQuery Mobile is not a stand-alone library; it is built on top of jQuery. Even though jQuery’s headline size may appear small (31.2KB minified and gzipped), and jQM doesn’t appear to add much on top of that (20.3KB minified and gzipped), this is not an insignificant amount of code for a mobile browser. Even if a browser already has these JS files available in its local cache, it still has to parse them on each new page load. And the painful reality is that mobile browsers are still really slow compared to their desktop cousins.

I’ve made a very simple test page to show how long it takes to just load (from cache) and parse jQuery (v1.6.1). Here are the very unscientific results from the devices I have to hand:

Device + browser Time to load (from cache) & parse
iPhone 3G + Mobile safari (iOS 4.2.1) 0.95s
Samsung Galaxy Ace (Android 2.2.1) + Android Browser 0.75s
iPad + Mobile safari (iOS 4.3.3) 0.29s
Samsung Galaxy Ace (Android 2.2.1) + Opera Mobile 11 0.29s
LG Optimus 7 (WP7, 7.0.7392) + IE 0.27s (very pleasant surprise!)

On other devices, performance can be even worse. 8 seconds on an older Blackberry? Try the page on your own phone and let me know how it shapes up. By comparison, on my laptop it takes about 0.02s to load & parse in Chrome 12, and about 0.05s in Firefox 5. So at a glance, it looks to me like mobile browsers are at least 5 times slower than desktop browsers.

When you’re talking about a consciously perceptible amount of time spent parsing a library, you’ve got a problem. Remember that this is just jQuery on its own, before adding in the jQuery Mobile framework and your own code, and before the browser has to do any actual rendering work to display your content.


The fact that jQuery Mobile sits on top of jQuery makes it a comfortable and attractive solution. If you already know jQuery, you’ll pick it up easily, and you’ll have all the power of jQuery available to you right off the bat. It’s well tested, and highly compatible. It’s under constant development, bugs get fixed all the time, and it has good community support. It’s better code than most of us are likely to write ourselves.

But the challenges of the mobile web are not the same as those of the desktop web. I have massive respect for everyone who works on them, but jQuery and jQuery Mobile do not address these problems adequately — yet. Performance is much more important, and much harder to come by because of slow devices and high network latency. Size matters a lot. When even big desktop web sites typically only exercise a small part of the code in jQuery core, you have to wonder if a mobile site is going to need all of it.

In summary:

  • jQuery, and by extension also jQuery Mobile, is too big a library for a mobile site that uses standard URL-based navigation.
  • Until the jQuery Mobile client-side navigation framework supports the HTML5 history API (pushState/popState), it will deliver problematic URLs. It’s up to you to decide whether this is a deal-breaker for your project.
  • If you’re building a PhoneGap application, jQuery Mobile is perfect. As you load the app, you load the framework once, and then navigate between a set of predefined pages using Ajax navigation and smooth transitions. You don’t have to worry about hash-based URLs, because they are not exposed to the user, and you’re not expected to link to them. The native look of the controls matches the user’s expectations for a native app. Awesome.
  • If you’re building a one-off mobile web application that you don’t expect to be around forever. jQuery Mobile might not not be the perfect solution for mobile web sites, but depending on the timescales and requirements of your project, it may very well be good enough.
  • If you’re building a full-scale mobile web site or application that is going to be core to your business, you can use jQuery Mobile to get you to v1.0 quickly, but consider it a set of training wheels that you should shed after this point. Its limitations will constrain the changes and optimizations you can make in the future. The UI is not designed with your site in mind, and the underlying framework is bigger than you will need. (A big framework may lead you to be less critical of the size of your own code.)

Some remarkable albums

After a string of pretty hard-core tech blogging, I feel the need to cleanse my palate with something a bit more lightweight. I don’t want to you get the impression that I’m some kind of geek or something. So in the long lead-up to the traditionally long-delayed Radio Sunpig (2010), here are three albums that I found quite remarkable last year, in the sense that I’m still listening to them over and over again.

Dananananaykroyd – Hey Everyone

Right from the opening licks to the closing stretched out wails of feedback, this whole album is filled with raucous energy. It’s not big on catchy radio-friendly melodies, but the frenetic pounding drums (two drummers!), shifting rhythms, screamed lyrics and gnashing guitars drive it forward with breathless speed. And yet at the same time the songs are not one-trick ponies; they are remarkably complex pieces of work that invite. I’d call it punk, but without the anger; it’s so hard to listen to them without a bobbing head and a manic grin.

And they’re Scottish, adding weight to my thesis that the best music comes from Scotland and Canada.

Hue And Cry – Open Soul

I’m a bit disappointed that Last.fm doesn’t understand Hue and Cry. On listening to Open Soul, Last.fm reckons that I ought to load some Curiosity Killed The Cat, and maybe a bit of Living in a Box into the mix. Weeellll, kinda no, guys. Hue and Cry actually made it out of the 1980s.

With Open Soul, they’re firmly in Michael BublĂ© and Jamie Cullum territory. Relaxed, jazzy, blue-eyed soul with gorgeous arrangements and a tight, tight horns section. Pat Kane’s voice has never sounded better, and their cover of BeyoncĂ©’s “Crazy In Love” — recalling the pseudo-rapped vocals on “Labour of Love” — is nothing but peppy fun. They’re absolutely at the top of their game here.

I also love the fact that Pat Kane is now also well known as a writer, speaker, and consultant on play, and is a smart and outspoken voice for Scottish independence. You should follow him on Twitter as @theplayethic.

Rack up another point for Scotland in the worldwide music battle.

Mos Def – The Ecstatic

One of the first games I downloaded when I got my iPad last year was Tap Tap Radiation, which is where I first encountered the song “Quiet Dog” which is a pure hip-hop masterpiece: sparse beats and precision rapping give it bounce and self-confident swagger. The rest of the album is wonderfully fresh and varied, mixing middle-eastern sounds with more traditional soul and funk, and lyrically jumping between brash (“Supermagic”) and achingly tender (“Roses”) with ease.

Mos Def is, of course, Scottish. (Brooklyn, West Lothian.)

Donkey Bridges

The ultimate reason behind my last two articles (“URL shortening is bonkers” and “On URLs, keywords, and memorability”) is a very simple use case: Alex (age 10) was playing Roblox on the kids’ computer, a game where you can build virtual environments and items to populate them with. He had made an item (I think it was a T-shirt), and he wanted to show it to me on my computer. What was the easiest way for him to do that?

Because Alex has an email account, but doesn’t use IM yet, the two options were:

  • I log in to Roblox, navigate to Alex’s profile, and look up the item.
  • Alex copies the URL for the item from his browser, and pastes it into an email to me. I open up the email, and click on the link.

Neither of these options is unreasonable, but they both feel unnecessarily cumbersome. Using the site navigation involves me clicking through several screens, and unless Alex is standing next to me looking at my screen, I’m not sure if I’ve got exactly the right item. But using email to pass the link around doesn’t take advantage of the fact that Alex is sitting five meters away from me, and we can just talk. For a younger child without an email account, even the second option would be out of the picture.

What I really wanted was for Alex to just say, “go to roblox.com, and type this simple code.” (With a code that doesn’t look like a cat has just walked over the keyboard.)

Donkeybridges.com is a demonstration of this idea. The site uses Yahoo!’s GeoPlanet API to show information about places (towns, states, countries) worldwide. Each place has its own page, which is identified by a non-obvious ID value in the URL, for example http://donkeybridges.com/place.php?id=2161838 (Guangzhou in China).

Each place also has a “link phrase” associated with it. (I originally called them “resource mnemonics”, but that’s not very catchy.) The link phrase is a combination of two adjective + noun pairs, like “a sticky pen and a funny feather.”

To view a place page, you can go directly to the URL (hard to remember), or you can go to the home page (easy to remember) and enter the link phrase (easy to remember). The idea is that two easy steps are better than one hard one. Not that pasting a URL into your address bar is hard, but ask yourself what you are more likely to remember in ten minutes: “2161838” or “a sticky pen and a funny feather”?

The link phrases are generated from one list with 100 adjectives and one with 100 nouns: A1 + N1 + A2 + N2. This gives a possible 100 x 100 x 100 x 100 = 100 million possible combinations. I picked the adjectives and nouns for the lists because they are simple and vivid, and produce clear mental pictures, which makes the combinations easier to remember.

100 million combinations isn’t enough for a generic URL shortener that may be dealing with billions of links, but it is enough to fit all the WOEIDs (“Where On Earth IDs“) that Yahoo! currently has assigned to places around the world. There is a simple algorithm to turn each WOEID into its matching phrase, and vice versa.

Because places that are adjacent in the real world often have WOEIDs that are very close together, I injected a little trickiness into the algorithm to make sure that consecutive WOEIDs produce very dissimilar phrases. WOEIDs 33556 (Rosevanion in Cornwall) and 33557 (Rosevean, also in Cornwall) map to “a jumping heart and a brown king” and “a fast dress and a wide knife”, respectively. If you’re interested, the source code is on Github.

What are the civilian applications?

You will have observed that the link phrases used on donkeybridges.com have nothing to do with the actual resources (places) they map to. This is a weakness when the resource is strongly physical, like a place, or a book, or an MP3. It can be fun to discover that a place is associated with a funny phrase, but there is no inherent reason why “a broken lion and a laughing cloud” should be more associated with Thurso in Scotland than with Beloha in Madagascar. The phrase is less memorable than it would be if there were a connection.

However, when it comes to identifying abstract resources, such as hotel bookings, appointments on a calendar, or items of virtual clothing, using one nonsensical but otherwise vivid and memorable phrase is as good as any other.

Sending someone a URL via email or IM will remain the quickest and easiest way to point someone at a digital resource most of the time. But link phrases give you a simple (and potentially amusing) analogue alternative when digital communication just doesn’t work out.

Please play around with donkeybridges.com, and let me know what you think.

On URLs, keywords, and memorability

As I explained in my last article, URL Shortening is Bonkers, a “resource” on the internet is a thing: a photo, a news article, a video, a user profile. We reach these resources by means of URLs (links), but bear in mind that the URL is not the thing itself; it is just a signpost to it.

These ubiquitous signposts of the modern internet are based on a system computer scientists developed in the 1970s to work with files on magnetic disks. This is why reading them out loud (“aitch-tee-tee-pee, colon slash slash example dot com slash monkey slash blah dot see-gee-eye”) makes you sound like a massive geek: to be using these things in the 1970s you probably were a massive geek.

It may seem a bit daft that we’re still doing it that way, but that’s just how evolving systems work. It’s why 60% of the world’s railway tracks are approximately two horses wide. Once the ruts have formed, it’s hard to break out of them.

The great benefit of URLs is that they are, as it says in the name, uniform. At web scale, you need a common standard for everyone to unambiguously signpost their own resources, without stepping on anyone else’s toes. URLs do that. But they are not intrinsically optimized for humans to understand, remember, or use directly.

A well-constructed, descriptive permalink, with a date and title in the URL, is a delight: it tells you when the article was written, and gives you a hint of its content (information scent). But remembering that URL so you can go to that article at some point in the future (two minutes or two weeks from now) takes effort. Did it contain full title of the article, or was it truncated? Did it use dashes for spaces, or underscores? Did it have “.html” at the end? This is why bookmarks were invented.

Just by virtue of being shorter than a typical URL, you might think that short URLs would be easier to remember than full links, but that’s not necessarily the case. The payload of most short URLs is an apparently random sequence of upper- and lower-case letters and numbers, and our brains find it easier to cope with structure than with randomness.

It doesn’t have to be that bad, though. Bit.ly allows you customize your short links with meaningful words and phrases instead of randomness. The short URL http://bit.ly/monkeys is nice and easy to remember. But customized URLs are handed out on a first-come, first-served basis, so just as with internet domains and user names on popular services, as more and more short words are taken, customized links will become longer (http://j.mp/weirdalbinopygmymonkeys) or more random (http://j.mp/monkeys71).

The key idea here is actually no different from what AOL was doing with keywords a decade ago (remember keywords?), or what Google does with search. Instead of going directly to a resource with a single, long, unmemorable identifier, you use two shorter, much more memorable parts in a hub-and-spoke fashion:

  1. Go to the well-known hub (Bit.ly, Google, AOL)
  2. Use the hub’s human-optimized naming scheme to access your target resource

Different hubs take different approaches to their “human-optimized naming scheme”. Biy.ly hands out names for free, but on a first-come, first-served basis. AOL used to monetize their names by making companies pay to claim their keywords. And Google, of course, doesn’t really use keywords: they use search phrases. Search phrases are completely freeform and flexible, but are less precise in leading you to exactly where you want to go. A company might want their flagship product to be top of the search results when you type its name in Google, but that doesn’t actually mean it will happen. (Like, any search for consumer electronics, ever.)

As a method for reaching a resource that you know is there, hub-and-spoke works pretty well, especially when the hub is so deeply embedded in many people’s everyday lives (e.g. Twitter, Facebook, Google) that they have the hub hard-wired in their memory already. What it lacks in directness, it makes up for with memorability and low mental overhead. If you see the link “facebook.com/vauxhallcorsa” on a billboard while you’re driving home from work, you don’t have to try to remember whether the advert said “vauxhall.com” or “vauxhall.co.uk”, and then figure out the company’s site navigation to get to the information page for the car.

Companies sometimes make use of this on their own sites, for example with promotional codes: “Enter the code XEPO29 to see exclusive deals!” More commonly, though, the typical corporate home page offers three ways of reaching content: headline links, general site navigation, and search. Say you want to “send someone a link” to the product page of a really neat waistcoat you have found. You tell them to go to the example.com home page, and:

  • …click on the “steampunk satin waistcoat” link. Only works if there is a direct link to that specific product on the home page. Doesn’t work for large sites.
  • …click on the link for “clothing”. On the Clothing page, click on the link for “jackets, waistcoats”. On the Jackets and Waistcoats page, click on… (etc.)
  • …type “steampunk satin waistcoat” in the search box. The product will probably be top of the search results. (Unless it’s part of a whole range of similar products.)

To supplement these three traditional paths to a resource, sites could use internal keywords. If the site recognizes that you have entered a keyword in the search box, it could take you directly to the exact resource instead of to a page of search results. (The “I’m feeling lucky” path.) Or it could show a shortcut to the exact resource prominently above the general search results.

Unfortunately, for large sites this still suffers from problems of scale: if you have thousands of resources (many of them similar), the list of pleasingly short, meaningful unique keywords will be quickly exhausted, and you will end up with keywords like “VampireRedSteampunkSatinWaistcoat” or “waistcoat227”.

However, if you relax the restriction that the keywords have to be just meaningful, and just have to be memorable, there are all kinds of interesting things you can do. I’ll show a fun little example in my next article: Donkey Bridges

URL shortening is bonkers

Well, mostly.

To be fair, full URLs (technically URIs, but let’s not go there) have a lot of shortcomings in the first place. But URL shortening only tackles one of their problems, and makes other aspects worse as a consequence.

The only problem that URL shorteners solve is that URLs can be very long, and therefore don’t fit into a 140-character SMS message. It’s not about fitting into Twitter messages; that’s just a side effect. SMS is the underlying restriction. Twitter could easily relax their 140-character limit and let people write vast screeds, but they still deliver an enormous number of updates via SMS, so longer messages would have to be truncated (or split over multiple messages). Just because we decadent Western smartphone users all rely on native Twitter clients does not mean that the rest of the world does.

(Also, forcing people to be concise in their writing is not a bad thing, and Twitter owns this space as a business concept. I find it interesting that part of Twitter’s value lies in enforcing this limitation, not in finding ways to lift it. Less is very definitely more in their case.)

This is not to say that the URL shortening services don’t deliver value. Aside from their stated goal of actually generating shorter URLs, some shortening services (e.g. Bit.ly) offer click tracking and analytics, so you can see how many people have used a link. Others (e.g. Adf.ly) allow you to piss people off generate revenue from your short links by presenting an interstitial page of adverts to people who visit the link, before taking them to the actual destination page.

There are definitely clever and interesting things you can do, but they all stem from a technical limitation that doesn’t actually exist for most web users. Which is kind of nuts. If you’re composing an SMS, then sure, make your URLs as short as they can be. But if you’re pasting a link into an online article or an email, why the hell do you need to?

“So that other people can then copy and paste the link more easily” is a crappy argument, because the single biggest problem with short URLs is that they obscure the target of a link. If you see the URL “http://www.disney.co.uk/tron/index.jsp” in an email, you don’t expect it to lead to a dating site. The same cannot be said of a random shortened link, whose payload is typically just a meaningless jumble of letters and numbers.

This isn’t actually a new problem, because advertising networks have been doing this for as long as the internet itself. Do you have any idea where http://adgo-online.de/ad/goto/71/1/b55f128e9ef13754dbd545ddc60d34/ will take you? Me neither. It used to be the case that only ad networks did this, but now everyone is at it. Apart from the opportunities for creative Rickrolling, there is no upside to this.

So now Twitter, who helped encourage the whole short linking thing in the first place (and who will now shorten your links automatically, without the need for a third-party service), has code in place that automatically de-references short URLs, so that you see the real target whenever you hover over a short link. They’re peddling both the disease and the cure, which sounds like a great lark.

Most people don’t care about the performance implications of an extra 301 redirect, so I won’t dive into that. But people do care about linkrot. Maciej Ceglowski of Pinboard did some research last month to find out what proportion of URLs in the Pinboard bookmarking system were dead, or no longer led to their original target. In his article Remembrance of Links Past, he writes:

“Links appear to die at a steady rate (they don’t have a half life), and you can expect to lose about a quarter of them every seven years.”

Using URL shorteners increases the risk of linkrot, because if you store the short URL, not only is there a probability that the target resource will die, but a certain proportion of URL shorteners will disappear each year, too.

That leads to the question of “what is a link anyway?”

In general, when we talk about a “link”, what we actually mean is a resource. Hence the term “URL”, which stands for “Uniform Resource Locator”. (Which is not the same as a URI, a Uniform Resource Identifier, but I already said we weren’t going to go there.)

A resource is a thing: a photo, an article, an MP3 file, a video. That’s what you’re interested in, and that’s what you want to show someone when you say you will “send them a link”.

The link is just a signpost to the resource. The map is not the territory. If the resource still exists, and can be found by other means, how much does it matter if the signpost disappears? How precious should we be about permalinks and cool URI’s that don’t change?

To stick with the signpost metaphor: full URLs are official signs erected by the city council; short links are verbal directions from some dude on a street corner.

If you think about them like that, it’s clear that short links are ephemeral, and do have a genuine use, provided that they are treated as such.

It’s perfectly fine for me to send you an IM with a short URL if I just want to you take a peek at a funny cat picture (and feel the curious need to save bytes). It’s not fine for me to use that short URL if I write a blog post and want to reference the same picture. That’s what the full URL is for. The mode of conversation is significant: in one case it’s ephemeral, but in the other case stability and permanence takes precedence.

However, most people on the internet care about this distinction approximately as much as the difference between URLs and URIs, which is to say, not at all. Oh well.

There is one last aspect of (short) URLs that I’m particularly interested in, but which I’m going to save for my next article: On URLs, keywords, and memorability.

Further reading: