But it's kinda crazy that if I'm on my phone I can't just share a URL to a page with someone who happens to be using a desktop. While I'm not sure if this is made explicit in any of the RFCs or standard docs, in my view a URL should be a locator for a resource that is agnostic of the user agent.
> in my view a URL should be a locator for a resource that is agnostic of the user agent.
You're not making sense. The mobile page has a dedicated URL. If you're browsing it, then sharing the URL will send anyone else to the same resource you're browsing, regardless of their user agent. Everyone agrees that this is a bad thing for you to do. Don't do it.
The standard page will redirect mobile user-agents to the mobile page. It is a better URL to give out in every possible way. But note that this is the opposite of what you're saying; the URL that behaves the way you say you want is the bad one that you should avoid sharing.
I am sympathetic to the view that the URL should just point wherever it points. This would require a change to Wikipedia's standard page so that it would display when requested on mobile instead of redirecting. That's fine. But sharing mobile links would still be awful behavior. Link to the standard page. That's what makes it the standard page.
What am I mistaken about? This is exactly what I said happens. I focused this information pretty heavily:
>> The standard page will redirect mobile user-agents to the mobile page.
>> I am sympathetic to the view that the URL should just point wherever it points. This would require a change to Wikipedia's standard page so that it would display when requested on mobile instead of redirecting.
No one is talking about what should happen. They're saying that, as you've confirmed, m.* is a separate resource from en.* because they exist as 2 separate pages on wikipedia.org. On the en.* page, people on mobile are incorrectly redirected to m.* which it seems that everyone agrees shouldn't be the behavior. The opposite, m.* redirecting people on desktop, doesn't occur.
That means that your statement that "URLs should be for a specific resource" contradicts your other statement that "sharing that URL ought [not] to send anyone to the mobile design". If the mobile page is a separate resource, then sending someone a link to m.* should always load that resource (the mobile version) which seems to the be the opposite of what you're suggesting.
Additionally, there seems to be additional confusion because everyone is assuming that the page loaded at m.* is the same page as that loaded on en.* but that doesn't seem to be the case as the page isn't responsive. It's the same text content but the stylesheet and headers are different which, by web standards, is a separate resource.
Everyone agrees with you on this point. You shouldn't need to manually manipulate anything but, because Wikipedia keeps a desktop resource and a mobile resource, there is a distinction and so you do need to manually manipulate it if you're sending a link from mobile to someone else and don't know their device. That doesn't change the fact that sending a mobile URL should always show the mobile page because that is, in fact, a unique resource and, therefore, has a unique URL.
As I've explained, even knowing their device is not sufficient, because someone on a desktop device may prefer the "mobile" design (which is responsive) or someone on a mobile device may prefer the desktop design (because it apparently contains more features). And if you're sharing the link with multiple people or publicly, you obviously can't accommodate mutually exclusive preferences.
If en.m. is asking for the mobile version, then en. is asking for the desktop version, yes? So why does en. redirect to en.m. on mobile?
It reflects the fact that standard pages existed before mobile pages did.
It's relevant that there are functional differences because those are not presentational differences. HTML is for content, CSS is for presentation. If the HTML is different, then it's a different resource and, therefore, gets a different resource locator (URL).
The use case is: I go to the standard wikipedia page, browse a bit, and then I want to give out links to the standard wikipedia page of a specifig article.
This is currently not possible without editing the URL if you are on mobile. And I dont understand why wikipedia is refusing to fix this.
This is pretty obvious in the general case, where it would be impossible for me to know if the URL I am visiting contains information about my particular user agent and is thus inappropriate to share with people with other user agents. When my user agent requests "en.wikipedia.org" and receives a redirect to "en.m.wikipedia.org" there's simply no way to know whether this resource has actually moved to a new URL (which is the semantics of the HTTP response) or whether this is simply a special URL that I shouldn't share. Yes, some people might be familiar with the "m." subdomain for mobile-specific websites, but in general this sort of thing is (in my opinion) an abuse of HTTP redirects.
As I just pointed out, and you somehow misunderstood, this is the exact behavior of the mobile page. It is not the behavior of the standard page. But sharing a link to the mobile page is bad, and sharing a link to the standard page is good. Keep this in mind when you're deciding how URLs should behave.
This is how mobile wikipedia pages behave. What part of that do you disagree with?
Share a mobile page's URL and the person following your link will see the same page you do, no matter what your user-agent is, no matter what their user-agent is, no matter what device you're using, no matter what device they're using.
This is the problem. The behavior you are looking for, of different people seeing different content according to their user-agent, is also provided, and it's provided by the standard page.
And I would argue that this is not only the point but the problem we are talking about. It makes the m. pages appear all over the Internet although they are less suitable for some devices (they are, I'd argue, even less usable because, e.g., the page history is missing when you are not logged in).