I’ll try to put this in the simplest terms:
- The GoogleChrome team have unilaterally taken the user-interface decision to remove “http://” from the beginning of http-only URLs, leaving “https://” and “ftp://” and so forth in place, but for HTTP replacing it instead with a pretty blue-planet-earth-icon
- The result has been a wave of geek techie protest
- The issue being that if you copy the text of a URL, you probably want the “http://” thing to come along with it too, so (say) you can embed the URL into a blogpost, or tweet it, or something.
- So they’ve addressed this by making it so when you copy the whole URL, you (hopefully) get the “http://” prefix.
Unfortunately there’s an issue which I wrote-up in a bug report:
My big issue with this is that it means I have to do _more_ work when I do cut-and-paste.
I understand that the “http:// is automatically prefixed by making a copy operation create the right kind of object in the cut buffer – at least on mac.
However if (as is fairly common) I do a partial cut on a URL, eliding as AS LITTLE AS A SINGLE CHARACTER from the URL which I want to copy – for instance any
– then I end up having to manually reinsert the http:// in whatever I am authoring at the time; for instance, a blog posting.
I was ambivalent, even mildly supportive of this change, until I discovered this. Now I am against it. To my mind either Chrome has to update the Cut/Copy operation so that any Cut/Copy touching the left-hand end of the string, creates a URL object… or they have to provide me the “http:// text when I am cutting/copying, so that I can choose to include it.
…however I deleted my comment when I found someone had beaten me to this observation and logged a separate bug – only to find that someone had spotted a bug in what would have been my immediate fix to this:
If I’m on eg.
http://code.google.com/p/chromium/issues/detail?id=41493and select with the mouse “code.google.com”, then I want to copy EXACTLY this. I do NOT want to copy
Why do this? I hypothesise that they’re aiming towards a stab as security usability, or alternately I hypothesise that someone semantic has gotten at them and is trying to move Chrome to reinforce a pro-Google “every URL is a kind of search query” stance.
But a cascade of failures and issues has been created by this one small change; some excerpts:
Another nice example for real world unpleasantness this causes:
– Enter ftp.gnu.org/gnu into omnibox.
– That’ll take you to ftp://ftp.gnu.org/gnu
– If you want to go to the http version, you have to type in http://ftp.gnu.org/gnu
– Which will show up as ftp.gnu.org/gnu
What steps will reproduce the problem?
1. Go to http://ftp.mozilla.org/pub/mozilla.org/
2. Focus Omnibox (eg. hit ctrl+l)
3. Reload page (eg. hit
when in Omnibox
What is the expected result?
*WEB* page (ie. “http://” is reloaded
What happens instead?
User is taken to FTP server
Not true. Twitter, Facebook, code.google.com (using Google Chrome), Google Talk,
mIRC and Wordpad all would linkify if I pasted an http:// url. Try it. Notepad would
not, but it would paste with “http:// from a normal browser, which I would expect to
be in the clipboard for non-“web object” applications to fetch.
1) double click in the location bar to select the URL
2) middle click in another window to paste the URL. Note that http:// is still missing.
This is frustrating enough to me that I’m considering a move back to Firefox or Opera. Please revert this short-sighted change.
…plus there’s a bunch of “We Just Don’t Like This” whining – which unfortunately the Chrome team are flatly ignoring due to their certitude.
Some of the above are easily addressable bugs, and some of these are more complex; the big issues are twofold:
- The URL represents “how://where/what” – how to retrieve some data, at where, and what the data is called; as the above comments show it’s not wise to assume “all the net runs HTTP by default” , nor that “just because the hostname begins with ‘ftp’ you’ll be wanting to access it via FTP”; thus if for the sake of ‘pretty’ you choose to elide the how:// from a URL, you’re gonna have to create an complex mechanism for maintaining that information out of band…. and then you have to port that infrastructure to all your target platforms, thereby causing bloat and making more work for yourself.
- Removing choice from users is a bad idea.
Chrome had something simple that worked: “here’s the URL, copy what you want of it”; without explanation that’s been expunged and replaced with something that almost-works, almost-fits and almost-satisfies the userbase… and to what benefit?
Well, one counter-argument puts it thusly (paragraphs added for clarity):
@93 For the record, I’m not a Chromium developer. However, can you explain this behavior?
We’ve told you why the change took place. It’s redundant geek speak, that doesn’t need to be communicated to the average user.
Rather, a globe icon communicates what is happening better than text.
In the terms of copy and paste, we’ve asked for specific applications that are not linkifying the paste, and no one has stepped up to provide such an application. We’ve asked what bugs this causes, and all we’ve gotten is “I don’t like it” or “it’s pissing me off”.
I think we’ve been quite patient and level headed trying to assess what the big issue is, and the only thing people seem to keep bringing up is they don’t like it. In other words, it’s entirely subjective.
So, if you can remain level headed, and provide specific bugs reports or broken behavior due to the change, then we can look at those cases. Until those are brought up, whining and moaning about it isn’t going to do much, if anything.
This echoes an attitude I’ve described elsewhere; and it seems to be compounded by “there is never adequate reason for technical geek stuff to be thrust upon the ‘normal people'” – for some collective of ‘normal people’ with an IQ somehow less than average.
Somebody at Google itself, posted a thoughtful response to the above: (extract)
I really hope you understand that this is a fundamental change that affects the entire web and how people look at web addresses. This is reverting Tim Berner’s Lee decision to add http:// to web addresses.
If all the browsers would implement this and ‘http://’ gets wiped out of the global consciousness, it would be a fundamental change to how billions of internet users identify and recognize web addresses.
You have to have more reasons than “it feels redundant, we’re saving some space, a globe is so much prettier” when you are changing something so fundamental.
Let’s assume after a while all browsers implement this and all applications out there handle this correctly by linkifying everything. People get used to passing around www.foo.com without http. Everybody forgets what http even means, it’s just redundant geek speek.
I see a few problems with this
– it’s really hard to tell that you are ONLY hiding http:// and not other protocols. That globe means nothing to me. How do you explain to the user what protocol you are hiding?
– how do you do that consistently across browsers? Will everybody implement their own little globe to signify ‘http://’? Will there be something standardized?
– will you in the long term remove https:// because it’s redundant too? If that is the plan, then once this also gets wiped out of global memory, how do you explain to the users the difference between secure and insecure connections? The one with the globe and the one with the lock? 🙂
What I think everybody here is saying is that for such a fundamental change, you should have a better thought out answer other than “well, I’m a developer and I personally think this was redundant, so I removed it”. It’s a change that affects far far more than some space on the address bar.
My response is: there is usability, and there is stupidity. I think this change has inadvertently trod upon the latter.
ps: if anyone says “Safari on the iPhone does this”, read here.