Chrome 69: “www.” subdomain missing from URL

I'm using Firefox Klar (Firefox Focus for Germany): I have tabs (you can't open an empty tab, but you can open links in a new tab), the session history is enough for my needs, and I can disable JS under settings (and also web fonts, but not images (that's a pity)).

For logins I'm using Keepass Android Offline, Firefox Focus/Klar can use it as autofill service (neither normal FF nor Chrome can do this).

So for me FF Klar/Focus is the best Android browser at the moment, it superseded the normal FF (with ad blocker) on my phone.

Edited: bad autocorrects from Gboard.

A bunch of monkeys would have caught most of these bugs during testing - and have done a better job with the coding in the first place.

>http://www.example.www.example.com -> example.example.com

What the fuck. I don't even.

This is what Chrome's update is trying to fix. Developers are confuser when setting up dns if they should have www or not have www or only have www...

> I literally began my comment by citing this:

That comment seems to be a rebuttal to the point you're attempting to make. It'd seem more apt to say you brought it in to interrogate it, rather than to say you "cited" it, and beyond rhetorical frustration ("why would you do this?"), it's not clear to me that you engaged it at all.

> It takes only a very small amount of thought and empathy with the average user to understand how the extraneous www prefix can be confusing.

It takes only a very small amount of thought and empathy with the average speaker to understand how the article at the beginning of this sentence is functionally extraneous (and is even optional in informal speech), and yet isn't particularly burdensome to use.

Perhaps the thing you're claiming is prima facie obvious with "only a very small amount of thought and empathy" is instead an unexamined assumption on your part and reflects assumptions about the average user that you have no particular claim to over anyone else in this thread.

> It can lead to failures like thinking you have to use it with every website.

"Failure" is a curious term here. The overwhelmingly common "failure" of someone adding it is comparable to the "failure" of forgoing a contraction for its full expansion. Or the article example I used above.

It's technically possible, I suppose, that a www|m.domain.tld record will simply not exist. That's a reflection of the reality that www|m.domain.tld and domain.tld don't actually resolve to the same server, and pretending they do breaks DNS. And not only is it a good bet that the failure we're worried about is more common than the failure you're worried about, the sensible way to address the potential failure case you're concerned about would be to allow an implicit redirect reflected in the URL to take place only if the www record does not exist. That'd be the user agent being helpful instead of making assumptions that break DNS.

> It enables fraud by making “wwwexample.com” look more normal.

This is half a worthwhile point. But only half a point because unless one goes whole hog in eliminating subdomains entirely, you can't really take out example.com.internet2.ru, and even if you did, there's also example-internet2.com, so this is part of a class of problems prefix elimination can't solve, which is a sign that maybe it's not worth it if there are tradeoffs (and there are).

> Your comment is a textbook example of “the principle of it all” argumentation.

You keep using this phrase. It sounds like what you mean is "the people I disagree with don't really have reasons they're just attached to some convention that doesn't matter because reasons." If there's a more precise meaning, try rephrasing.

> You cite no concrete examples of problems caused by hiding www from the UI.

Since your comment didn't contain any clear criticisms of the recent state of things, it seemed best to see if I could elicit those first.

Also, the most prominent concrete problem examples of how this breaks DNS weren't exactly hiding if you read the linked issue.

On a deeper level, though -- and this is an answer to your interrogation of the comment you brought into the thread -- this also handicaps people's ability to actually learn by observation how domains and subdomains and others aspects of URLs work through observation. Presumably your natural response to this would be to appeal to the tastes of the average user and saying they don't care about such things and that's only a concern for technically advanced users and "don't make the user think." Spotting you the accuracy of that model of an average user (which I've yet to see a comprehensive case for), perhaps some of those things are true, and yet, as a combined package, the conclusions it leads to are often wrong. Why?

"Don't make me think" is a starting place for good UX. Not the end. The next principle for really great software might be best articulated as "make affordances for optionally advancing use." Learning how domains and subdomains work isn't required for anyone to use the web -- it never has been, because people have always been offered hyperlinks and search boxes from starting points. But the URL bar offers a real affordance for starting to unpack details of how URLS work (including domains and subdomains). An "average user" may never care to start with, but this isn't advanced tech, it's accessible to anyone who can learn how to parse the parts of a physical address, not by nerdy study but simply by incidental observation... all while not requiring people who may tune it out entirely to make any more effort than they might with the controversial change under discussion. Casting subdomain (or path) details of that language into an implicit and ambiguous new convention makes it less likely they'll pick it up. So even assuming this change can be made w/o breaking DNS -- which doesn't appear to have been addressed -- it's removing an affordance into a simple and relevant (if linguistic) tool for navigation/orientation.

So there's your harms to consider.

Cities and states superfluous from physically mailed addresses these days if all you want is for your letter to arrive. Sometimes it's convenient to even simply give zip codes in some exchanges of address info (or to collapse the whole thing into a bar code). Would you suggest that it's harmful or confusing to continue to have cities and states as an allowable convention in addresses? If some postal/shipping service mandated the convention of leaving out cities/states, could you see that there's a credible case for harm, though it's redundant information?

That's a comparable situation with www.

And beyond the marginal utility of space savings of ~3-4 character widths on a small screen, there's no argument I've seen for a benefit in removing it that stands up to scrutiny.

Its weird too because chrome invented to UX when closing lots of tabs not to reflow the browser UI but keep placing their close X under the mouse until you move away. So its like they understood this once and have forgotten.