Let’s talk about protocols. I’ve been repeating most of what is in this post in conversations for a while now, so I thought I should write it down. They are thoughts around what it means to add new protocols to the platform, and how we go about it in practice. The main extensibility mechanism that we have comes from the HTML5 era: registerProtocolHandler() . In this post I’ll explain where I think that’s kind of OK, where it falls (sometimes very) short, and some things I think we learned along the way. The purpose of this post isn’t to make suggestions, it’s simply to have a look at the space and the things I think we need to keep in mind.
Most of the URLs we type these daysbegin with https : – or before that, http: . We changed the main protocol of the web to be more secure. It’s not inconceivable we could want to have that level of change again, but there are plenty of things short of that where protocols develop and somehow find their way into the platform.
A few popular examples from the HTTPArchivedata: Over 30% of websites include at least one mailto: link. Almost as many sites include a tel: link. There’s plenty of webcal: and fax: . geo: is used on over 20,300 sites. sms: is used on 42,600 + websites. These are just a few examples of protocols that are trying to do something useful.
Things That Go “Click” When you click a link that has oneof those protocol identifiers, the browser says “Do I know how to handle that protocol?” If the answer is no, it passes responsibility along to the OS. So, if you have Skype installed, and click on a skype: link, the OS might launch Skype for you. Protocol handlers really are just built on the idea that over time, we build web-based services and it should be possible to say that the way to handle them can be by rerouting handling to a domain (say, gmail.com for mailto: links). So, for those, things it works… Kind of.
The mistakes we made along the way… On the surface, all of those protocols that turn up in the HTTP Archive data seem like success stories. However, I’d like to tell you why they haven’t been so great, and why we already have better solutions. Consider the secondmost widely used of those, the tel: protocol. Not because this one is especially bad, but because it is very easy to illustrate many problems in a concise example. Before tel: , authors would put some text in their web page, like: Phone: (555)123-4567 With tel: , authors could now put something like this into their HTML: < a href = "tel:123.456.7890" > Call now </ a > Yay! Except, no… wait… That is kind of terrible. Sure, for some users, where all of the stars align, that will be a nice convenience. But there are just way too many cases where this is more of a barrier than a convenience. Let’s look at some of the failure modes of that line of code, starting with the simplest: Hidden information Because we’ve made it a link, it’s far too common that authors don’t actually display the phone number. They assume that the device I’m looking at is the device I want to dial from. There are many cases where that is not true! Perhaps I’m on my office desktop and I want to dial with the handy office phone that is next to me, or the conference system, or even just my cell phone. Maybe I want to read the number out to someone else, or write it down for later. Just show me the !@$!@ number! This isn’t a problem inherent to the protocol, but it’s still a problem. Theoretically capable, practically incapable Sometimes a device can be physically capable of dialing out, but currently not have that service available. This happened to me while traveling abroad in 2018 , where I was able to use my cell with WiFi but couldn’t dial out (I didn’t have WiFi calling at the time). This problem still comes up I use that same 2018 cell phone to control my media in my house, and occasionally to look something up, but since it isn’t on my cell plan, I can’t use any tel: links. No registered handler at all On some machines, there is no registered tel: protocol handler. What happens in this case? Unspecified. Each OS will do something a little different. For years tel: would often do nothing at all which is very confusing to users. Some operating systems will, to various degrees, offer to help you find something capable of handling the protocol, but even that can be confusing (see next point). Registered a Complex Program Some devices will launch a program that’s registered to handle the tel: protocol, even if it can’t currently dial. There are many examples of this. Apps like Google Hangouts or Skype were chat programs with some VoIP support. They could dial out if users paid a special recurring fee – but most users didn’t pay that fee. When those users clicked a link and it launched their chat program, or told them they have to pay to dial, that’s confusing and frustrating. In fact, lots of users of those apps just use them for text chat. Not so long ago, many users on office desktops didn’t have cameras, mics or speakers. If users clicked a tel: link and it launched their chat program and implied that they could pay money to dial out, but actually couldn’t do that: This is very confusing to users.