PDA

View Full Version : SmoothMenu With Fixed Divs on Mobile Devices



WycheGnome
09-17-2013, 09:46 AM
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/dynamicindex1/ddsmoothmenu.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/showthread.php?73013-Anylink-CSS-Sub-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/dynamicindex1/ddsmoothmenu.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
09-18-2013, 09:42 AM
.

Your page is in violation of Dynamic Drive's usage terms (http://www.dynamicdrive.com/notice.htm), 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/showthread.php?74719-Smooth-Navigational-Menu-v2-1-Hover-Mouse-Problem&p=299101#post299101

for details.

WycheGnome
09-19-2013, 03:37 PM
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
09-19-2013, 04:28 PM
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
09-20-2013, 10:15 AM
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
09-20-2013, 12:05 PM
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
09-21-2013, 03:56 PM
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
09-21-2013, 05:06 PM
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
09-22-2013, 04:58 PM
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
09-22-2013, 06:02 PM
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.

WycheGnome
09-23-2013, 11:27 AM
Annoying as it is to lose the button effect, removing the button styling does cure it and the menus work on the iPad and phone. iPad just doesn't seem to like the <button> </button> construct.

I have done some tinkering with the css which has mitigated the loss of the buttons a bit.

Thanks again John.

jscheuer1
09-23-2013, 11:47 AM
Though it's always possible that you will get a look that you prefer over what you had with the buttons that way, it should be possible to get goth the look and action that you had with the buttons without them, probably even better. With the buttons, items that had sub menus were wider than ones that didn't. They probably didn't have to be, and probably don't have to be without buttons either. You can get a different look to an a tag when it's depressed, by styling its :active preudo class as I noted before.

When I get some more time I will play around with that for you.

jscheuer1
09-23-2013, 02:50 PM
I got more time sooner than I thought and it was easier than I thought. It might need tweaking but it looks good in most browsers I have.

First backup your current srs.css file, just in case. I only changed the styles for the menu though.

Next, download and use this version (right click and 'Save As'):

5236

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

WycheGnome
09-24-2013, 03:17 PM
Wow !! Brilliant !! All I have adjusted is the widths of the menu entries.

Thank you very much for your time on this, it has solved the problem of keeping the look and feel of anylinkcssmenu without the drawbacks of that system when used for multiple levels.

I am now underway with the overhaul of the site which results in most of the pages going over to .php names so that I can run includes rather than using Dreamweaver's library functions. The only drawback with that is that invoking scripts from Dynamic Drive using a jquery call doesn't make the Dynamic Drive 'legal messages' readily visible in the source code, although they can be seen if the subsidiary file source is viewed. I have got round this by repeating the notices in a separate include file which makes them immediately visible to anyone viewing the source code in either of the .php files. I hope this way of doing it is acceptable. The results, so far, can be seen at:

http://www.s-r-s.org.uk/archivesignals/brersig.php
http://www.s-r-s.org.uk/archivesignals/brarsig.php
http://www.s-r-s.org.uk/webmasternotes.html

Thank you again, John.

jscheuer1
09-24-2013, 04:13 PM
I'm not sure I understand your reasoning there. I don't. I will take your word for it. And what you've done is fine, and is all that's required to satisfy the part of Dynamic Drive's Terms of Service requiring that the script credits be plainly visible in the source code of the page.

One thing you might consider doing with these menus is making your own custom arrows. The white one seems OK, but it could be red, and the blue one might be better if it were yellow or green. Or the white one could be yellow and the blue one green. Whatever looks best to you.

WycheGnome
09-25-2013, 06:30 AM
The reason for including the notices as a separate file is to provide a workable solution to the thread http://www.dynamicdrive.com/forums/showthread.php?75054-Escaping-Dreamweaver-Dynamic-Drive-Legal-Notices

The idea of making the arrows a different colour is one I'll have a look at.

Thank you again for the additional comments.