No it's not. You're being overly technical. A typical user expects to see where they're going to end up. Not the first link in a chain of transparent redirects. Even if you disagree it as at the very least controvertible. I can see how a web developer would have assumed it was expected. And in that case, it wouldn't have been intentionally deceptive. That's all I'm trying to say.
Unnecessary state should not be present in the URL. Yeah, people do it all the time, but it's sloppy coding and bad for many reasons, including those described in the article.
The rationale is that everyone interested has been doing this with redirects (for years) in non standardised and often opaque ways.
So it’s better to standardize and make it transparent.
E.g. google search results get rewritten to redirects as soon as you hover over them or press them (and are redirects in the first place with JS off). Have been for at least 8 years now.
"Other people do it," by itself, is not a great justification.
It's yet another way to mislead. Just because other misleading schemes exist doesn't mean this isn't also misleading and potentially bad.
As for "How so" ... I didn't think it through. I'll go with "potentially not good," but equally not thought through. Since the subject of the article is URLs as UI, when you send someone a URL to "look at this", what they see is the URL, and in my example the human readable part is "the site" and "a3n", but what they get is nothing to do with a3n.
I can only intuitively start with "that's misleading," and imagine (but not point out) the possibility of "something bad". Maybe something merely annoying like rick-rolling.
>> For example, what if the sender types in `You should go to http://ww.example.com, where "example" must be replaced with your company name`? Suddenly `www.example.com` has an unintended DDoS!
> Ah, so that doesn't happen if the sender types in the wrong thing in HTML...?
I can't tell if you're being purposely contrarian or simply don't understand users.
The problem: Things that shouldn't be links get turned into links.
Your response: $SOME_OTHER_PROBLEM
I mean, really? You can't tell the difference between someone making a typo when intending to write a link and someone making a typo that results in a link?
"Showing another page" is not a manipulation? So the redirects of yore when you would change the link-text to a URL that does not match the link-URL is not a manipulation? That is effectively what imgur does.
I wasn't commenting on this particular example, just pointing out that for most caseses the use of anchors in the URL is normal and functional and not just a JS SPA thing.
Hasn't this been the expected behavior since the dawn of the web 2.0? Next he is going to complain that websites can have a hyperlink that says example.com but points to badexample.com! And worse yet, they can use js to hide their tracks! (ie, google search click redirects)
I simply don't believe that mistakenly saying "links" instead of "URLs" is sensationalist. The author is not engaging in clickbait by substituting that word. A layman understanding of the web will not make a distinction between a URL and a link. The issue is clearly the fact that the browser deceives the user, whether it is changing a link in a page or changing the URL typed in the address bar, these are both equally deceptive from the user's point of view.
Hell, I have a reasonably good knowledge of the terminology and I will regularly ask people to "send me links" or "send me URLs" interchangeably. It's just needlessly pedantic.
By design, the web is a "1. send me the document <-> 2. here it is" transaction, not a series of many small notifications. By design, the url() property almost certainly wasn't intended to be dynamic. This is clearly 'bending the established rules' — cleverly, admittedly.
> But that's useful information that's told me redundantly by the page title and the banner at the top of the page also. I don't need the URL bar for that.
The page isn't required by anything to contain that information or to give it accurately. How do you distinguish example.edu/financial-aid/ from example.edu/~some-student/ ?
> In fact, using the URL bar for it assumes that the path has semantic meaning, which is not an assumption that the URL standard actually requires.
It doesn't assume anything, it just shows you the URL. If it has semantic meaning then you can see that -- which it commonly does.
> I somehow like looking at URLs but am I supposed to edit them as an end user or draw conclusions from their look?
People shouldn't be drawing conclusions from the URL (apart from the query string and the domain part, but that latter is a whole other story). The URLs are supposed to be unchanging and not break, and that's strongly incompatible with having them contain human-meaningful information. And in particular (though not exclusively) with using path-segments to communicate a tree structure for your website. Such tree structures are inevitably torn down and replaced over time on most long-active websites (especially those which are the public-facing homepage of a long-lived organisation), and the result of placing them in the URL is inevitably link breakage. Hiding the URL by default is therefore good, as it should help to prevent the user from seeking meaning in the URL or the site owner from placing it there.
And links (with the exceptions noted above) shouldn't contain meaningful information for automated use either: it's Hypertext As The Engine Of Application State, not Link Structure As The Engine...
(Tree-structured site guides are fine and useful means of navigating, by the way; they just don't belong in the URL.)
Doesn't actually seem to be an intentional redirect, though—if you truncate everything past the "b" in the URL, it still works (and similarly for other blog posts). I have a feeling it's just doing a "best match" based on the URL.
> The problem is to end up at "noindex site" thinking that the "noindex site" is a competitor site
And there is no solution for that, it seems. The solution for the problem <red in address line>'hey, that's noindex site!'</red> is obvious and simple.
> And I don't see how such deception is possible without the backbutton-bug
You told it yourself - 'you can just call the URL directly in browser'. And there are many ways and scenarios how that clicking on a link could happen.
reply