Live data from Hacker News

Chrome 69: “www.” subdomain missing from URL

bugs.chromium.org

321–330 of 919 posts

Re: Chrome 69: “www.” subdomain missing from URL

#321

Earlier quoted context omitted.

They didn't care so far because it was so confusing. The hope is that by showing something that's user-relevant (the name of the website name and the security level), it will become more useful for the average user. Why should a user see: https://www.wikipedia.org/wiki/Canada?utm=asdioasd&arg=j210d... when all they care about is "Wikipedia.org/wiki/Canada"?

Because there is a huge difference between those two: https://en.wikipedia.org/wiki/Canada https://fr.wikipedia.org/wiki/Canada

If the browser absolutely 100% of the time knew that difference and showed "Wikipedia FR > Canada", wouldn't it be much simpler for the average user?

The browser could even show specialized UI such as "FR" as a clickable dropdown menu to allow users to switch languages. Chrome already does this for searching a single website through the address bar (type domain.com TAB)

Basically these changes are not thought for you. You are not representative of the average Web user.

Re: Chrome 69: “www.” subdomain missing from URL

#322
post #220

Earlier quoted context omitted.

Those go to the same place for me

Some small subset of pool servers run an HTTP server that redirects you to www. Not all of them. You just got lucky.

I must be lucky too, as I got the same result from both.

Re: Chrome 69: “www.” subdomain missing from URL

#323

Earlier quoted context omitted.

I'm guessing it's related to mobile. Limited real estate means removing www gives you 3 more characters on the end of the url.

Pendantic hat on: 4 www.

Proportional fonts, so no the '.' doesn't get you a full character.

Re: Chrome 69: “www.” subdomain missing from URL

#324
post #30

This is idiotic and harmful. We already lost information about the protocol, because somebody believed it is "too complex" for users. Now we're losing other parts of the URL. It's making a joke of the SSL/TLS padlock, too — what exactly is the padlock supposed to tell me? It used to signify that a "known authority" certified that I'm connected to whatever I see in the URL bar. But now that browsers take liberties wit…

You can still click and see the whole URL. This is just making it easier for the average user to see the most important thing to them, which is the domain name. It's not like they're just changing stuff randomly. The TLS padlock change has been going on for a while now, and not without reason. As we get to a point where almost everything is served over TLS it doesn't make sense to tell the user every time. It makes m…

> "This is just making it easier for the average user to see the most important thing to them"

This is exactly the wrong way. The domain name system is simple, easy to learn, partly, among other, exactly because it is without ambiguity. It has been an essential part of our lives for several decades by now and users should be expected to undergo the effort of looking into how it works for 5 minutes once in their lifetime. (Arguably, parsing a URL is an important and essential skill nowadays, like adding.) Obscuring it and introducing ambiguity doesn't only not help, it is an essential hinderance to understanding.

Re: Chrome 69: “www.” subdomain missing from URL

#325
post #238

Earlier quoted context omitted.

It's not a shoddy implementation on Citibank's part. Google are just fucking the web over so we all have to fit their structure. This is standard incumbent behaviour, they are drawing up the moat bridge, inch by inch.

I think the downvotes here are uncalled-for. This is correct. Google is leveraging a dominant market position to make seemingly frivolous changes that will ultimately benefit them commercially. Come on, you know where this is going: They are going to hide amp subdomain, so you don't know if you're looking at AMP or the actual destination. And then suddenly the whole world funnels through AMP.

> Come on, you know where this is going: They are going to hide amp subdomain, so you don't know if you're looking at AMP or the actual destination. And then suddenly the whole world funnels through AMP.

That's probably the reason for this utterly bizarre change.

Re: Chrome 69: “www.” subdomain missing from URL

#326

Considering a subdomain "trivial" is ridiculous... there's a difference between "www.example.com" and "example.com". Not only can they serve different sites, they can even have different DNS records! It seems that "m." is also considered a trivial subdomain. So when a user clicks a link to a "m.facebook.com" uri, they'll be confused why FB looks different when the browser reports it's on "facebook.com". I sincerely h…

>there's a difference between "www.example.com" and "example.com" Can you link to a site where these two are different?

Someone mentioned www.citibank.com.sg vs citibank.com.sg in the issue.

One of my school's websites: I can't remember what it was and this was before I understood what the difference is, but www worked much better than without iirc.

This also applies to m.*, so literally any web-app with a mobile version.

Re: Chrome 69: “www.” subdomain missing from URL

#327

If the browser uses some technique to detect that www.domain.com is functionally identical to domain.com for a given domain, then I don't see a serious problem with this. But if they are short of that certainty, they're obscuring a critical part of the URL, and harming usability (e.g., if I want to jot down a site's URL for later use, I might get something unexpected).

Well, browsers already support a better form of this feature. On the server you setup a redirect to your preferred domain. You redirect https://www.example.com to https://example.com or vise versa.

Re: Chrome 69: “www.” subdomain missing from URL

#329
post #274

Earlier quoted context omitted.

Because arguments aren't always useless like in your example. Might as well just do away with the whole URL bar and just have a green checkmark if Chrome thinks it's the site you want. I mean, why should a user see "Wikipedia.org/wiki/Canada" when all they care about is "This is the Wikipedia Page for Canada"?

I know you’re being sarcastic, but if chrome could, with perfect accuracy, indicate if this was “the site you want”, why not do away with the url? Mind you, I’m not suggesting to do away with linking, as some rando suggested this implies. (While chrome doesn’t show the protocol prefix, it still copies the prefix when you copy the url, so imagine a similar ui.) But for most users, wouldn’t a ui that shows “server iden…

If we could, I'd be all for it. Have an option that says "show URL bar or not" and by default hide the URL bar, optionally show the whole thing. Especially on space-constrained devices like cell phones where every pixel counts. Just show the page's title.

I think we're a long way away from that ideal, though, and some web pages may not be designed with this ideal in mind.

Post reply on HN