Considering how much is abstracted from the user these days, I've always wondered why something as technical and meaningless to the average user like "http:// hasn't been removed before. Good move I say.
What would you say about "www.", then? Shouldn't that be removed as meaningless, as opposed to the protocol prefix which a) identifies something as a URL, b) makes it detectable and parseable?
Well that's not really up to the browser maker to remove. The domain owner makes choices about subdomains and dns records. So if the domain owner deems www as the location for something, that can't be abstracted away.
The www. prefix is a special case for people; it literally means "its the world wide web" or "its the internet" to them. Technically, the subdomain is irrelevant. But, most people don't know this. They don't know how the internet works and (I'd suspect that this is true in more cases than you might think), think that www. is needed to get to whatever site they want to visit.
Of course, this is all assuming that they even type the address in, rather then searching.
I generally just type in the name of the site that I want:
'amazon' for www.amazon.com
Firefox is generally smart enough to take me to where I want to go. The only issue is when some hack site games it's way to the top of a search result for something else, but I've only run into that a few times.
Which is itself an issue -- since many browsers are now turning the 'address bar' into a combo search+address bar, novice users may not even realize what the difference is (or was).
You are right - but I think there is a difference in that omitting http:// doesn't break so many things.
Try this link: http://www.news.ycombinator.com for example - this is what happens to most addresses not prefixed with www. This means that hiding the www. would mean waiting to work out that the site doesn't exist (or the connection is down) before trying the non www. version, and worse that you would get the wrong site if www.foo.com and foo.com were distinct. Hiding the http:// doesn't have such massive implementation issues.
Right. My point was supposed to be that the average user doesn't know about these implications. And since it actually makes a difference in what page is viewed, don't hide the www. from them. Sorry if I wasn't too clear.
But we're not talking about removing http:// from actual urls, just from the display in the address bar. I guess you're saying that seeing it in the address bar highlights that it's an important part of an actual url, which is useful for education?
I do. At least, when untrained people consistently see this prefix, they will be less surprised when they actually have to use it (like when copy-pasting). Or they could ask what this gibberish actually mean.
I like not seeing the http. But I hate that now when you copy-paste, it doesn't do plain-text anymore. When you paste the url in email, it shows a hyperlink to example.com/page while linking to http://example.com/page. I would love it if onfocus event for the address-bar shows the http and selects the full address and copy-paste just copies the plain-text url.
I hate rich text copy/paste. I probably only want to copy formatting 5% of the time. Do any operating systems provide ways to configure how copy/paste works?
It's not exactly "configuration" but Mac OS apps usually have "Paste" and "Paste and Match Style". The latter being basically a plain text paste with the current app figuring the rest. (that's what it feels like at least)
However, I have seen a few times where it doesn't really work as expected. Not sure why.
And I also dislike rich text copy/paste. One example that comes up often for me is that I copy the link to a comment on HN and paste it to Gmail, and it just shows up as "link". Stupid.
> Since 99.999% of the people only ever encounter http://, ftp://, and https:// (did I forget any?), why not create a standard set of easy-to-understand icons to replace them, in cooperation with other browser makers?
For me at least it's a lot harder to memorize the meaning of a 16x16 pixel image than a four-character string.
Also, we have exactly the same problem that Google's having with this, which is that it's difficult to copy/paste, to speak nothing of entering in a url you have written down.
Good move, overall. Every browser I know of automatically inserts the http:// and has for some time now. Removing the visual component of this just completes the abstraction that's already there.
The author suggests replacing the string of text with an icon, like RSS. But the RSS icon quickly went from "standard" to "indecipherable clusterfuck" in practice. http://images.google.com/images?q=rss%20icons
The "http:// has been replaced by an icon. I suspect it's supposed to be a small planet earth icon, but the color choice makes it look like the moon, and the continent placement makes it look like a squinty smiley face when viewed from a few feet away.
I can see the obscuring of http:// being useful way back in 1995, but in 2010, it seems kind of a moot point given how ubiquitous the act of web browsing is.
To be entirely honest, I can't see how it would be useful either in 1995 or now. A person either cares about URLs or they don't. In the first case, the URL should be displayed properly; in the second, they won't have a damn clue what all that funny text in the box at the top of the screen is anyway, so you may as well show it properly.
The scheme is an essential part of the URL. Copying an URL from a browser's location bar used to be a reliable way of sharing links, but this change introduces a greater potential for errors (there's no reason to assume an https resource is available via http, for example).
Copy-pasting includes the scheme (mostly, there's a couple bugs at the moment). Better to read up on the issue before commenting about how it's supposedly broken.
I didn't say it was broken, but that the change increases the possibility of errors. Look at the other links provided in this thread to see why this is so. I stand by my statement, which I made after reading up on the issue.
Not consistently. This is a critical part of URLs. Not displaying it is like not displaying zip codes in US addresses (I recently lived at an address that differed from a nearby address in zip code only. We were constantly returning misdirected mail to each other.).
It (https) is displayed consistently in Chrome's address bar though. I agree that the scheme is a critical part of a url. The question is whether a real url must always be shown in the address bar.
I've already been bitten from this change a half-dozen times. Every time I want to share with someone an url I have open in chromium now, I have to manually type "http://.
Hopefully they will eventually fix it so copying from the location bar will include the full url. (Complicated of course by the fact that a user may only copy part of the url, leaving off eg "?foo")
Since the OS X pasteboard is clever enough to add http:// back in when copying the url from the location bar, this actually works pretty well on my Mac. I like it too.
I can see how it'd be intensely frustrating if the pasteboard doesn't work, though.
Only if you copy the entire link. If you try and extract a subsection like a directory, by either dragging across, or by shift unselect, it will not copy the 'http://.
A fringe case? Maybe, but I've already run into this pain a few times jumping back and forth from chrome to emacs.
Furthermore, select, right-click, "copy" uses a different clipboard from select (the latter is what other X11 software uses and the "http:// is never put there).
Read the thread... doesn't seem like a 'hard' problem, rather, it just seems like there are multiple ways to handle the issue and they haven't decided on which one yet.
WYSIWYG copy/paste is binary. It either is, or not. You can't tweak binary.
WYSIWYG copy/paste is bound to break at some point. But it should be pushed as far as possible to complex tasks not floated into the most abstract action - copying an address. The issue is conceptual, it is unrelated to implementation.
