After 19 years, http:// prefix is getting ditched (in Google Chrome) | Hacker News Reader

prefix is getting ditched (in Google Chrome)

code.google.com

98 pointsportman89 comments

I agree with the sentiment on the thread that removing http:// is a UX bug. Copy & Paste in this case is paramount over UI simplification. Keep it simple... do not make it a configurable option and do not remove http://.

The prefix is only removed from the "steady-state" display. It will still be there if you copy the URI from the address bar.

EDIT: Verified that copying works in the current nightly build, although there are some quirks pasting into rich text controls in some apps (like Pidgin).

I presume that you mean "copying" via Ctrl+C and not the X11 way of simply highlighting the text. The latter is known to be broken in Chrome.

I filed a bug for it that which was wontfixed: http://code.google.com/p/chromium/issues/detail?id=27972

Yep, I can confirm that pasting http: URIs from the X11 "primary selection" is broken in the current Chromium nightly.

I'm glad that got wontfixed. It's not the convention at all in Windows or OS X. I can't stand applications that unexpectedly mess with my clipboard. Lotus Notes does this all the time and it drives me nuts. I make an attachment, and bam, my copied text is gone.

But fixing this wouldn't affect Windows or OS X, and middle-click pasting is the convention in Linux. I hate when I use Windows and inevitably realize yet again I can't do it. (Also, highlighted text sends to a different clipboard than ctrl+c.)

I don't think anybody's ever got this quite right. It's especially frustrating working with Firefox and GNOME terminal. Firefox copies into both clipboards, GNOME terminal replaces the selection clipboard when I Visually select something in vim, then when I paste from what should've been in the selection clipboard, I get what I just deleted in vim. It seems the behavior wrt selection vs copy clipboard is inconsistent from desktop to desktop and version to version.

Yeah, Chrome is actually reasonably good about making copied URLs be valid URLs, backing out any display that was done to them in the URL-bar. Better than Firefox on this: for example, in the URL bar, both Chrome and Firefox display '%7c' as '|', which makes the URL invalid. But when you copy it out of the URL bar, Chrome turns it back into %7c, whereas FF doesn't.

The main odd UX issue is that you usually expect copying text to give you that same text in the clipboard, whereas in Chrome you get something magically changed.

How about removing it, but modifying the functionality of the copy action, so it appends the clipboard with http:// if the user has selected/copied the entire URL?

Personally, I have no qualms with http://, I just think this suits the best of both worlds: the future and the past.

What about https:// ?

Obviously the browser would know the true url, so it'd be able to just copy that.

Also, it seems the functionality I mentioned is already in Chrome.

There's another use case, maybe it's just me, but at least once a week I need to insert a single "s" into the URL to go from the non-SSL to the SSL version of a page.

My proposed solution: go ahead and hide the http://, but when you click onto the address bar (and therefore want to edit the URL), show the http:// at that time.

This solves copy-paste issues, changing protocol issues, and probably others.

But I'm not sure where to make that suggestion on the Chromium issue tracker.

My proposed solution: If it ain't broke...

Even better, but there seems to be tons of enthusiasm on the Chromium team for removing http. I'm just hoping they minimize the collateral damage.

Reminds me of another dominant tech company with a history of thinking it knows better than its users and making awful UI decisions.

Canonical?

controversial != awful

Sometimes doing things like that work, re: floppy drives and the iMac.

I'm sure the same thing was said about inner-tube tires. I mean, why re-invent the wheel?

Because have you ever ridden a bicycle with a flat tire? I hardly think the two use cases compare.

Anyway Comment #24 makes a lot of sense http://code.google.com/p/chromium/issues/detail?id=40865#c24 I see the enhancement for the end users who have NFI what http is but leaving it there provides more advantages as a whole than removing it.

That's a saying that works only when things fail. But if you applied it to everything all the time, then no progress will be made.

If I remember correctly, isn't this how the iPad does it? I don't have one so I can't check.

On one now and you're exactly right. Seems like the best of both worlds.

incidentally, the iPhone does it that way as well.

But you can still do this.

Just:

1) [F6] = Goes to the address bar and highlights the URL

2) [CTRL]+[C] = Copies the URL in it's entirety

3) [CTRL]+[V] = Pastes it back in the address bar, now with http://

4) [Home] = Go to the start of the line

5) [>][>][>][>] = Move beyond "http"

6) [s] = Insert the "s"

7) [Return] = Navigate

See! Google have already thought of this and this wonderful feature is available already.

PS: Down-voters are trigger happy, to them: This is a joke!

