SmoothMenu With Fixed Divs on Mobile Devices

[WycheGnome]

Script: Smoothmenu v2.1 using the 'v' setting for vertical menus popping out from the left side of the web page.

http://www.dynamicdrive.com/dynamici...smoothmenu.htm with zindexvalue in ddsmoothmenu.js is set to its default value of 1000.

I have managed customise and get this working to my satisfaction on a desktop computer running Windows 7. However, I am having problems with an iPad and on a mobile phone running Android.

The web page is arranged as two panes side by side. Both panes are declared in css as 'fixed' divs, both as to their top position and width. The left hand (menu) pane is just sufficient width to accomodate the list of choices with the result that the sub-menus flying out to the right pop up over the right hand pane. Initially the sub-menus would appear behind the right hand pane content. I have overcome this by setting the z-index of the right hand pane to minus 1 and this renders them above the content of the right pane.

This, however, has not fully cured the problem as the sub-menu selections are not acted on correctly by the iPad or phone.

iPad: sub-menu appears but, on selecting it, the sub-menu disappears as it would if you touched any other part of the right hand pane.

phone: sub-menu appears as on iPad but then the two part company. If the sub menu item is 'stand alone' then the effect is as on the iPad. If, however, the sub-menu has a sub-sub-menu beneath it, selecting the option brings up the sub-sub-menu. Selecting an item from this removes the sub-sub-menu leaving the sub-menu on display but the action for the selection made is not carried out.

There is a temporary test page at http://www.s-r-s.org.uk/WebmasterNotes.html if want to see the effects for yourself.

In http://www.dynamicdrive.com/forums/s...-Menus-on-iPad jscheuer1 suggested using Smoothmenu in place of anylinkcssmenu because the latter was not designed to work with multiple levels. It's ironic that using anylinkcssmenu on the Android allows all the menu levels to appear and selections be acted upon, although the iPad seems to fail after the second level.

The root of the problem is probably the use of fixed panes as putting the Smoothmenu example menus in the right hand pane lets them work exactly as intended and demonstrated on http://www.dynamicdrive.com/dynamici...smoothmenu.htm

I need to keep the left hand pane menu in view at all times, no matter how far the right hand pane is scrolled down, which is why the panes are fixed. Any suggestions on how I can make Smoothmenu sub-menu and sub-sub-menus selections fully selectable in this situation?

[jscheuer1]

.

Your page is in violation of Dynamic Drive's usage terms, which, among other things, state that the script credit must appear in the source code of the page(s) using the script. Please reinstate the notice first.

