What is meta? ×
Meta Stack Exchange is where users like you discuss bugs, features, and support issues that affect the software powering all 129 Stack Exchange communities.

When (accidentally) clicking "mobile" in the footer, one gets the mobile site in a regular browser too. To switch back, one can click "full site" in that same footer:

footer on mobile site

However: when hovering it, the mouse is changed as to select text, rather than to indicate one can click (even though it's clickable).

All other links do change the mouse into a pointer.

(Not a big deal, except when somehow accidentally getting into the mobile mode, I guess.)

share|improve this question
Tested in Chrome and Safari (WebKit) and Firefox (Gecko). –  Arjan Oct 1 '11 at 10:19
I found this to be confusing also. I got into mobile mode by accident... shrug –  GUI Junkie Apr 10 '13 at 11:44

4 Answers 4

up vote 1 down vote accepted

As I noted earlier in the comments, this should be fixable with one line of CSS:

a[onclick] { cursor: pointer }

As far as I can tell, this fixes the issue (and any possible similar issues elsewhere in the user interface) with no harmful side effects.

Since the SE folks don't, alas, seem very interested in fixing this, I've added the CSS rule above to the Stack Overflow Unofficial Patch, a collection of client-side CSS and JavaScript fixes packaged as a GreaseMonkey-style user script. If you're using a compatible browser (Firefox, Chrome, Opera, possibly Safari and others, but unfortunately not IE or most mobile browsers), please give it a try!

Update: In the upcoming release of SOUP (v1.17.devel) this rule has been generalized to:

a[onclick], a:not([name]) { cursor: pointer }

This rule catches some extra pointer-less pseudo-links that the earlier one didn't, such a comment delete links, and should hopefully still remain free of false matches.

share|improve this answer
It helps non-mobile users who may (intentionally or not) sometimes end up using the mobile view. As noted in Nick Craver's answer, users with actual touch screens will rarely if ever see a mouse cursor anyway. (Anyway, if you really want to try SOUP on a mobile device, there is a bare-bones Tampermonkey browser for Android with built-in user script support.) –  Ilmari Karonen Jan 25 at 12:51
Wow, you're absolutely right, and that was actually even the reason why I reported this. Somehow some wires did not connect in my mind this morning :-) (Removed my erroneous earlier comment.) –  Arjan Jan 25 at 12:53

Inspecting the footer links with Google Chrome, I notice that the other links use the cursor: auto property, while the "full site" link doesn't have that CSS property.

Actually, the "full site" link is merely an <a> element, without any "href" attribute, and with an "onclick" event that switches the format with a call to StackExchange.switchMobile(). For that link, the cursor should be explicitly set.

<div class="footer-links">
   <a href="http://chat.stackoverflow.com">chat</a>
   <a href="mailto:team@stackoverflow.com">contact us</a>
   <a onclick="StackExchange.switchMobile('off', '/?__=...')">full site</a>

footer link

"full site" link

share|improve this answer
Are you saying that it is common to have to explicitly set cursor: auto for <a onclick>? (When asking, I also noticed that the computed style matched what I saw on the screen. In a first revision I even copied the HTML into the question, but I removed that as I couldn't see any difference in the HTML to clarify this, assuming the CSS would not have different selectors for the JavaScript link. But apparently <a href> has different defaults than <a onclick>?) –  Arjan Oct 1 '11 at 10:12
Ah, even adding an empty href helps. I guess it's by design for the browsers then; still wondering why <a onclick="...">some text</a> is not defaulted to the same cursor! –  Arjan Oct 1 '11 at 10:18
And even adding a top-level a:hover{ cursor: pointer; } fixes this. (I know, that might show the pointer on other unexpected places.) I learned something today! –  Arjan Oct 1 '11 at 10:39
I guess that the cursor is not shown as pointer because, without the "href" attribute, the link is not really a link (which means it doesn't take you to other pages). For the browser such <a> element is just text, in the same way <a name="anchor">Anchor title</a> would be. Of course, the browser just checks if the "href" attribute is present, and it doesn't verify its content is an empty string, a not existing URL, or a malformed URL. –  kiamlaluno Oct 1 '11 at 11:04
@Arjan it's not explocit, it's part of the Chrome user agent CSS. –  Manishearth Apr 22 '12 at 10:22

Mobile devices that get the theme don't have hover, so we intentionally put little to no effort to support it...to instead reduce the load time as much as possible. Many areas don't have hover that traditionally would if you poke around.

Also, we have to use a JavaScript link (and cannot use a simple GET URL), to avoid abuse. Not all links should have the cursor: pointer style, as it can cause mobile issues, so the no-cursor is intentional.

share|improve this answer
Just to be sure, as for load time: this is not about hovering with some "title" attribute to provide some additional help. Also, we've seen some people accidentally getting on the mobile site. Did you consider that too? (I know of 1, 2, 3 confused users.) –  Arjan Apr 22 '12 at 10:15
Any reason for not using href? –  Manishearth Apr 22 '12 at 10:17
@Arjan - not all links should have the style, and it can cause mobile issues, so yes the no-cursor is intentional. –  Nick Craver Apr 22 '12 at 10:19
Very well, accepting this as it's the official answer. One more note though: it seems that adding an empty href="" and an additional return false; makes browser already treat it as a clickable link... ;-) –  Arjan Apr 22 '12 at 10:21
The problem is that this is confusing to desktop users who somehow end up on the mobile site and want to switch back. Anyway, a simple a[onclick] { cursor: pointer } ought to fix this in any modern browser without any collateral damage I can think of. (If there is something that would break, please tell me; I'm genuinely curious.) And if that's not specific enough, the rule could easily enough be limited to, say, only the footer on the mobile view. –  Ilmari Karonen Jan 24 at 0:17

I've noticed this before (when inspecting the mobile site on a desktop)

I don't think that the cursor is a big issue. Yes, it will show up on accidental switches to mobile, and I guess it makes sense to use cursor:pointer if it's being explicitly set.

What is an issue is that the mobile site is locked in with Javascript. In other words, you cannot leave the mobile site if Javascript is disabled. Thr same goes for joining the mobile site. I always use JS, so I don't care much about this, but it occurred to me that there are older phones that support a half baked version of JS. And switching to/from the mobile site is pretty important if your phone cannot handle the full site.

So, I ask the devs, what's wrong with href? Nothing to be lost by using it, and it's a tiny change.

share|improve this answer
Thinking about it, I assume some cookie/session magic is needed to ensure all links work without changing sites when clicking a link. Still then, some explicit URL to switch might still be doable, like example.com/go/mobile rather than some mobile.example.com. –  Arjan Apr 22 '12 at 9:59
It was a GET request, but since anyone could trick you into loading a resource with that GET URL, they could annoyingly switch you...the same reason logout has a confirmation button. There is a meta post doing exactly this that prompted the change: meta.stackexchange.com/q/98925/135201 –  Nick Craver Apr 22 '12 at 10:15
(Manishearth, indeed a /go/mobile could be easily abused by linking it as an image, like <img src="/go/mobile">.) –  Arjan Apr 22 '12 at 10:19
@Arjan you can still add an href and then just make onclick return false after execution. That makes a working JScookievoodoo link, and a working link in the absence of JS. –  Manishearth Apr 22 '12 at 10:19
@Manishearth - that doesn't at all prevent the case were talking about, if the GET URL works, so does abusing it. Also this is very simple JavaScript, for this argument to hold any water (even if it couldn't be abused), you'd have to show us a phone it breaks on...that has even a remote chance of handling our site in general, and I'm pretty confident such a device doesn't exist. –  Nick Craver Apr 22 '12 at 10:21
@Nick hadn't seen that (on mobile, no realtime updates). Ok, I understand now :) –  Manishearth Apr 22 '12 at 10:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .