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.)

  • Tested in Chrome and Safari (WebKit) and Firefox (Gecko).
    – Arjan
    Oct 1, 2011 at 10:19
  • I found this to be confusing also. I got into mobile mode by accident... shrug
    – GUI Junkie
    Apr 10, 2013 at 11:44
  • This can't really be a "bug" when mobile devices has no hover or mouse pointers. If mobile theme is used on a desktop computer, well, it's totally expected to have things missing in the design. :) Jan 2, 2018 at 10:30
  • Well, @Shadow, but your desktop browser does, doesn't it? And that's where I feel it's a bug. (And such an easy fix could be deployed.)
    – Arjan
    Jan 2, 2018 at 10:48
  • At most this can be something really really minor "nice to have". As feature request I would have upvoted this, but as bug it just feels wrong, as I don't consider this a bug. When in mobile theme, I expect the behavior to fit, well, mobile device. :-) Jan 2, 2018 at 10:51

4 Answers 4


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.

Update 2: It looks like this has been quietly fixed at some point, possibly as a side effect of the great CSS redesign of 2018. The mobile style sheet now contains the rule:

a, .s-link {
    color: #D58E10;
    text-decoration: none;
    cursor: pointer;

which makes all <a> elements have a pointer cursor by default.

  • 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.) Jan 25, 2014 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, 2014 at 12:53

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.

  • 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, 2012 at 10:15
  • Any reason for not using href? Apr 22, 2012 at 10:17
  • @Arjan - not all links should have the style, and it can cause mobile issues, so yes the no-cursor is intentional. Apr 22, 2012 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, 2012 at 10:21
  • 1
    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. Jan 24, 2014 at 0:17

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:[email protected]">contact us</a>
   <a onclick="StackExchange.switchMobile('off', '/?__=...')">full site</a>

footer link

"full site" link

  • 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, 2011 at 10:12
  • 1
    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, 2011 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, 2011 at 10:39
  • 2
    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.
    – apaderno
    Oct 1, 2011 at 11:04
  • @Arjan it's not explocit, it's part of the Chrome user agent CSS. Apr 22, 2012 at 10:22

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.

  • 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, 2012 at 9:59
  • 1
    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 Apr 22, 2012 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, 2012 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. Apr 22, 2012 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. Apr 22, 2012 at 10:21
  • @Nick hadn't seen that (on mobile, no realtime updates). Ok, I understand now :) Apr 22, 2012 at 10:26

You must log in to answer this question.

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