Earlier quoted context omitted.
The point is that the most common thing people do when clicking the URL is typing something else in the search bar, and the second most is copying the URL. In both cases, having the URL change is a problem, because this includes people who don't know what the http:// means or what a subdomain is, and don't immediately understand when a URL is the same as another. Your extra click saves my mother, and millions like he…
If you type something in the bar it doesn't matter what it shows. If you copy the URL, the fact that what you copy is literally different than what you're looking at is confusing. You copied "example.com", so why does the clipboard now contain " http://www.example.com/" ? > If we can get to a world where she can see an unfakeable padlock and read ‘facebook.com’, rather than remember whether it was ‘https:’ or ‘https.…
Chrome hides www and https:// in the address bar again
181–190 of 194 posts
Re: Chrome hides www and https:// in the address bar again
#182Earlier quoted context omitted.
I can't reproduce what you say, it doesn't prepends http:// in my case. Are you on Windows?
Yes, on Windows. You do have to select the first part of the url, but I often just want the host and port, ie localhost:8080 instead of http://localhost:8080
Re: Chrome hides www and https:// in the address bar again
#183Earlier quoted context omitted.
> It was impossible for the user to change either (in the stock OS). That's... much, much worse than dot extensions.
He's mis-stating it slightly. You couldn't fiddle with a file's creator code, but there wasn't much reason to. The type codes were editable, in the sense you could choose the default app you wanted to open files of that type, which is really what you'd want to modify most of the time.
BTW, I think you're referring to the 'creator' code, not the 'type' code. The 'creator' code determined which application would open a file when it was opened. And it was per-file; I don't remember any mention of a system-wide 'default application' or anything like that.
This was actually rather nice in practice. It meant a JPEG image created by e.g., GraphicsConverter would be opened by GraphicsConverter when double-clicked; whereas one saved by a web browser would be opened in the web browser. But either could be dragged into either application in order to open the web-browser-saved image with GraphicsConverter.
Re: Chrome hides www and https:// in the address bar again
#184Earlier quoted context omitted.
This was never a problem with classic Mac OS. Files had a type code and a creator code. The type code told application whether they could open the file. The creator code told the Finder which application to open when the file was double-clicked. It was impossible for the user to change either (in the stock OS).
Wait a tic - so the creator code forced the opening program to always be the same for a given file? There way no way to declare a preference that `.csv` files should now be opened with textedit or some such?
Re: Chrome hides www and https:// in the address bar again
#185Earlier quoted context omitted.
This was never a problem with classic Mac OS. Files had a type code and a creator code. The type code told application whether they could open the file. The creator code told the Finder which application to open when the file was double-clicked. It was impossible for the user to change either (in the stock OS).
> It was impossible for the user to change either (in the stock OS). That's... much, much worse than dot extensions.
The Finder maintained a 'desktop database' which, I believe, was used by the operating system to determine which Applications were able to open files given their type. This was updated automagically, so given a floppy disk with an application on it, and a file that could be opened by that application, the user could insert the disk, double-click the file and the application would be launched to open the file--even if the application was previously unknown to the machine in question.
Power users could use ResEdit or some other tool to change such attributes of a file.
http://vintagemacmuseum.com/macintosh-type-and-creator-codes... has some more info about the system. Also https://tidbits.com/2009/09/06/snow-leopard-snubs-document-c... which remarks on the system's retirement in OS X 10.6.
Reminiscing about all this makes me remember fondly how much better the experience of using a Mac back in the 90s was compared to computing nowadays!
Re: Chrome hides www and https:// in the address bar again
#186Earlier quoted context omitted.
On windows? I've never experienced/noticed this, what extensions are still hidden? Hidden files is a separate setting from hiding extensions (which is good), but I've never noticed a file that wouldn't display the extension after changing the setting. I can't remember specifically for any of the earlier versions, but this has been my experience on 7 & 10.
.lnk is one such extension.
Re: Chrome hides www and https:// in the address bar again
#187Earlier quoted context omitted.
> seeing the domain and nothing else likely improves security By hiding between 1 to 3 letters? It seems much more secure to do it like Firefox using grey for the unimportant part and black for the important part. If anything, if "m" is hijacked (by a feature actually to use subdomains), it's less secure because now he thinks he is somewhere that he isn't.
It's not always 1-3 characters. google-payments.sbc.net for example. For the third time, I'm not arguing in favor of Google's implementation. What I'm saying is that this has nothing to do with Google being out of touch with users as the GP suggests.
It will consider google-payments as being trivial and hide it? I may have misunderstood something, the article mentions clearly only "www" and "m" and if anything it made me read more and it seems like they no longer hide "m" (which make it much better because now the only mistake can be made only between www and without it, which should be quite rare).
> What I'm saying is that this has nothing to do with Google being out of touch with users as the GP suggests.
You said that:
> seeing the domain and nothing else likely improves security
Sorry but you are arguing that it will improve security. I'm asking you to prove that it does improve security.
I'm not arguing whether it's in touch or not with their users, it's meaningless, security is not an esthetical choice.
Re: Chrome hides www and https:// in the address bar again
#188"The Chrome team values the simplicity, usability, and security of UI surfaces. This change is the complete opposite of simple. Simple is showing the real URL. Complex is trying to remember in what cases Chrome hides part of the URL and trying to guess what website you're viewing.
Of course it isn't. URLs are largely made of useless and incomprehensible information for most users.
Re: Chrome hides www and https:// in the address bar again
#189Earlier quoted context omitted.
It's not always 1-3 characters. google-payments.sbc.net for example. For the third time, I'm not arguing in favor of Google's implementation. What I'm saying is that this has nothing to do with Google being out of touch with users as the GP suggests.
> It's not always 1-3 characters. google-payments.sbc.net for example. It will consider google-payments as being trivial and hide it? I may have misunderstood something, the article mentions clearly only "www" and "m" and if anything it made me read more and it seems like they no longer hide "m" (which make it much better because now the only mistake can be made only between www and without it, which should be quite…
My opinion on that bit isn't cemented in yet (why I used "likely"), but people are fooled by real-sounding domain names. They don't know what TLS is and they don't know what the prefix is, but they do know the difference between "google.com" and "avs.net".
Re: Chrome hides www and https:// in the address bar again
#190"The Chrome team values the simplicity, usability, and security of UI surfaces. This change is the complete opposite of simple. Simple is showing the real URL. Complex is trying to remember in what cases Chrome hides part of the URL and trying to guess what website you're viewing.
Simple is showing the full http headers. Simple is showing iframe urls. Of course it isn't. URLs are largely made of useless and incomprehensible information for most users.