This is something I've always wondered. On all major operating systems, application menus (File/Edit/View etc) only appear on click. However, nearly every web site that uses a drop-down menu instantiates it on hover, not on click.

How and why did this convention come about?

  • 1
    Come to think about it, the hover approach seems superior to the click approach. Why am I forced to point and click the "File" menu entry?
    – jensgram
    Commented Aug 24, 2010 at 11:29
  • 13
    Hovering might be accidental, while clicking is intentional. I'm also not sure touch screen users will agree about the hover being superior :)
    – Dan Barak
    Commented Aug 24, 2010 at 13:09
  • 1
    +1 for mentioning touchscreen. Also true of other mobile input devices, i.e. BlackBerry's trackball, etc. Hovering may be nice, but for maximum accessibility, allow clicking, too. Commented Aug 24, 2010 at 18:14
  • Probably because of the "3-click rule", which is a myth. uie.com/articles/three_click_rule
    – Miki
    Commented Aug 25, 2010 at 16:36
  • 2
    Nothing annoys me more than an action taking place due to me hovering over a menu. I'd much rather click to get feedback. I forced the click on intentionally. I may or may not have intentionally hovered over a control.
    – user708
    Commented Aug 27, 2010 at 18:03

6 Answers 6


I have no idea as to the actual correct answer to this question, but let me speculate: I think it's because the web has hyperlinks. Clicking on something on a web site is associated with visiting a different page, and as such, if you were to create a dropdown menu that activates on click, the expectation of what it may do when activated is uncertain: will it direct me to a new page or will it pop open a menu? So if you continue that line of logic, creating hover menus makes a lot of sense, because before a user clicks you can present them with feedback indicating they've activated a menu.

It may also factor into the famed internet attention deficit problem which is where all the numbers showing people hanging around on your page for only a few seconds comes from. I know the "users don't click" concept is a myth, but a lot of people don't, and it may lead to a lot of menus being implemented using hover state because the designers expect users won't click because they think it may lead them to a different page.

Further, I imagine it's a repeating cycle: designers see hover menus and design hover menus, which more designers see and more designers design. Not everyone thinks about each individual UI control they're using in terms of why they need it and what purpose it has; many designers I've worked with choose controls "because that's what you use" (see: incessant overuse of the autocomplete combo box; a rant for another time).

Contrast the above with desktop breed apps where there is (usually) no hover state, certainly not as a UI pattern for menus, and I think we've come full circle.

  • Some great points there. OSes do have many 'single click' actions - like toolbar buttons - although I guess they have a slightly different perceived action to links. Commented Aug 25, 2010 at 9:46
  • 1
    Agreed, I feel a user's expectations on a click is to be taken to a new page. Additionally, the "3 click rule" existed for so long that people wanted reduce the number of clicks required by a user by any means necessary. Finally, add in the browser default behavior for title or alt attributes (hover over elements with them to reveal that hidden information) and people associate a hover with "show me more information". It's just one of those things that was probably randomly decided and the convention just stuck. Commented Aug 26, 2010 at 3:00
  • Spot on. I always expect a click to lead to a new page on the web. Interestingly, this is the case even with the top-level menu normally activated on mouse-over. Sometimes JavaScript doesn't work properly, the screen is too small (e.g. mobile device), page doesn't load quickly enough, etc. Clicking the menu should still lead to a new page.
    – dbkk
    Commented May 22, 2011 at 20:57

Just a guess, but hover is probably used as opposed to onclick because css has a :hover pseudo-class.

Or perhaps dropdown was used because user's did not realize that they had to click to open the menu. Half of the time, a dropdown menu looks just like any other menu until you hover. And the expected action when you click a nav button is for the site to take you to that page. So perhaps users simply were not finding the additional menu options.


Rahul makes an interesting point concerning the lack of a consistent action on a 'click'; however, I think it goes beyond that into a more general sense of discoverability on the page surface.

People may not click due to the desire not to leave a particular page, but many people will 'mouse over' the page looking for active states. Since the menus react to the hover and not the click, the user can more easily discover the structure of the menu system without resorting to clicks.

This, of course, leads to certain accessibility issues. When I click a menu on a desktop application, the default behavior is to leave the menu open until I make a choice, or click off the menu. This helps users who may have difficulty in maneuvering the mouse to the correct command without coming off the menu (which collapses it in the hover paradigm).

  • That's why it's always good practice to have delays on the menu so that (a) the menu doesn't keep appearing if happen to move the mouse past it (aiming for something else like the address bar); and (b) if you overshoot the menu item slightly, you can move back without the menu closing. Commented Aug 25, 2010 at 9:50

Web apps are are wildly inconsistent in terms of UI, but the user must understand them quickly (otherwise his attention span dries up and he'll go elsewhere).

The menu on hover has much better discoverability - when I see a button on a newly visited site, I have no idea whether it will pop a menu with more options (which I want), or it will take me away, destroying the current state of a page (including half-written comment) - which is obviously not what I want. It takes only a few percent of sites with a latter practice to make me fear clicking something I don't know - and intimidated user is not happy user.

By mouse, we explore stuff that's on the screen, hovering means 'I am currently looking at you', so it is pretty natural that the UI element show either what it does (a menu), or a hint (tooltip: this will delete the post you are writing).

On the other side, not reacting on hover is impolite - user asks what the element does, and you don't answer. People love to feel that they have control and know what's happening; every bit of feedback is important, and by not reacting on hover, you are wasting a chance to communicate.

In our recent desktop software (Outlook add-in TaskConnect), we went as far as putting the help tooltip to every active element, and setting the tooltip timeout to zero - therefore making it appear instantly. You can see a short video of how it looks in action. What do you think about that?

PS: In any case, menu should also always pop out on click, otherwise touchscreen users or keyboard people (including disabled users) wouldn't be able to use it.

  • 1
    Re TaskConnect instant hover - I hate it. I would give it a second or two delay (the way most tooltips work). The last thing you want is a hover menu popping over something while you're trying to read/decide what button to click, especially if you're a new user learning the software. Commented Sep 11, 2010 at 3:08

Typically, the top item of a menu will take you to the page with that title. You don't go anywhere when in an application. Hover for menu items was developed as a shortcut to see subsections within a particular section of site rather than needing to go to the page to see the subsections. With an app you don't go to the "file' section for example. Abandoning web conventions for touchscreen is a mistake to me. They're good to keep in mind and watch but often and app specifically designed for the touchscreen is better. Websites aren't meant for fingers.


"Discoverability" is definitely a factor here.

My distinction is the state of mind of the user, especially when comparing an application to a website.

When you click, you mean to do something, perform a certain action - it has to be intentional.
Users are usually operating applications in this state of mind.

However, (some) websites are more about consuming content. You're browsing, reading and perhaps will perform an action. As a matter of fact, one of the biggest challenges it to get the website visitors to actively DO something, not just visit. Hence it makes much sense to try to push you to do something by showing you the options more easily.

There's another difference between the two states of mind:
Usually you'll be using an application several times, hence becoming a bit more familiar and proficient with it. On the web, chances are that a lot of your users are new, hence they might not know where to look for things and might also be "afraid" to do commit to (click) something they don't know.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.