Considering how often adding an s to http is done (for example, I've only done this once, in gmail, before I saw the 'always use https' setting), I think that this is OK.

Still don't think it should be removed, though, just sayin' :)

If you want to discuss the http issue the place is chromium-discuss@chromium.org

Personally I don't see what purpose there could possibly be in removing it. The worst part is that it causes ambiguity about what will be copied (if the user was confused before about http they will be doubly confused when it magically appears after copying it).

I'm using the latest dev release that has this feature implemented. Let me tell you how it actually works. The location bar looks like this:

    news.ycombinator.com/item?id=1263512

When I select it and press Ctrl-C it copies this to the clipboard:

    http://news.ycombinator.com/item?id=1263512

Nothing is broken.

Useful to know, but I have to agree with portman. What about switching to an https: URL? Loads of sites default to http when they should be secure.

Perhaps it would be better to add a white 'Not identified' badge in the place where the green Certificate Name (or red broken certificate name) goes?

Clicking it would reveal a message that the site is not identified, and information being sent to it is viewable to third parties.

Nobody in my immediate family know what https:// means. They especially have no idea what its absence means.

... They especially have no idea what its absence means.

Oh, I wholly agree, this makes sense for the average user. It's just wasted space to most people. They've already dimmed everything but the domain name (a brilliant idea in every single way), making the prefix' "cognitive impact" rather minimal already. To that end, I don't personally see that removing it is necessary, nor helpful. So at best it maintains the status-quo, and arguably lowers it slightly.

But, since these decisions are largely made for the majorities, it does make sense that they're going that route; I'm not really annoyed, I'm just mildly disagreeing with the decision.

As to the white non-secure flag, I'd tint it slightly yellow so it raises an eyebrow for people interested in their own privacy; white is too ignorable, and much harder to see at a glance. On the whole, it's an interesting idea, as it'd effectively turn the whole http/https battle into a slight-but-real push to move to https entirely.

> As to the white non-secure flag, I'd tint it slightly yellow so it raises an eyebrow at people interested in their own privacy; white is too ignorable, and much harder to see at a glance. On the whole, it's an interesting idea, as it'd effectively turn the whole http/https battle into a slight-but-real push to move to https entirely.

Exactly what I'm thinking. Just raise it as info, then change it to a warning progressively over time, with some advance warning to web developers.

Try to copy "http://news.ycombinator.com to the clipboard.

On Mobile Safari, the URL is displayed without the http:// until you tab on it and it will include the http:// as the URL box expands.

This is clearly how hiding http:// should be done (if at all). Playing tricks with the clipboard is going to be confusing and frustrating to use. It is also suggested in other comments here; I hope the Chrome devs pick this up.

Copy and pasting using the X clipboard does not result in the addition of http://

Works for me.

Are you sure you weren't using the X primary selection (select, middle-click) instead of the X clipboard selection (usual ctrl-c/copy, ctrl-v/paste)?

It can't be hard to make copy and past work fine without http://. Fact is that it's mostly irrelevant for the majority of users.

Chrome address bar is very smart. It will decode the %xx%xx%xx escape to their recognizable original characters, e.g.

http://i42.tinypic.com/241kxhc.png

But when you copy the whole URL, it will be copied as the %xx%xx escape as every URL do

http://www.google.com/search?hl=en_US&query=%E6%B5%8B%E8...

Note if you only copy partial of the URL, not the whole URL, you will still get decoded text

All of the browsers I have installed, besides Opera, do this.

Safari FireFox Camino Chrome

"Keep it simple..."

I think the idea is to keep it simple for most users, not the techies.

I don't think many non-techies have any clue why the http is there, and they (rightly) don't care.

As for "adding an 's' for the secure site", once again, how many non-techies do you know actually do this? I'm not saying that's a good thing, but most casual computer users don't know about that. Hopefully they know about the lock icon on most browsers, but I actually kinda doubt that too.

I wonder how this will effect spdy://, Google's potential replacement for HTTP. Maybe it will be good; you can hide spdy:// too and make the difference transparent to the user.

I commonly use file:// and other protocols. How will it handle those?

Every URI scheme except http: is still displayed.

This includes https: as you can see in the screenshot: http://chromium.googlecode.com/issues/attachment?aid=-277348...

Not only the http:// prefix but the whole idea of URL is a notion that should not be user-facing in an ideal world. Even the pretty REST ones are the internet equivalent of the command line voodoo many non-technical users just don't get and type in or copy paste without knowing what it means. If the URL is too long only geeks understand its components, let alone edit it in place to go somewhere else.

It's debugging info for sure, but for most newbies is wasted vertical screen estate.