Once you take care of that, add this to the stylesheet (addition highlighted, around line #263:

.ddcss3support .ddshadow.toplevelshadow {
margin: 0; /* in CSS3 capable browsers overrides offset from NON CSS3 capable browsers, allowing the box-shadow values in the next selector to govern that */
display: none;
/* opacity: 1; */ /* optionally uncomment this to remove partial opacity for browsers supporting a box-shadow property which has its own slight gradient opacity */
}

Add this script as shown in the head of the page (I've also added the credit back in for the main script, both are highlighted):

<script type="text/javascript" src="scripts/jquery-1-9-1.js"></script>

<!-- smoothmenu script file -->
<script type="text/javascript" src="scripts/ddsmoothmenu.js">
//***********************************************
//* Smooth Navigational Menu- (c) Dynamic Drive DHTML code library (www.dynamicdrive.com)
//* This notice MUST stay intact for legal use
//* Visit Dynamic Drive at http://www.dynamicdrive.com/ for full source code
//***********************************************
</script>
<script type="text/javascript">
jQuery(function($){
	$('button').click(function(e){e.stopPropagation(); $(this).parent().trigger('click');});
});
</script>
<script type="text/javascript">
	ddsmoothmenu.init({
		mainmenuid: "smoothmenu1", //menu DIV id
		orientation: 'h', //Horizontal or vertical menu: Set to "h" or "v"
		classname: 'ddsmoothmenu', //class added to menu's outer DIV
		//customtheme: ["#1c5a80", "#18374a"],
		contentsource: "markup" //"markup" or ["container_id", "path_to_menu_file"]
	})
	ddsmoothmenu.init({
		mainmenuid: "smoothmenu2", //Menu DIV id
		orientation: 'v', //Horizontal or vertical menu: Set to "h" or "v"
		classname: 'ddsmoothmenu-v', //class added to menu's outer DIV
		//method: 'toggle', // set to 'hover' (default) or 'toggle'
		arrowswap: true, // enable rollover effect on menu arrow images?
		//customtheme: ["#804000", "#482400"],
		contentsource: "markup" //"markup" or ["container_id", "path_to_menu_file"]
	})
</script>

These changes may or may not cause problems in other browsers/on other devices. If so, let me know

Oh, and you can get rid of the red, the page is not using it.

The browser cache may need to be cleared and/or the page refreshed to see changes.

Notes: I have no mobile to test on, however, due to a what I consider a bug in Chrome, it currently detects itself as touch capable with this script. And it also exhibited the same problems. If this is an accurate indication, the cause isn't the fixed layout, rather the use of buttons, which introduce aother level of clicks to the event hierarchy each time one is activated. In browsers that operate on hover, this is no issue. But, as you know, touch devices require the use of click to activate the menus. I also noticed that the buttons weren't even being visibly depressed when clicked, so something was in the way - Even though they're not really being used, the drop shadows turned out to be the culprits. They were somehow covering the buttons. Now, this should be fine in at least one of your touch devices. We may need to add an on touchstart event for one or more of them as regards the buttons, but probably not. Let me know how this works out.

Once it's working, you should update to the interim fix for Chrome, see:

http://www.dynamicdrive.com/forums/s...101#post299101

for details.

[WycheGnome]

Thank you for the suggestions which I have implemented other than removal of the part you marked in red. That will go when I put these changes live across the web site.

Touch screen behaviour has changed in consequence of the altered code:

iPad: the menus and sub-menus are now usable but the sub-sub-menu still gives problems as the menus disappear instead of being selectable. A further quirk is that once the sub-menu is called it locks out the other sub-menus until the page is refreshed. I also tried increasing the print size using the two finger method Apple recommend and this worsened the ability to use sub-menus.

Android Phone: works better than iPad but left hand fixed pane is no longer fixed. Scrolling back up reveals the sub-menu is there and can be used. Sub-sub-menus can also be used similarly.

Neither situation is particularly user friendly.

I also implemented the Chrome interim fix you mentioned but this made no difference to these behaviours, as one would expect given that the change is for Google Chrome (only?).

I am beginning to think that the only solution for touch screen systems is to turn off the sub-menu and sub-sub menu code by not calling it on a touch screen device - is that possible? For anylinkcssmenu I found some code that did this by not calling the init routine if a touch screen was detected and this just left the top level menu choices working.

I could then add a 'site map' page for touch screen users' benefit which would be a useful facility anyway for desktop users in addition to the mouse events.

[jscheuer1]

I have some further ideas.

1.) Where we added:

<script type="text/javascript">
jQuery(function($){
	$('button').click(function(e){e.stopPropagation(); $(this).parent().trigger('click');});
});
</script>

Make that:

<script type="text/javascript">
if(ddsmoothmenu.detecttouch){
	jQuery(function($){
		$('button').click(function(e){e.stopPropagation(); $(this).parent().trigger('click');})
		.each(function(i, but){
			but.addEventListener('touchstart', function(e){e.stopPropagation();}, false);
		});
	});
}
</script>

And get rid of:

	ddsmoothmenu.init({
		mainmenuid: "smoothmenu1", //menu DIV id
		orientation: 'h', //Horizontal or vertical menu: Set to "h" or "v"
		classname: 'ddsmoothmenu', //class added to menu's outer DIV
		//customtheme: ["#1c5a80", "#18374a"],
		contentsource: "markup" //"markup" or ["container_id", "path_to_menu_file"]
	})

It's not being used, and might be causing problems with the mobiles.


2.) Instead of using a script there at all, you could just get rid of the buttons entirely, the menu should then act properly. If you want them to still look like buttons, you could style the links using css to have an :active pseudo class that makes them look depressed when clicked. The :active pseudo class properties are in effect when a link is clicked and the mouse is in the down position. Something like:

