How to make this work with no links at the top level?

[mmcdermott]

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?

[Remirror]

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.

[admin]

Yes, the script requires <a> elements for triggering the sub menus so some modifications would be needed if you would like to use <span>‘s instead.

However, I am not sure there is any serious reason for not using <a>‘s, is there? You could even omit the href attribute 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 href as 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 tabindex attribute to your <span>‘s but that is still not a perfect replacement for a real link).

[Remirror]

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?).

[admin]

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.

[Remirror]

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 docClick function.

[admin]

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):

https://jsfiddle.net/zLnqcb6y/28/

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>

[Remirror]

Thank you! This indeed is pretty. I think this will work for most issues.
Maybe you could include the mega-menu class in your docs, I can’t find anything about it there.

[Remirror]

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.

[admin]

Hi again, you have a good point about stopping the event propagation. Here is a different approach (that shouldn’t have any issues too):

https://jsfiddle.net/vadikom/zLnqcb6y/42/

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.

[Author]

Posts