www must go, it's a remnant of the past, the sooner the better.
protocol is not a detail that should be ever exposed to the end user, at least not in text form. visual cues "you're safe" or "your connection isn't secure" are much more effective.
Post addresses should go away. "You're at home" or "you are away" displayed on your smartphone lock screen should do. For the rest, there's Uber. – I'm not so sure that this is how real life works. Understanding addresses (post or electronic) is an important part of liability and a sound mind. Also, how do you identify authority, if you do not know about uniforms or IDs?
a) you're confusing addressing something with presenting the address; b) you're completely (possibly intentionally) ignoring the context, which is all about specifically "www" part, the trivial non informative part that is just a historical artifact.
If in doubt about the historical context of the "www" subdomains: This was, when dedicated services were run on dedicated machines (or rather, dedicated network interfaces). "www" was just a default appellation (much like a well known address on particular services) for a server running W3 services. I don't see, why there isn't a use case for dedicated service domains anymore. (Not everything is WWW.) There's no magic to this and has never been. (The magic is in the port number as encoded in the protocol portion of a URI.)
Regarding the context of the example, all this is about navigating and about communicating how to navigate. Real live addresses tend to be much more messy, but they are bearable and users have been able to operate them for what is now several centuries.
it's just like your opinion man. not showing redundant information is good. if you disagree where's your rant about browsers lying about port 80 by not showing it?
if your point is that www.name.com can be different site from name.com - i disagree even more, this is a case of incompetent developers at name.com so redirect your rage accordingly :)
> a thing for websites to do
they'll do it eventually, doesn't mean browsers shouldn't be getting rid of redundancy.
> it's just like your opinion man. not showing redundant information is good.
The host name is not redundant information.
> if you disagree where's your rant about browsers lying about port 80 by not showing it?
Why should I write idiotic rants?
> if your point is that www.name.com can be different site from name.com - i disagree even more, this is a case of incompetent developers at name.com so redirect your rage accordingly :)
Well, great that you disagree. Now, please do the work of changing the relevant standards instead of making yourself look like an idiot by calling people who read and follow standards "incompetent developers".
> they'll do it eventually, doesn't mean browsers shouldn't be getting rid of redundancy.
>> if you disagree where's your rant about browsers lying about port 80 by not showing it?
> Why should I write idiotic rants?
You are not aware that all browsers currently hide port numbers in the URI bar if they are 80 or 443? For example, https://www.google.com/ is actually https://www.google.com:443/, but the browsers choose to hide this part. Wouldn't it be better if you actually saw which port the browser connects to? That way you can write https://www.google.com:13000 for example to try to connect to another port, but now you believe that those addresses doesn't exist. Removing these two standard ports from the address bar is therefore exactly the same as removing other standards parts, like https:// or www.
> You are not aware that all browsers currently hide port numbers in the URI bar if they are 80 or 443?
Which is why hiding the protocol is stupid. How do you know which port is being used if you don't know the protocol. You are actually arguing against your own point.
I know it is port 80 or 443 based on the protocol - it's deterministic. I don't know that www or m maps to the same place as the apex domain name.
> How do you know which port is being used if you don't know the protocol
by using the browser you opt into vieweing the web, which historically is used via http/https on ports 80/443, and just as historically, majority of web sites have www subdomain, which these days makes no sense to expose to users just like ports and protocols.
What a "majority of web sites" are doing is also completely irrelevant. If the standard says that it's a thing that you can do, and the standard says which behaviour the other party has to implement, and you are the only person on the planet to do this thing, the other party is still at fault if they implemented something else.
The whole idea of writing standards is completely useless if you can not rely on what a standard says. If something conforms to a standard, that guarantees that if you also conform to the standard, you will be able to interoperate with it. That is the whole point of writing standards. If either party does not conform to the standard, there is no value to the standard in the first place. If you are supposed to know what some random people consider sane, or the implementation details of everything that you want to interoperate with, and build your stuff for that, then you don't need a standard. The whole reason for writing standards is to eliminate the gigantic overhead and friction of that approach and to enable everyone to instead read only one document to ensure interoperability. All of that becomes worthless when you implement what you think is sane over what the standard says.
google.com could even be QUIC which could be any UDP port but in most cases is 443. That information isn't displayed either. Not to mention the difference of http1, http1.1, http2, quic, shouldn't the all be displayed if we really care about displaying the protocol?
The protocol is irrelevant. The identity is what this is about. URIs identify resources, and conflating different URIs is violating the relevant standards.
It's hiding though, not conflating, it isn't violating any standard. Not to mention, how is a protocol irrelevant but a "www." subdomain isn't? Both are equally useless for most users when browsing.
> It's hiding though, not conflating, it isn't violating any standard.
By doing what?
> Not to mention, how is a protocol irrelevant but a "www." subdomain isn't?
Because the "www." hostname is part of the identity, the protocol is not (if we are talking about HTTP/1.x vs. HTTP/2 or QUIC--HTTP vs. HTTPS is part of the identity, of course).
> Both are equally useless for most users when browsing.
That's irrelevant. It still is part of the identity of the document.
> You are not aware that all browsers currently hide port numbers in the URI bar if they are 80 or 443?
No, I am not, for the simple reason that that is not the case. Browsers hide port 80 only for HTTP and port 443 only for HTTPS, because those are the well-known ports for those protocols, and the specifications of URIs and those protocols define that no port in the URI is equivalent to the well-known port, and what the well-known ports are.
No, the browsers simply follow the relevant standards, as you can see from the links above.
> Wouldn't it be better if you actually saw which port the browser connects to?
No, there is no additional information in displaying the well-known port, as per the standards cited above, so it would be a completely useless waste of space.
> Removing these two standard ports from the address bar is therefore exactly the same as removing other standards parts, like https:// or www.
What do you mean by "standards parts"? Also, could you please cite the relevant standard that specifies that http[s]://www.domain/ is equivalent to http[s]://domain/?
> Browsers hide port 80 only for HTTP and port 443 only for HTTPS, because those are the well-known ports for those protocols
how is that different from "browsers only hide www part of domain name because this is a well known historical artifact and default behavior of any sane website should be to either redirect one name to another or serve the same content on both"
> how is that different from "browsers only hide www part of domain name because this is a well known historical artifact and default behavior of any sane website should be to either redirect one name to another or serve the same content on both"
That one of those is part of the relevant standards, the other is not. What your personal opinion is as to what a "sane" anything should do is just completely irrelevant for this discussion. You build reliably interoperable systems by implementing what the standard says, not by implementing what you would prefer the standard to say, because (a) if everyone just implements what they think is sane, that's guaranteed to fail at interoperating because everyone else will consider something else sane and (b) the process for building the consensus as to how to do things is the standards writing process, so if you think a standard is insane, you have to participate in the standards writing process to change the consensus on how to do things sanely, which then will be reflected in a new revision of the standard.
Whether something is well known is also completely irrelevant. "Well-known port" is simply a fixed term for "ports that have been standardized as the default port for a protocol", and the only relevant fact here is that the behaviour of not displaying the port number is standardized.
> you're being unnecessarily and angrily pedant.
No, your kind of reasoning is precisely how a ton of interoperability problems arise, costing humanity probably billions of dollars to work around each year.
There is no standard that says "how a browser ought to display identity of a site", at least none that I know of, but that doesn't mean that there is no standard that is relevant to how a browser should display URIs.
There is also no standard that says "how an email client should display email addresses". Now, suppose that some email client decided to always replace the TLD in any email addresses it displayed with ".com". Is that conforming to standards because there is no standard that says "how an email client should display email addresses"? No, obviously, it's not, because the address "foo@example.com" is not guaranteed by any standard to be equivalent to "foo@example.org", say, so this transformation causes an email address to be displayed that, according to the relevant standards, is not guaranteed to be semantically equivalent (mind you: that does not mean that they can never be equivalent--there is just no guarantee that they are/there is no responsibility for the owner of those addresses to make sure that they deliver to the same mailbox). Which is in contrast to, say, displaying "foo@ExaMple.org" as "foo@example.org"--those are guaranteed to be equivalent, so substituting one for the other is acceptable.
The exact same thing applies here for URIs. The URI and HTTP(S) standards specify which URIs are equivalent, and if your software displays one URI as a different URI that is not guaranteed to be equivalent, then that is in conflict with that standard.
in context of browsing web sites in the browser, www is absolutely redundant information.
> do the work of changing the relevant standards
since you're so much into standards, there is no standard for how browsers ought to display identity of the site provider that is being browsed. i also don't know of a standard that mandates anything specific about "www" subdomain. and i completely stand by the statement that serving different content on "name.com" and "www.name.com" is utter incompetency.
> in context of browsing web sites in the browser, www is absolutely redundant information.
Please cite the relevant standard that says so.
> since you're so much into standards, there is no standard for how browsers ought to display identity of the site provider that is being browsed.
Which is just willfully not understanding the problem? There is a standard for which URIs are equivalent to one another, and I linked you to it. Browsers displaying one URI as a different URI that according to the relevant standards is not guaranteed to be equivalent is obviously in conflict with that standard.
> and i completely stand by the statement that serving different content on "name.com" and "www.name.com" is utter incompetency.
Great, I understand that that is your opinion. But the standardized consensus differs from your opinion, and the standardized consensus has precedence over your opinion. If you think the standardized consensus is insane, then work on changing the standardized consensus rather than promoting breaking interoperability.
> then why did you bring it up?
I didn't. Different host names are not redundant, that claim is simply your invention because you don't like that they are not redundant.
www must go, it's a remnant of the past, the sooner the better.
protocol is not a detail that should be ever exposed to the end user, at least not in text form. visual cues "you're safe" or "your connection isn't secure" are much more effective.