.ddsmoothmenu-v#smoothmenu2 a:link {
	background: url(regularbut.gif), center no-repeat;
}
.ddsmoothmenu-v#smoothmenu2 a:active {
	background-image: url(depressedbut.gif);
}

A sprite would be better, if you know how to do that or want to learn, or the depressedbut.gif image could be preloaded.


3.) If all else fails we can do what you suggest, not use the menu script for mobiles. Again, skip that added script and just add the highlighted as shown (the red part should be removed, you're not using it):

<script type="text/javascript">
	ddsmoothmenu.init({
		mainmenuid: "smoothmenu1", //menu DIV id
		orientation: 'h', //Horizontal or vertical menu: Set to "h" or "v"
		classname: 'ddsmoothmenu', //class added to menu's outer DIV
		//customtheme: ["#1c5a80", "#18374a"],
		contentsource: "markup" //"markup" or ["container_id", "path_to_menu_file"]
	})
	if(!ddsmoothmenu.detecttouch)
	ddsmoothmenu.init({
		mainmenuid: "smoothmenu2", //Menu DIV id
		orientation: 'v', //Horizontal or vertical menu: Set to "h" or "v"
		classname: 'ddsmoothmenu-v', //class added to menu's outer DIV
		//method: 'toggle', // set to 'hover' (default) or 'toggle'
		arrowswap: true, // enable rollover effect on menu arrow images?
		//customtheme: ["#804000", "#482400"],
		contentsource: "markup" //"markup" or ["container_id", "path_to_menu_file"]
	})
</script>

[WycheGnome]

Thank you for the further thoughts.

I changed the stop propagation code as suggested and this seemed to make no difference on either iPad or phone.

I also removed the first 'init' routine and, again, this made no difference. This proves it wasn't needed, and that it wasn't the cause of the problem.

Next I tried removing the buttons and their styling and this looked horrible on the desktop as the menu appeared as a standard list (site map style) spreading out of the left pane boundary. On iPad and phone the menus disappeared entirely! It may be possible, however, for me to resolve that by editing the css as the button styles were overriding the standard smoothmenu ones.

Turning off the sub-menu system by not running the init routine on touch screen devices seems to produce the best result so far and, coupled with a site map page which I've duly added for the tests, seems to provide a workable solution. The iPad's failure to recognise a second menu choice request will not be a problem if all the buttons load a fresh page as this resets the choice selection mechanisms.

[jscheuer1]

Well, yes if you were going to get rid of the buttons, you would have to use the standard css for the menu and work from there, otherwise it probably would look like what it is, a list.

Too bad none of that other code helped.

[WycheGnome]

Thank you for your efforts on this - the investigation has been well worthwhile as others will now be aware of the issue.

Unless someone, somewhere, knows otherwise, we seem to be thwarted by the version of Safari that runs on iPads. It is clearly confused when running menu structures inside divs that are fixed.

Thank you again.

[jscheuer1]

You're welcome. But I'm still not convinced it's not because of the buttons.

On the other hand, if it's only Safari iPad (perhaps Safari iPhone too), we could test for just that and let other mobiles and other browsers on those devices use the full menu.

[WycheGnome]

I'll give that some thought, but I am reluctant to go down the route of being touch screen device specific as I can foresee the web site code becoming a nightmare to maintain.

For now, I have embarked on an overhaul of the site with the sub-menus switched off on touch screen devices but with the addition of a site map page in compensation.

[jscheuer1]

I'd be more inclined to do it without the buttons. Then it should be fine for all devices/browsers.

As it is now, you are disabling it for all mobile/touch devices. If it's only a problem in Safari on Mac mobile/touch products, that's a bit like throwing the baby out with the bath water. So, if you want to keep the buttons, and go the disabling route, you can afford to be more specific.

But as I've been saying, it's probably those nested buttons, not the fixed layout that's the problem. You could get rid of them, and, if you still want the same or similar look, style the links to look and act like buttons. Once that's done, all devices/browsers should work fine with it.