

rel="shortlink" - URL shortening that doesn't hurt the internet - benhoyt
http://code.google.com/p/shortlink/wiki/Specification

======
sjs382
This is already done on some sites using rel="canonical" and rev="canonical".
please don't create a competing standard. A site as large as Flickr already
uses this standard. Check the page at
<http://www.flickr.com/photos/patrickmatte/3828709208/>

    
    
      It contains both:
      - <link rel="canonical" href="http://www.flickr.com/photos/patrickmatte/3828709208/ />
      - <link rev="canonical" type="text/html" href="http://flic.kr/p/6Qk8RJ >
    
      Each one has a specific purpose. You can read more at:
      - http://simonwillison.net/2009/Apr/11/revcanonical/
      - http://www.flickr.com/services/api/misc.urls.html#short

~~~
akirk
Well, it is controversial whether rev="canonical" is the right thing to be
used. Furthermore the rev attribute has been removed from HTML5.

See <http://annevankesteren.nl/2009/04/rev-canonical> for some details.

~~~
sjs382
A rebuttal:
[http://erikvold.com/blog/index.cfm/2009/4/21/rev_canonical_g...](http://erikvold.com/blog/index.cfm/2009/4/21/rev_canonical_good)

I've disagreed with the rev attribute being removed from html5 since I read
about it. The draft isn't final though, so time will tell...

But back to html4... Google, Yahoo and MS all support (or have announced
support for) rev="canonical". The only "standards" that matter are the ones
that are used. :)

~~~
jacquesm
> the only "standards" that matter are the ones that are used

Right, like upper case html tags and the iframe tag...

It's a difficult time for the web, and real standards are hard to come by.

The 'standards that matter are the ones that are used' attitude is exactly
what got us into this mess in the first place (Microsoft up front with their
'extensions').

I'm all for waiting for the dust to settle and then refactoring using whatever
the standards body decides, even if that would be against my personal
preference.

Using something on purpose to try to subvert the process to me smacks of
driving on the left hand side when the standard behaviour is to drive on the
right. It creates a lot of trouble for no good reason other than to prove that
'you can'.

Of course you can. But do you really want to aggravate others just to show
that you can ?

There is plenty of stuff in the current html standard that goes against my
personal preference but I won't let that get in the way of at least trying to
comply.

~~~
sjs382
_The 'standards that matter are the ones that are used' attitude is exactly
what got us into this mess in the first place (Microsoft up front with their
'extensions')._

The "standards will be written as they will be implemented by the browser
manufacturers" is exactly the approach that the whatwg has taken on html5:

    
    
      After an inordinate amount of discussions, both in public and privately, 
      on the situation regarding codecs for <video> and <audio> in HTML5, I have 
      reluctantly come to the conclusion that there is no suitable codec that 
      all vendors are willing to implement and ship.
    

_I'm all for waiting for the dust to settle and then refactoring using
whatever the standards body decides, even if that would be against my personal
preference._

Which is exactly the approach i said I was taking. And despite the tone of the
tone of your post, I dont seem to recall saying that I was going to continue
using rev in html5 even though it was removed from the (draft) spec. I _will_
continue to use it with html4, though.

~~~
jacquesm
Ah, ok. Apologies then!

------
tlrobinson
Or how about Twitter just not count URLs against the length and be done with
it.

For SMS, Twitter could just append a very short URL pointing to the actual
tweet on their site, where you'll be able to see the URLs.

~~~
steilpass
[http://news.com/And-What-If-I-Start-To-Encode-My-Message-
In-...](http://news.com/And-What-If-I-Start-To-Encode-My-Message-In-My-URL)?

~~~
kevindication
<http://it.will.be/hard-to-read>

------
commiebob
Correct me if I'm wrong, but the way I read this is on any page I own I would
have to define a short url for it in the head section of the html.

So with this standard no one could short link to a site I control without me
going through and making up a short link for every page.

In addition to that, this standard assumes that your url is somewhat short and
not something like "thelongesturlintheworld.com" in which case it wouldn't
help at all.

Twitter needs to just make it's own URL shortening service and put an end to
all this.

~~~
dlsspy
You're looking at it backwards.

Right now, people communicating on microblogging services end up having three
things that need to be working for them to get through:

1\. The µblog 2\. The URL shortener 3\. The original site

Various URL shorteners might fall over for a bit, or any other number of
stupid things.

In the wordpress example, they registered wp.me so they could shorten the URLs
sanely:
[http://images.scripting.com/archiveScriptingCom/2009/08/16/m...](http://images.scripting.com/archiveScriptingCom/2009/08/16/mattmensch.gif)

If you support shortening, you reduce a dependency. You can still use tinyurl
or bit.ly or whatever in this model, but if you don't, it'll be done for you.

~~~
chrischen
Then why don't microblogging sites find a way to accomodate long URLs. Why do
we have to start defining _short_ (which is subjective) urls?

~~~
dlsspy
That's a fine suggestion, but it requires some out of band metadata.

Remember, twitter is an SMS mailing list. You want to be able to send that
data in a way it can be picked up from simple mechanisms like SMS messages.

~~~
chrischen
hmmm... I guess that's a good reason. But what other use is there besides SMS?

------
pohl
Webmasters could have been giving thoughtful consideration of the length &
structure of their URLs all this time, yet they have not been doing so. A
voluntary system like this slightly better, but couldn't it be ignored just as
easily?

~~~
omouse
_Webmasters could have been giving thoughtful consideration of the length &
structure of their URLs all this time, yet they have not been doing so. _

They don't do it because it would negatively affect their search ranking.

------
SingAlong
Doesn't this interfere/clash with the XFN specs?

Because, XFN uses rel attribute of links to define relationships.

~~~
dlsspy
I think it fits fine:

 _This attribute describes the relationship from the current document to the
anchor specified by the href attribute. The value of this attribute is a
space-separated list of link types._

I'd say a shorter version version of a URL represents a relationship to the
current URL naturally.

------
trezor
I was about to make a post about how I wanted twitter dead to end all this
useless noise about URL shorteners.

Then I realized that the reason there is noise here is that some people
actually seem to think they have something to offer the world which the real
URL wouldn't do.

Can someone who are actually willing to defend these things explain to me why
you consider a short URL more useful than the original? What motivation you
have for adding third parties to what could be a standard hyperlink?

~~~
ubernostrum
The two most common uses I've seen are:

1\. Huge unwieldy URLs like the ones you get from Google Maps, which may get
mangled by email clients.

2\. Easy-to-type URLs to put in slides for presentations, since people in the
audience can't click on the things you're showing them.

------
scythe
I liked the idea behind <http://twi.bz/>, which at least shows the domain name
behind the link. It doesn't make for quite as short links as tr.im &c though.