Bookmarks and web navigation via links are already hiding the fact that 'you go to URLs' now, entering a URL in the bar is the corner case because not everything is easily accessible from everywhere else in very few steps.

In the future the internet will be distributed and content addressable and not have a certain thing only available at a certain URL you have to remember, and then the URL will really go away. HTTP is client server, IP networks are peer to peer by nature.

In an ideal world, users would look at something they don't understand and figure it out. Not to a level of mastering all the underlying concepts, but to the level of becoming functional with it. In an ideal world, we don't feel the urge to hide something we think the user will not understand. Instead, in an ideal world, we teach the user. Be it by presenting the subject in ways the underlying concepts become clear and obvious, be it in showing them progressive levels of functionality and abstraction. In an ideal world, users are intelligent, curious and do not feel the urge to run away from things, they feel, are too complex for them.

It's disturbing when someone advocates the idea of dumbing down what is a powerful idea in order not to upset those who think they would be upset, preventing them from learning something useful.

I use URLs for many things, from describing database connections to navigating hierarchical datasets in data-driven visualization tools. There is a lot to it beyond HTTP.

The Internet is not a blue "e". It's not a place of consumption, but one of sharing.

And when it becomes distributed, like you say, URLs could really serve us well, not by mapping to server:port/folder/document.html but to content and letting the underlying, non-http protocols, work out what's the best place to get the resource you need. You say "in the future" but p2p file-sharing networks use URLs in the form of network://hash-to-what-you-want.

If you assume your users are stupid, not only will you limit you product to those who know little, but you will rob them the possibility of learning something.

By ideal world I meant 'a better internet user experience within the next a decade or two' not 'all people are intelligent' as you meant. In the latter we would not be crouching over a browser anyway but do more evolved stuff :)

We do not teach users what an URL is when all she wants is to read her emails, just as you do not teach them how that browser is written or how the data travels to and from destination. I share your wish that people would be more inquisitive and learn but some people are just not like that for various reasons or do not have time for that and trying to teach them stuff they do not care about flies in the face of good user experience.

You use URL for many things including DB connections, this makes you a technical person. One of the reasons user experience is still shit in many applications is that many techies are convinced the user should be exposed to all the wonders of the underlying technology and consider this the noble quest of teaching them.

Yes - network://hash-of-what-you-want is the content addressability I mentioned. So the 'locator' in URL is not going to be meaningful. You do not locate a resource, you get some stuff wherever it may be located - assuming it is in one single place and not built from bits located in various parts. Anyway it was a tangent to the main topic - even if we denote the content someway it should not be exposed to your users.

Try asking around your non-tech relatives and see if they understand what the components of simple web url-s are. My mom sure does not, and I have no intention of teahcing her that .com is some silly legacy from when it was thought that if you are a company that is what your webpage address, will be named like or what is with the slashes or even worse the ampersands.

I do not assume users are stupid, they just don't give a shit about stuff that is cruft and that has little bearing on what they actually do on the web.

The fact that tiny URLs are such widespread also underlines the fact that URL is a necessary evil by which you send someone to a resource and not something to inspect by people. There are complaints about them being opaque but much less then you'd expect given their massive use.

So do not try to teach people who do not care about learning because they will not learn and you'll have wasted your time on them.

> trying to teach them stuff they do not care about flies in the face of good user experience

The worry about "user experience" is the cholesterol-rich fast-food of design. It's terrible, dumbs users down, but, somehow, it's addictive. Imagine a world of immediate gratification and zero frustration. That's what many people are tying to build.

> they just don't give a shit about stuff that is cruft

Not everything you don't grasp, or that was decided before you were born, is cruft.

> The fact that tiny URLs are such widespread

Tiny URLs are a reaction against poorly-designed, overly complex URLs that convey little or no meaning. Nobody needs Bit.ly to go to http://www.google.com. I'm all in for not failing when a user fails to type http://, but I am completely against hiding it under a magical hood that will protect users from the dangerous unknown techniques under it.

Knowledge is power and, therefore, it belongs to the people. The better it's distributed, the better.

MobileSafari hasn't displayed http:// since its inception.

Yes it has. I remember the hiding of it being one of the changes in an iPhone OS update.

Alas, then I remember wrong. Regardless Safari has done it for a while. If someone can find discussion of its removal I'll edit my original post.

http://daringfireball.net/2008/11/treating_url_protocol_sche...

I can't seem to edit my post, looks like mobile safari has done this since 2008 for what it is worth.

If you tap on the address bar then it shows the http://.

Looks like Opera Mini removed it a while back also. I didn't even notice. :) So in the end, it's not that big a deal imho.

