A recent build of Chromium removes “http://” from the Omnibar in the browser, and replaces it with a globe icon. As a result, typing “http://www.google.com” will result in “www.google.com/” being displayed, rather than the full URI. There’s been a lot of heat and discussion about this, and near and far as I can tell, people just plain don’t like it. At least the vocal minority doesn’t. From what I’ve pieced together, here are the reasons the developers have removed “http://” from the display:
- The browser uses HTTP as its default protocol. Any other protocol, such as HTTPS, FTP, etc is not default.
- It’s already understood that HTTP is the default protocol of the browser by users.
- Displaying “http://’ is redundant information, as the user is already aware of #2.
- If the user is not familiar with #2, then why does it need to be presented at all? Why clutter the interface or display “geek code” to the average user?
- Removing “http://” from the OmniBar removes the redundancy, while keeping the browser behavior and user interface entirely in tact.
- The browser will display other protocols that isn’t default to the browser, such as “https://” and “ftp://”.
Fact of the matter is, the Chromium developers aren’t going to revert the change. I’ve read all the comments I can find on this matter, and here’s an overall summary:
After seeing “http://” in every browser on the market since browsers have been used, as soon as it’s removed, it seems there’s a big gaping hole in the address bar. For some reason, it keeps their eyes floating back to the address bar, wondering what had happened and why it was changed, when it wasn’t hurting anything to begin with. In other words, displaying “http://” is sexy, and removing it is not. Either that, or they feel that there’s a big void in their life with it missing.
It breaks other applications with copy and paste
By removing “http://” from the Omnibar, when copying a URL to the clipboard, and pasting it into other applications, these applications may or may not be able to recognize the URI, and as a result, not make it “clickable”. However, there have been no use cases submitted of such breakage. No one has come forth saying “Application X won’t linkify a URL pasted without http:// in front”. Plenty of speculation about it, however. Plenty. But, what appears to be the problem, isn’t Chromium, but either your operating system, or the application you’re pasting your URL to. You see, Chromium will present a web object to the operating systems clipboard. If the operating system is worth its weight in gold, it will preserve the web object, and present the object to the pasting application.
So, at this point, it’s up to the application how it wants to handle it. Every email and IM client that I can test, including office document creators, treat the web object as it should, and linkifies the paste, even though “http://” isn’t part of the paste. If an application exists that doesn’t linkify the paste, it should be brought to that developer’s attention. After all, it’s the problem of their application, not Chromium. Think about it. Do you type “http://www.google.com” when chatting with your buddy, or just “google.com”. So, not only should the client recognize clipboard web objects, but it should also recognize partial URI schemes.
It doesn’t adhere to specification
This is semi-valid. At least people are concerned about Chromium adhering to spec. The specification is the URI scheme includes a scheme name, such as “http”, “ftp”, “smb”, etc, as well as an authority, path, query and fragment. So, by not displaying the scheme name in the Omnibar, Chromium is not adhering to specification. The problem with this argument, however, is that the specification is really only dealing with applications referencing a URI, through another program, source code, etc. What is displayed visually to the user shouldn’t matter if it’s “breaking spec” or not. I tell you right now, your mom isn’t going to care if her URI is valid specification.
Frankly put, I’ve been all over the mailing list and on the bug report trying to explain to people soundly and logically why the move was made, and why the Chromium developers aren’t going to revert the change. As I outlined above, no one, other that developers and Internet geeks, are going to notice, if they haven’t caught wind already. If the change is indeed breaking applications, then the developers need to know what is breaking and how. What they don’t want is a bunch of whining, moaning and threats that you’re going back to Firefox. That doesn’t help. If copying and pasting is broken in other applications, let them know what application is broken, and how it broke. You know, bug reports. Actual, solid, bug reports.
Currently, there is a regression. When removing “http://” from the Omnibox, copying the URL didn’t include “http://” in the clipboard web object. So, a paste wouldn’t show it either. So, they added “http://” to the clipboard on copy. However, something else broke this behavior, and as it sits, a copy and paste will not give “http://” in the pasted result. However, this has been marked as release critical, so the next stable push likely won’t go out until this is fixed.
Personally, I welcome the change. Knowing the default protocol of your software may or may not be important, but I don’t think the software really needs to communicate that to you. Think of your email client. It communicates over SMTP, IMAP and POP3, sometimes simultaneously. Yet, you don’t think twice about it, and it certainly doesn’t tell you “Okay, now I’m using the SMTP protocol to send your message.”. IRC clients don’t tell you they’re using “irc://”. Chat clients don’t tell you their protocol, whatever it may be. FTP clients, SSH clients, Samba clients. On, and on, and on. The browser is the only exception to this rule. Why? Why does the browser need to tell you that it’s using HTTP when it’s already generally understood? Isn’t the important thing interacting with the sites you want to visit? Not the protocol? Frankly, I say good riddance!