rel="shortlink" - URL shortening that doesn't hurt the internet | Hacker News Reader

rel="shortlink" - URL shortening that doesn't hurt the internet

code.google.com

53 pointsbenhoyt41 comments

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

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.

A rebuttal: http://erikvold.com/blog/index.cfm/2009/4/21/rev_canonical_g...

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. :)

> 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.

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.

Ah, ok. Apologies then!

This was done before that with HTTP 302.

rev="canonical" doesn't compare to HTTP 302. HTTP 302 doesn't allow a user to discover a shortened url provided by the publisher. It's just a temporary redirect.

Who cares if its a short URL or not? An URL is an URL. If you want to "discover" what is behind a link, do something like

  $ curl -I http://faux.com/XiSk
  HTTP/1.1 302 Moved Temporarily
  Server: nginx/0.6.35
  Date: Mon, 17 Aug 2009 09:47:11 GMT
  Content-Type: text/html
  Transfer-Encoding: chunked
  Connection: keep-alive
  Location: http://www.faux.com/the/realz/resource

And HTTP 302 is more than just a redirect. 302 says, "Hey, the resource is over here, but check back with me next time before you request that same resource because it might change" whereas a HTTP 301 says, "Don't worry about checking back here next time you want the resource, its really over there".

Maybe URL shortners should be throwing 301's around instead of all of this rel nonsense.

I think you're missing the purpose of this thing. rel=-hortlink / rev=canonical answer the following question:

"I'm on a page with a really long URL. Is there a preferred shorter URL for this page?"

In the context of URL shorteners, 302 redirects usually take you from a short URL to a longer one. rel=shortlink is about discovering the preferred short URL when all you have is the long URL.

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.

One of my pet peeves about Twitter is that conceptually, it hasn't embraced the fact that most of its users don't Tweet by SMS.

I'm all about using a restricted message format to encourage spontaneity and focus the message, but if I want to @reference more than like three people I have very little room for what I want to say - and if I have a URL as well, I have almost none.

Keep the system as-is for SMS-based tweets, but for the rest of us don't count @names or URLs in the message length.

So what happens to the "unrestricted" tweets when they're received over SMS?

Send them as two sequential SMS messages, or an MMS message (user's choice). Pretty much anyone who is receiving tweets on their phone has unlimited received texts anyways.

The same thing that happens to DMs. They get split up.

Twitter should treat urls, @reply, #hashtags, geographical descripters, etc as a separate metadata field outside of the message.

Agreed. Similar to what they're doing with ReTweets, or at least are rumored to be doing. (showcasing the original tweet in your followers' streams and just saying who it was retweeted by)

There is also a huge benefit to developers if they separate the stuff out - no more parsing tweets for mentions/hashtags because there's a separate field for them as well as possible fields for other info.

http://news.com/And-What-If-I-Start-To-Encode-My-Message-In-...?

http://it.will.be/hard-to-read

The anchor text would still count against the message length, but the href would not. Just have some simple syntax, like markdown's [text](url)

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.

They basically have. It's called bit.ly (which is the official/default URL shortener and whose servers are housed in Twitter's data center). For all intents and purposes, Bit.ly is Twitter's own URL shortener.

But not every Twitter client and site uses Bit.ly (HootSuite uses ow.ly, for example, and Digg uses, well, digg.com). And, you know, not every short URL is made for Twitter.

(Note: this isn't supposed to be a response to the original post, which I only skimmed.)

Correct, you'd need to add it to each page, but that shouldn't be a huge deal these days unless you just have tons of static html pages on your site. If your site uses some kind of templating system (Wordpress, ASP.NET Master Pages, Smarty, etc.) you should be able to dynamically add the shortened link into the document header without too much trouble.

I understand that it's not a huge deal, but that's not really the point. Do we really need to update every page on the internet with a short url? Just in case it gets linked on twitter or a shorter version is needed for some reason?

It just seems a little ridiculous to me.

Consider it in a different light -- you're running your own url shortener on the same server that the content is on. This helps to avoid "linkrot" caused by unavailable/disappearing url shorteners.

If this isn't a concern for you, don't provide this service. People will continue using other shorteners that are susceptible to these problems.

The idea isn't that every page will define its own URL. The idea is that some pages will, and things-that-shorten-URLs should then use their preference in shorter URL when linking to them. For all other pages regular URL shorteners like tinyurl and bit.ly can be used just as they are now.

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...

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.

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?

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.

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

Phones have been able to recieve SMSes longer than 140 characters for about a decade now.

Limiting a service on the internet because 0.1% of the users want SMS notification on decade old phones is stupid and backwards.

Short URLs aren't just about twitter. URL shortening is useful in a variety of situations, and tinyurl was widely used for years before twitter came along.

In addition to space constrained applications such as SMS (and artificially space constrained applications like Twitter) shortlinks are also required anywhere humans are required to remember and/or enter them - that is, when they are printed, recited over radio or displayed on televisions. This is a very important use case that people often ignore.

Sam

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?

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.

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

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

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.

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?

If it's short enough, it can be easily read over the phone.

If similar looking characters are removed (1 or I; 0 or O), they can be easily noted in a notebook without confusion.

These are just two alternate uses...

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.

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.

Reply on news.ycombinator.com