Well-Intentioned Schemes

tl;dr - there's a lot going on at that beginning of an HTML href which you can take advantage of, particularly by pointing links to communication services such as SMS or Skype.
A Uniform Resource Identifier (URI) begins with a scheme such as "http" or "https." Right away, there's an important difference between these two common schemes that many may not be aware of. HTTP is HyperText Transfer Protocol, the transfer protocol that undergirds the web. HTTPS is similar but the S stands for "secure." What does that mean? Basically, when you request a resource, which could be anything from a fully fledged website to an individual text or image file, using HTTPS your request is first encrypted in your browser & the response you receive from the server is also encrypted. This means that any party in between, including your Internet Service Provider such as Comcast or your employer if you're on your work computer, cannot monitor precisely what you access on the web. HTTPS also prevents "man in the middle" attacks by trying to ensure that you're communicating with the right web server; if you've ever seen one of those terrifying "This is not the web page you're looking for" warning messages (an every day occurrence for users of our campus WiFi, sadly) then it's because of that feature of HTTPS.

Communication Schemes

HTTP is well-known even to those who don't write HTML, but there are a few rarely used schemes that provide new functionality, especially now that more & more people access the web on phones. Most web content authors are familiar with mailto, a neat scheme that opens up links in an email client. Mailto even comes with an enhancement; you can add subject & body content by appending "?subject=[subject text here]&body=[body text here]" to the URI. So one can email David Weinberger with the subject "Cluetrain" & the body text "You wrote it." by writing the following HTML:

<a href="mailto:self@evident.com?subject=Cluetrain&body=You+wrote+it.">Hey David</a>

URIs can't have spaces, so I encoded them into + signs, but other than that it's pretty obvious how each piece of the link works. Here's the thing: mailto is just one scheme amongst others. There are also schemes for SMS & telephony which, up until people starting browsing the web with their phones, weren't very useful. A link can open in a texting app like Messages by using href="sms:555-555-5555?body=hello+friend" or in a phone with href="tel:555-555-5555". There is little reason not to write all your phone numbers in tel: links starting today. You never know who may be accessing your site on a phone, so give them a chance to call you without the friction of flipping between their phone app & your site.
Besides the mailto, sms, & tel schemes which are all hardwired by the operating system to the user's default applications, one can also launch specific apps if they have registered schemes. Perhaps the most obvious usage is Skype, yet another communication service. We use this on our tutoring website, where our tutors host online sessions using Skype. One can call the Skype user Trueclain by clicking the following HTML:

<a href="skype:Trueclain">Skype Me!</a>

Yes, that link opens Skype. Minds blown. Skull fragments scattered all around.
Schemes are not limited exclusively to communication services either: the Coda Protocol app for Mac opens coda:/// URIs in the Coda text editor. I was unable to find any examples, but I think at one point CSS Tricks was using Coda URIs to directly import code samples into people's text editors. Pretty cool. A more commonly used application scheme is the Twitter scheme. A link with a href of "twitter:@phette23" would, if clicked in an iOS device or recent Mac OS X, open the Twitter app to my user page.
I'm unsure of the utility of twitter: URIs. Is it better to open Twitter.app or the Twitter website? I'd prefer to direct users to the open web if functionality is all the same, which it is with Twitter. Web links always work regardless of operating system or installed software. But it's very valuable for websites to be able to tie into OS applications like phone & Skype that are not available online.

No Life Without Suffering

Of course, as soon as you start opening URIs in applications all sorts of headaches arise. We live in an era where the diversity of devices, operating systems, & software setups accessing the web has never been greater. There are no guarantees.
There is no standardized way for web browsers to handle some of these rarer schemes. Clicking tel & sms links on my laptop, I see a few different behaviors:

• Google Chrome does nothing. That's actually the best behavior I've seen; above all don't further confuse the user with error messages.
• Safari fails with a message noting "OS X doesn't recognize Internet addresses starting with 'sms:'". Particularly dumb coming from Apple, who just shipped an SMS app (Messages) with their latest OS.
• Firefox fails with a cogent message of "Firefox doesn't know how to open this address, because the protocol (sms) isn't associated with any program."
• Internet Explorer 8 404s when trying to follow sms: links & times out when trying to follow tel: ones.

Unfortunately, these dead-ends will always occur when websites try to use non-standard schemes. There is no way to detect what software is installed on a user's computer using JavaScript (with good reason since that risks both security & privacy mishaps). It would be nice to perhaps expose an error API when an unsupported scheme is followed, something that would allow scripted fallbacks. Until browser vendors, probably in collaboration with operating system developers, find an elegant way to handle breakdowns it will probably always be a risky move in terms of user experience. An ideal solution would involve Web Intents, wherein links point towards particular services (much as mailto & http links do currently; users can configure their default mail & web browser apps) & not specific programs like Skype. In the event that no app is registered to handle a particular intent, a prompt such as "You do not have a program equipped to handle this link, would you like to view a list of candidates in a software directory?" would be nice.

Protocol-Relative URIs

Let's revisit the HTTP/S divide to discuss protocol-relative URIs. If you use the HTML5 Boilerplate, you might've already seen this line down towards the bottom:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.8.2/jquery.min.js"></script>

Why is the "http:" missing on that src attribute? Because by leaving the protocol off, the src attribute inherits the scheme of the website it's on, e.g. if it's served over HTTPS then that URI will default to HTTPS. This is important because when resources of a HTTPS site are served over HTTP most browsers pop-up a "warning: insecure content" alert. When you mix HTTP resources in HTTPS you lose the security of those elements: someone snooping can see that I requested http://ajax.googleapis.com/ajax/libs/jquery/1.8.2/jquery.min.js though the rest of my requests may remain encrypted.
In sum, there's rarely a reason to put the scheme in any scr or href attribute. The only reason would be if a particular resource is explicitly not available over one scheme or the other. For instance, Google's encrypted (read: HTTPS) search is simply not available over insecure HTTP: requests for http://encrypted.google.com are redirected to https://encrypted.google.com. So while a link to http://encrypted.google.com will redirect & work–albeit after a superfluous HTTP request–an HTTP src attribute pointing at a image available only over HTTPS would not & visitors would miss the image entirely.

Exeunt

Does anyone have examples of innovative uses of non-standard schemes? I'm curious if there are applications that I just haven't thought of yet. Putting phone numbers in tel: links & Skype names in skype: links is a start, but there must be more. There are so many interesting possibilities in the existing schemes: facetime, maps, market (Google Play), ms-help (Windows help files), spotify, & webcal. There must be uses that help glue our websites into the larger system of software that our users employ every day.