Start a new discussion
To start a new discussion please visit the discussions section of the GitHub home page of the project.
You can also search our old self-hosted forums for any useful information below but please note that posting new content here is not possible any more.
How to make this work with no links at the top level?
Home › Forums › Latest release › 1.1.x › How to make this work with no links at the top level?
- This topic has 9 replies, 3 voices, and was last updated 4 years, 11 months ago by admin.
February 22, 2018 at 17:05 #3868mmcdermottParticipant
I have a menu structured like this:
<ul class="menu"> <li><span class="nolink">Header here</span> <ul class="dropdown"> <li><a href="/whatever">Menu link</a></li> <li><a href="/whatever">Menu link</a></li> <li><a href="/whatever">Menu link</a></li> </ul> </li> <li><span class="nolink">Header here</span> <ul class="dropdown"> .... etc. </ul>
How can I get SmartMenus to work with the spans instead of links at the top level?June 5, 2018 at 23:23 #8270
I have the same issue, but I even want to use no-link items at arbitrary levels of the menu. Additionally, I want to be able to use block elements.
The solution is actually very easy; just replace all “a”s in the SmartMenus code by, e.g., “.a” (i.e., use class names instead of tag names).
However, this requires changes in the SmartMenus code. Instead of forking it and including your fork, you perhaps can use PHP to retrieve and preprocess the script accordingly.June 6, 2018 at 13:19 #8271
Yes, the script requires
<a>elements for triggering the sub menus so some modifications would be needed if you would like to use
However, I am not sure there is any serious reason for not using
<a>‘s, is there? You could even omit the
hrefattribute if you like (not advisable) and it would still work properly with mouse/touch:
... <li><a>About</a> <ul> ...
On the other hand, there is a serious reason for using
<a>s inside parent menu items (and not omitting the
hrefas in the above example) – without a link element your parent menu item loses its ability to gain focus and thus the sub menu becomes completely inaccessible via the keyboard (unless you specifically add a
tabindexattribute to your
<span>‘s but that is still not a perfect replacement for a real link).June 6, 2018 at 13:42 #8272
True, it does work this way, but it also has some drawbacks:
- “a” is semantically wrong for non-link elements (e.g., separators or static textual Information)
- “a” is not valid if it contains interactive content (e.g., buttons)
- Even if I ignore the latter points, I cannot really use a (real, i.e. link) “a” within a dummy “a”
For now, I will go with the (dynamic) code change solution, but it would be really nice to have this improved in the next release. It should only require small changes. And I’m convinced there will be a simple solution for the focus issue you describe (perhaps auto-adding “tabindex” to each element?).June 12, 2018 at 18:05 #8285
Sorry for getting back late! Could you please post the HTML content of one of your main menu
<li>‘s? I am not sure why you would need to wrap all those kinds of elements inside the link (if you use a link instead of a
<span>that is). You could put those elements as siblings of the link instead.June 13, 2018 at 00:17 #8287
Well, this is not so simple because I use SmartMenus in combination with a lot of other stuff such as custom tags. However, here is a toy example which demonstrates three problems: https://jsfiddle.net/zLnqcb6y/.
I managed to solve all of these problems, but I need to do a lot of hacking (including code changes) for this purpose.
I think what would really be needed here were hooks in the code. For instance, problem 3 could be solved easily if you would provide a hook for the
docClickfunction.June 13, 2018 at 11:54 #8288
Here are the recommended solutions to the issues you are having. You won’t need to customize anything in the script core – you just need a bit additional CSS and JS. And the result is a fully accessible sub menu (screen readers/keyboard):
But again, in order the sub menu to be fully accessible to screen readers and keyboard users I strongly recommend using the following HTML for your parent “Search” menu item:
<a href="#">Search</a>June 13, 2018 at 14:21 #8289
Thank you! This indeed is pretty. I think this will work for most issues.
Maybe you could include the
mega-menuclass in your docs, I can’t find anything about it there.June 21, 2018 at 23:06 #8294
Upon closer look, I experience some trouble with your solution regarding problem 3 (as exemplified by the ui-autocomplete element):
- After having selected a city, try selecting another city. This does not work for me because the ui-autocomplete does not close the second time.
- More generally, stopping event propagation may not be the best idea. What if other plugins define event handlers for the stopped events?
- Your solution works for ui-autocomplete, and it is easy to extend to other elements/widgets if they are known in advance. But what if I want to create a SM-based component that can be used with <i>any</i> widget in it?
Thank you for your help.June 27, 2018 at 14:19 #8298
Hi again, you have a good point about stopping the event propagation. Here is a different approach (that shouldn’t have any issues too):
Your solution works for ui-autocomplete, and it is easy to extend to other elements/widgets if they are known in advance. But what if I want to create a SM-based component that can be used with any widget in it?
The SmartMenus code that hides the menus on click is generic enough and should work with all types of elements/widgets that are rendered inside the mega menu. The problem with the autocomplete is caused by the fact that the autocomplete element is actually not appended inside the menu where the input is by the jQuery UI code but is a child of the BODY element.
But also in general no matter how well you try to design your “widgets” to avoid any possible conflicts with other scripts/CSS, it’s simply impossible to be sure this would never happen in certain scenarios. One could always write a JS/CSS snippet that could accidentally break/conflict with your widget.
- The forum ‘1.1.x’ is closed to new topics and replies.