iPad and onMouseOver

I’ve been putting the iPad simulator through its paces and I’ve run across one interesting feature in the new MobileSafari: onmouseover!

Many people, myself included1, assumed that onmouseover was dead2 with the arrival of touch based web browsers, and up until iPhone OS 3.2 that seemed to be the case. However, in my testing, I’ve found that the first tap on an element with an onmouseover “attribute” will trigger the onmouseover event, stop the click event from propagating to any children until a second tap after the onmouseover has fired.

Setting focus elsewhere (via tapping other onmouseover watching elements or form fields) will trigger the onmouseout event and, again, tapping on the element a second time while the onmouseover is active sends the click down to its child elements. You can see this in action with Twitter’s “hovercards”.

Sadly, adding those behaviors using jQuery doesn’t seem to give it the same magic. Perhaps we’ll see it in the next version of MobileSafari, and hopefully on iPhone as well. These are preliminary findings, of course, and in order to do more testing I’ll require an iPad (with 3G, please).


  1. I even went so far as to start replacing my onmouseovers with click events on lib.rario.us but I couldn’t go through with it. 

  2. By “dead”, I mean “functionally useless.” 

  • Jason

    The iPhone has been firing mouseover/out events when the focus changes for awhile now (if not always). It may be inappropriately named, but I don't see the difference between firing these events regardless of the input device (mouse, wacom tablet, finger, etc.) The bigger problem is still that IE is the only browser that uses mouseenter/leave which respond much more appropriately. Mouse events and the box model. Possibly the only two things IE ever had right.

  • http://octidextro.us/ M. Dave Auayan

    You're correct, and I should clarify: it fires those events and stops the click propagation from hitting a link inside the element with the onmouseover event, as is commonly seen on drop down menus.

    This behavior is new, not so much the onmouseover events.

  • Jason

    That's awfully nice of them to stop the propagation. Browsers have been letting events breed like rabbits for far too long.

  • tr888

    “Sadly, adding those behaviors using jQuery doesn't seem to give it the same magic.”.

    Are you saying that the onMouseOver eventhandler must be declared in the markup of the served page and cannot be dynamically added to the DOM?

  • http://octidextro.us/ M. Dave Auayan

    Indeed, that's exactly what I'm saying, though I haven't run it through any proper tests.

  • http://www.aimsdata.com/tim Timo

    What happens if
    (a) you put a dummy click-handler in the markup and add the onMouseOver behavior dynamically in jQuery?
    (b) you add a dummy click handler and onMouseOver behavior both with jQuery?

  • trung

    Hi Dave A question about mouseover / mouseout on ipad , Follow this document http://www.quirksmode.org/blog/archives/2008/08/iphone_events.html . When user focus a element A, mouseover will be fired. mouseout event will be fired when user focus another element B. And in this above link, links and form fields are clickable. Yeahhh. But i visit this page http://www.steadfastcreative.com/ . See the slideshow, when click on slide , NAV will be showed. and when click another element not links ,form fields ,it’s fired mouseout ? why ? trick ?

  • http://octidextro.us/ M. Dave Auayan

    It took me a couple readings to figure out what you were asking (and for anyone else reading, he’s saying the first link says that the Mobile Safari mouseout event doesn’t fire unless you click on a link or form element), however, the second link has a nav element that is hidden on mouseout, which is seems to be triggered by clicking on any element, not just links or form fields).

    To possibly answer your question, trung, the first link you posted may have your answer: if you attach an onclick event handler to any element, that element remains focusable even after you remove that handler. I didn’t see anything to that effect when trying to view their source, however, so more testing is needed.