Hacker News Reader

Comment by basch | Hacker News Reader

if anything, it should be time to declare that its a bit insane to expect lay people to be able to read from right to left and left to right concurrently, and understand all the delimiting punctuation correctly, along with unicode. its time to restructure url rendering to be right to left, and combine delimiters. dashes, periods, slashes, and subdomains and hundreds of tlds have made it too confusing.

https://www.google.com./ should become either https/com/google/www/ OR secure/com/google/www/ OR secure.com.google.www. Browsers can then just always bold the third word?

View on HN

I think re-ordering like that would actually benefit technical users more, but it's probably too late to make such a change. I don't think we'd need that change for browsers to put the parts they consider most relevant in bold. That logic is simple enough right now.

really we are talking about rendering, right? not actually changing the protocol itself? (:lock: = lock unicode/emoji = secure http)

:lock:/com/GOOGLE/www/maps/hawaii

I am a strong proponent of the URL being part of the user interface. I should be able to manipulate what i request of a service by modifying the url. The text in the url should mean something.

Making the rendering that different from the actual URL would be very confusing, especially if it varied from program to program or within programs. Links would look one way on websites and then have a completely different form in the url bar after clicking them.

That particular rendering choice would also have the downside of being the same for both https://www.google.com/maps/hawaii and https://google.com/www/maps/hawaii

Yeah you might have to double punctuate after the subdomain, BUT it still makes it clear what domain you are on.

https://com/google/www//maps/hawaii

And its not like the browser couldnt render it both ways, either on click or hover.

And how would the client distinguish the part that goes to DNS from the HTTP path?

double punctuation?

https://com/google/www//maps/hawaii

Why even bother with URL language? It should just be 'Google Search' in the bar and you can see the URL if you want.

I have many websites which I don't let Google to index, how would my users access them?

If you're not in Google's index, then it's likely you're not in Google's interest to use Google's product to visit your site, since the company prefers if you use their search rather than type links directly or follow links from other links, hence they want to kill the URL — https://www.wired.com/story/google-wants-to-kill-the-url/

What's your rationale for this? The removal of the superfluous www subdomain makes sense. It puts to actual unique site information immediately after the padlock.

Most sites either redirect to it away from www when you visit them anyways.

People have always said to host your site at www and redirect to it, something I have never understood nor heard a convincing argument for.

I have my servers configured to redirect visitors away from www.

> People have always said to host your site at www and redirect to it, something I have never understood nor heard a convincing argument for.

It comes from the long-lost days when people actually ran their own servers, and would have [www,mail,ns1,ns2,intranet,chat].example.com servers. If you already have a lot of special-purpose domains, it seems weird to privilege "www" as the real example.com, so the recommendation was to redirect from it.

I had some years I thought the same way, however:

From a DNS point of view: you can't have CNAME's on your root (can be useful, especially in some DNS load balancing situations, or load balancing on third party providers)

From HTTP point of view: A no-www domain might not be the best solution if you ever want a 'Cookie-free Domain' (static.) for images etc. which speeds up your site. If you start with a no-www domain you have to setup a different domain (no subdomain) for it: like sstatic.net for SO, ytimg.com for YT and yimg.com for Yahoo.

When the browser makes a request for a static image and sends cookies together with the request, the server doesn't have any use for those cookies. So they only create network traffic for no good reason. You should make sure static components are requested with cookie-free requests. Create a subdomain and host all your static components there.

If your domain is www.example.org, you can host your static components on static.example.org. However, if you've already set cookies on the top-level domain example.org as opposed to www.example.org, then all the requests to static.example.org will include those cookies. In this case, you can buy a whole new domain, host your static components there, and keep this domain cookie-free. https://developer.yahoo.com/performance/rules.html#cookie_fr...

in my view having a www record (and no-www redirect) has more benefits that a no-www

Reply on news.ycombinator.com