Anylink CSS Sub-Menus on iPad

**WycheGnome** · 02-22-2013, 03:22 PM

1) Script Title: AnyLink CSS Menu v2.3

2) Script URL (on DD): http://www.dynamicdrive.com/dynamici...anylinkcss.htm

3) Describe problem: See below.

I have a problem with Anylink css menu when the web page is viewed on an iPad.

Web site is www.s-r-s.org.uk with a navigation panel (div) on the left side of the page that is 'fixed' in position so it doesn't scroll. Within this is a navigation menu structure that uses sub-menus. The anylinkcssmenu.js code is at version 2.3 and the anylink css directives are included within the file srs.css.

On a normal desktop or portable PC the menus work fine but on the iPad trying to select one of the links produces a 'grey' area and the link does not work. The 'grey' area may well be one of the sub-menus not forming properly but the 'grey' area appears regardless of whether the button I select actually has a sub-menu associated with it or not.

On another of my web sites www.wycherail.co.uk I have a similar navigation panel which does work on the iPad without any problem. The anylinkcssmenu.js on this stite is still at version 2.0 but there are no sub-menus.

The problem with the SRS site when viewed on the iPad seems, therefore, to relate to the use of the sub-menus.

Any thoughts on how I can cure the problem please.

**WycheGnome** · 08-31-2013, 10:10 AM

It is now 6 months - yes 6 months - since I posted this request for help or advice. All I have had in that time is one comment about format - but no help !!

I have had to run my web site without this menu system working properly on touch screen devices.

The web site is www.s-r-s.org.uk but the use of sub-menus is disabled generally on the site.

www.s-r-s.org.uk/index2.html has had the sub-menus re-enabled so that anyone offering help can see what the originally described problem is.

Can I have some assistance now please.

**jscheuer1** · 09-01-2013, 04:10 AM

This is a free all volunteer forum. There is no requirement for anyone to help anyone. And the scripts provided by Dynamic Drive are free for all to use, but do not come with any warranty or guarantee of fitness for any particular use. This script is not rated for iPad, and even if it were, if there was a problem with that, it would not be Dynamic Drive's or this forum's responsibility to fix it or to help you with it.

That said, I see you've made some customization and/or done something to use this menu for more than one level (something it's not intended to do) and to use it with buttons instead of links (also not intended).

I would recommend against using buttons in the way that you have because it relies upon javascript to function at all. A browser without javascript or with it disabled would have no way to navigate the site.

You could make links that look and act visually like buttons via css and/or javascript, but that do not require javascript to change the page, rather using the usual a tag href attribute to supply the URL. Or you could replace each button with a form having a single button that submits it and have that form's action attribute be the URL.

That's one issue. The other major one I see is making the site accessible to touch devices. For that you could use a menu designed for that, like:

http://www.dynamicdrive.com/dynamici...smoothmenu.htm

The way that menu works is, on touch devices it use click (tap) to activate the drop downs. You can choose to have all devices operate that way (click/tap) with the menu, or to have devices that register javascript mouseover/out use that method. In the latter case the menu will detect touch devices and convert itself to a click (tap) activated menu.

It also has the advantage of already being set up to have multiple levels to the menu.

However, when using it as a click (tap) activated menu you cannot have a menu item that both opens a submenu and links to a page. Because the click on any particular item has to be reserved for either navigation or the opening of a submenu, it obviously cannot do both. Using buttons with it, even as forms as I mentioned above would probably require modifications. But you could use it with links that look and act visually like buttons via css and/or javascript.

To bring all of that together for you is a little bit beyond what is usually offered in a free forum such as this.

What I would advise is setting up the menu I suggested with normal links, bearing in mind what I said about click activation. That will require a rethinking about what many of the menu items are and do, and of what exactly should go in the drop downs.

For example with Home, which currently has two options (Cookie Information and Page Handling) in its drop down and if you click on Home, takes you to the home page. After rethinking its drop down could have three options (Got to Home, Cookie Information and Page Handling), and clicking on it would only open or close the submenu. Clicking on any of the items in the submenu would take you to that respective location.

If you have problems setting up the menu with normal links, open a separate thread about it.

Once that's working, if you still want the button look, you can try designing the links to look and act visually like buttons. If you need help with that, you could open a separate thread on that.

Of course this is just one of virtually infinite ways to proceed, but if you do proceed like I advise, chances are things will work out well for you.

**WycheGnome** · 09-01-2013, 05:34 PM

John

Let me start by thanking you for the response you gave. It eventually kicked me into a different direction from the circles I was stuck in and to finding the cause of the problem - and curing it. However, the solution wasn't where either of us initially thought.

