4 ms·
> implementing what the standard says do show me the standard that regulates how browsers ought to display identity of the site. because everything you've said
by keymone 7y ago
> implementing what the standard says
do show me the standard that regulates how browsers ought to display identity of the site. because everything you've said is irrelevant otherwise.
- zAy0LfpBZLC8mAC 7y agoI already have. 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.