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