I full appreciate your comments that the Anylink menu system wasn't designed for multi-level menus or for the iPad but, nevertheless it does cope with them effectively and elegantly. A good system. Something you might like to consider mentioning in the instructions and notes for the scripts. I had already looked at the Smoothmenu you mentioned and the All Levels one as well and both exhibited exactly the same problem on the iPad.

I have taken on board your comments about using straight anchor links instead of inputs (why I used inputs I can't now remember - I'm getting a bit old) and restructured the menus to suit. The change is invisible to users as I have styled the anchor link buttons exactly as before; except that is, for one thing, I added the additional item to each sub-menu in order to allow iPad users to access the principle pages. Making the change to straight anchor links did not, however, cure the problem.

However, I must challenge your comment about javascript and the potential issues if a user of the site has javascript disabled. All three of the menu systems mentioned above use javascript so anyone with javascript disabled will be unable to use the lower levels of the menus regardless of which one of the three is used.

If you go back to my original posting of last February you will see I drew attention to grey areas and suggested they might be linked to the sub-menus. Mention of the javascript got me looking through the supplied anylinkcssmenu.js (version 2.3) file to see if I could see something of how it works; and how it used the shadow function. And the shadows are indeed linked to the sub-menus!

The initialise function within the js file includes this line: "document.body.appendChild(menu.shadow)" (line 229 according to Dreamweaver). I'm certainly no expert in javascript but this seems to facilitate the script creating shadow boxes that can appear under the sub-menus. Commenting out this line removed the problem grey areas immediately! It would seem that the version of Safari in the iPad fails to move these shadows to the bottom of the page, well out of harms way, as implied by "appendChild" and instead places them top left of the screen. Safari then compounds the problem by placing the shadow boxes as a layer above all other layers equivalent to giving it a z-index value higher than anything else. Thus the menu buttons could not be accessed easily, and often not at all, unless the user got lucky and found the minute gaps between the shadows. Of course, on a desktop computer the mouseover works and the problem is never encountered.

You might like to suggest to the author of the script that a modification to the script to automatically disable the call to append the shadows (or otherwise create them) could be beneficial on touch screen systems - there is already a routine included to detect if the script is running on a touch screen. It would certainly avoid the need to users to make changes themselves with all the attendant risk of version control that doing so can bring.

So, thank you again John. I've left the altered www.s-r-s.org.uk/index2.html page in place for now in case you or anyone else wishes to look at it. I've got some other changes to make to the web site that this problem hss shown to be desirable, so it will be a few days before the rest of the web site is altered to embody and activate the full solution. Once that process is finished the index2 test page will disappear but future readers will then be able to view the solution by just looking at www.s-r-s.org.uk as that will outlive me.

Oh, one final point. I was aware that most (or all) of the support comes from unpaid volunteers. It's something we have in common - I don't get paid for creating and running the web site!

John

**jscheuer1** · 09-02-2013, 04:04 AM

The current version of Smooth Menu works fine on touch devices. Perhaps you tested an earlier version, and/or didn't fully understand the explanation in my previous post about click/tap activation. There have been no reports of problems with its shadows. There is a current issue with it though, falsr positives from Chrome on its being a touch device when it is not. There's an easy fix for that:

http://www.dynamicdrive.com/forums/s...941#post298941

But it looks like a problem in Chrome to me. Hopefully they will fix it. I have (as noted in the above link) reported it to them.

With javascript unavailable or disabled, at least the top level links (which will I believe be disabled when javascript is active, and if not could easily be for those devices that require it) will work in Smooth Menu. If you take the added step of only installing the menu styles on browsers with javascript enabled, then the entire menu tree will be available to non-javascript users.

However, as I stated before, with those buttons you had there, no navigation was possible without javascript, not even top level. They are now with the changes you've made at least working for top level navigation.

There are some other issues here. The menu items have a Venetian blind look in Chrome (extra space between them). And in most if not all browsers, when you go over - say, Archives > Appendices > Companies, the middle level disappears. In other words those menus with more than one level lose their tie back to the main menu once you hover over to the second drop down. Neither of these two things will happen with Smooth Menu. Both good reasons to use a menu designed for multilevel use rather than trying to shoehorn one that's not designed for it into acting like it is.

But, if as you say you are happy with what you have now, that's good enough for me. I just thought you and/or others might want to be aware of some or all of the above.

**WycheGnome** · 09-02-2013, 06:46 AM

Thank you for the additional comments and remarks. I'll give Smoothmenu another try before propagating the changes across the web site.

I will be taking the opportunity to make some other changes linked to making editing of the site independent of Dreamweaver's library function and easy to edit in other editors it will be a few days before anything is implemented. I'll probably make one more posting here just to let you know when the changes have actually been implemented.

Thank you again, John