Tim Berners-Lee's "one regret" was the addition of the // to web addresses: http://bits.blogs.nytimes.com/2009/10/12/the-webs-inventor-r...

Just think of the paper we'll save!

It seems to me that this comment was the driver for this Chrome "feature."

The problem as I see it is that the Chrome devs are fixing it at the wrong place. Changing one user app, when the standards state it's necessary to include just breaks things.

They need to change the standard, not the app. Until then, they've just got a broken implementation.

I'm surprised there's so much discussion about this topic. This seems a very straightforward and logical UI improvement.

I suspect commentary on this has become basically a bike shed color argument at this point.

I am still unsure as to whether or not I like this.

One of the first things I do when I get to a page that requires my credit card information or any kind of username/password login information that can lead to a compromise of accounts that hold personal information is look at the address bar for the https:// in the URL.

Chrome still displays https://, and these days you should be looking for the company name anyway. See http://chromium.googlecode.com/issues/attachment?aid=-277348...

EV certificates don't solve anything besides the fact that now the cert companies get to charge more for an SSL cert.

Checking for https://<name of company> means I don't have to go hunting for where the EV cert sign is posted these days, the URL bar is still in a uniform location.

Ugh, I run chromium nightlys and this change has caught me off guard, I really don't like it.

I have been running the 5.0 dev channel builds for a while and I didn't even notice this change until I read about it now. I think it's OK. It has been done in such a way that it never bothers the user.

Honestly, I thought it was a bug until I saw this thread.

This makes absolutely no sense. Why try to fix something which is clearly not broken?

EDIT: Spelling

the 7 of 8 chars in prefix is irrelevant, so, replacing them with an mini-icon in UI saves space and improves readability.

The better question is - where are all favicons? =)

Favicons only in the tab bar. If you have too many tabs for the window's width, they stop getting displayed first on the selected tab (making the progress indicator invisible too) and eventually none of the tabs will have favicons as they get narrower.

The stupid globe icon they added opens a useless focus-stealing "Page Info" popup window that's missing most of what should actually be shown in it (like cookies). They moved the bookmarks star to the right of the address bar to make room for it.

might as well axe out the 'www' while you're at it.

not while there are still stupid websites that don't work without it.

A game site I used to frequent. I always thought that this would scupper new word-of-mouth visitors.

http://ntsc-uk.com/

http://www.ntsc-uk.com/

haha, nice

So let it be the browser's responsibility to try both with and without it. They'll either be the same, or one will be nonexistent or a not-found page; it's not like people put one site at www.x and another at x.

You would hope so, but unfortunately you'd be wrong - a tiny fraction of the time, but still...

Well that would seriously increase http requests and dns lookups which slows down everything.

For example:

http://pullmantransit.com/

http://www.pullmantransit.com/

Probably Apache defaulting to the first virtual host.

I am unsure if this is intrinsically stupid, but in our university, we have subdomains of the form www.faculty.university.de, mail.faculty.university.de, ssh-gate.faculty.university.de, mayflower.servers.faculty.university.de and so on. At least the ssh-gate is different from the www-server, and it appears the www-server is equal to the mail-server. Stripping the www here would be a world of hurt.

Long story short: the www is not necessarily stupid, especially if you use it to designate a web server from different servers.

there is absolutely nothing preventing them from still using subdomains while making the domain itself resolve to something useful.

No way. There's nothing special about www. Subdomains could well resolve to different IP addresses.

Sarcasm much?

Is this really true? Because I have wondered quite a few times. Is www.foo.bar just a subdomain like irc.foo.bar or mail.foo.bar? Is the default www.somesite.com basically just convention?

Yes.

Let's get rid of tld's, too!

AOL Keywords FTW!

I propose we go to Compuserve navigation.

Example: If you want google.com you type "go google" into the address bar and "Go CB" when you want a chat protocol.

ISTR you can't have CNAME on a domain name, which causes problems potentially with mail delivery. Everyone does it anyway...

You can't have a CNAME record for something that also has another type of record.... I think that includes SOA records or NS records. That may be where the confusion comes from.

There is also confusion regarding how they are resolved.

If an A record is requested, but a CNAME is encountered, the resolver will then look up A record for the resource indicated by the CNAME. If the CNAME is specifically requested, it will return itself as expected.

Couple this with different implementations of mail servers (and other stuff) not strictly following RFCs...... that led to a general consensus among many greying sysadmins now to try to avoid using CNAME records wherever possible, as they were more trouble than they were worth.

Thanks for the explanation!

http://no-www.org/

Reply on news.ycombinator.com