Hmm, this post I'm responding to was automatically moderated some time ago, meaning this is the first that I have seen it. However, I am familiar with this problem. Basically, the test I devised (I did some work on this script, though it's still 90% or more a DD script), to detect a touch device was too aggressive, resulting in some false positives. A touch device cannot do mouseover/out in a logical manner consistent with a desktop or laptop with a mouse or other mouse like device. So it has to operate the menus on click (touch for a touch device). As a result, I recommend that you rethink your menu logic so it will work as an on click menu. I know that removes some flexibility. But it will add cross device accessibility.
If you or others do not want to do that, false positives can be reduced. But I must stress that for touch only devices, click/touch activated menus are the only kind that will be fully functional.
The current test is (in the ddsmoothmenu.js file):
Code:
detecttouch: !!('ontouchstart' in window) || !!('ontouchstart' in document.documentElement) || !!window.ontouchstart || (!!window.Touch && !!window.Touch.length) || !!window.onmsgesturechange || (window.DocumentTouch && window.document instanceof window.DocumentTouch),
In today's environment, that can be fairly safely reduced to:
Code:
detecttouch: !!('ontouchstart' in window),
But as I say, that still means that in those touch only devices, a hover menu will be less than optimally accessible.
Best to plan from the beginning for a click activated menu - that will translate effectively to touch only and to hybrid (devices that are both touch and mouse capable).
Bookmarks