Opened 15 years ago
Last modified 13 months ago
#13273 new enhancement
Allow "'non-clickable" menu items
Reported by: | stgoos | Owned by: | |
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | normal | Version: | 3.0 |
Component: | Menus | Keywords: | needs-design |
Focuses: | ui, accessibility | Cc: |
Description
In the new menu generator I'm missing the option to create "non-clickable" menu items.
What I'm after is that I want to create for example a main menu item with the title "Links" which is non-clickable (no url attached to it) and basically only acts as an umbrella item for the actual links I want to locate as subitems of the item "Links".
- Home
- Something else
- Links (this one should be non-clickable)
- external link 1
- external link 2
- etc
I think that an optional tickbox in the add link section will do the trick. Basically, all it has to do is to "disable" the check whether or not a valid URL format has been submitted and, of course, it has to trigger some modified html output.
Hope you guys can add this in the 3.0 release because this would basically complete the menu generator :)
Keep up the good work and I'm really looking forward to the 3.0 release!
Attachments (2)
Change History (23)
#4
@
15 years ago
Another workaround in 3.0 is to add a custom menu item with a bogus url, and then remove the url, keeping the label, once it's added to the menu structure.
Would be good to have it fixed in the next release, as having a top menu item (with subitems) as links is bad UI design, even for a webpage. I think users do not expext menus to behave like that.
I also really appreciate the new menu builder, it takes a lot of work out of making the site navigation. Thanks for the good work!
#6
follow-up:
↓ 8
@
11 years ago
- Keywords changed from menu, non-clickable item to menu non-clickable item
There are basically two approaches to this as far as the outputted HTML is concerned.
The first option is to output an anchor tag without the href-attribute. This is what already happens when you add a custom link and remove the URL, as oellefsen suggested. The second option is to remove/replace the anchor tag.
The second option will probably cause a lot of problems styling-wise, as a lot of styling is applied on the anchor tags in menus. The first one is the way to go, in my opinion, as it won't cause any of the problems and still have the desired effect.
#8
in reply to:
↑ 6
@
10 years ago
- Keywords needs-patch added; menu non-clickable item removed
Replying to Jesper800:
The first option is to output an anchor tag without the href-attribute. This is what already happens when you add a custom link and remove the URL, as oellefsen suggested.
I'd be interested in seeing this approach. For the UI side, it would probably work well as a toggle in the add-custom-link area that hid the url field. It could potentially just create a custom menu item without a URL, utilizing the underlying functionality of the workaround.
Alternately, there could be an additional "placeholder" menu item type that exhibited this behavior.
@
10 years ago
Introduce support for placeholder menu items, which function as custom items without urls.
#9
@
10 years ago
- Focuses ui added
- Keywords has-patch needs-testing added; needs-patch removed
- Severity changed from minor to normal
- Version set to 3.0
13273.diff implements core support and UI for "placeholder" nav menu items. Placeholders are similar to custom links, but without URLs. Accordingly, the UI is built-in to the existing "Links" section, as a checkbox that toggles the visibility of the URL field. The patch includes no-js support. Alternatively, a "Placeholders" section could be created, although that would be less elegant.
On the front-end, placeholders would primarily be used as parent menu items, as placeholders for sub-menus in top-level menus. Generally, the only enhancement that themes could (or would need to) make to support this feature would be to apply cursor: default
to these menu items, in place of the default cursor: text
for unlinked links. This enhancement certainly isn't required and some themes may take advantage of this feature further than just tweaking the cursor. 13273.diff implements the small CSS fix in all of the bundled themes, as the fix improves the UX somewhat for each of those themes.
#10
follow-ups:
↓ 11
↓ 12
@
10 years ago
- Keywords 2nd-opinion added
I think we've all probably seen a use-case for this at one time or another so it's not without merit.
However, I have some concerns, primarily with introducing a core feature that requires theme styling changes to work as expected.
Additionally, I think if we move forward with this, we're going to need to take some time to consider the best workflow for creating and editing placeholder links. Should there be a checkbox only in the add pane? Or should we just allow adding custom links with no URL? Or what using about special URL placeholder (heh) like #
. Or what about a menu item setting?
#11
in reply to:
↑ 10
@
10 years ago
Replying to DrewAPicture:
However, I have some concerns, primarily with introducing a core feature that requires theme styling changes to work as expected.
More like "requires theme styling changes to make non-links appear as such". The non-links will "work", but the cursors will likely confuse people without the change.
#12
in reply to:
↑ 10
@
10 years ago
Replying to DrewAPicture:
Additionally, I think if we move forward with this, we're going to need to take some time to consider the best workflow for creating and editing placeholder links. Should there be a checkbox only in the add pane? Or should we just allow adding custom links with no URL? Or what using about special URL placeholder (heh) like
#
. Or what about a menu item setting?
The problem with #
is that it implies click-ability like any other link (which may be desirable for some themes), as opposed to being merely an placeholder. #
will also cause issues in themes where menus aren't at the top of the page (including fixed navbars like Twenty Fourteen has), because of the scroll-to-top functionality.
I'm definitely interested in more opinions on the best workflow for adding and managing placeholders. I like treating it as its own type once added, like the patch does, but there're certainly other options.
#16
@
6 years ago
- Focuses accessibility added
- Keywords needs-design added; has-patch needs-testing 2nd-opinion needs-refresh removed
- Milestone set to Future Release
This ticket remains a fairly-common need for users. Core (and the web) would benefit from a consistent and accessible mechanism to "headings" in menus, that break out of link elements entirely and allow users to semantically create submenus without top-level links.
Let's step back and approach this as a broader need for an accessible, core mechanism for this common use case in building menus. The associated markup changes (along with any other changes to menu markup that could improve semantics and accessibility) can be coordinated with theme back-compat via the use of a theme-supports flag (potentially under the existing html5
array of updated-markup features).
13273.diff may have reusable elements for the admin UI changes. These would also need to be implemented in the customizer menus panel.
This ticket was mentioned in Slack in #accessibility by robert.vidrine. View the logs.
5 years ago
This ticket was mentioned in Slack in #accessibility by robert.vidrine. View the logs.
5 years ago
This ticket was mentioned in Slack in #core by noisysocks. View the logs.
4 years ago
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
13 months ago
#23
@
13 months ago
This behavior is now available in the navigation block, but that doesn't solve the problem for a lot of sites using classic themes. There are a few issues to solve here:
1) Core could add a setting for the menu to make top level items into buttons. Option text might need some careful thought.
2) In keeping with the historic practice of the navigation menu builder, core should not enqueue any scripts or CSS to handle this.
3) Therefore, this should be behind a theme support flag, so that a supporting theme can provide appropriate CSS and scripting to support the option.
I think this is doable, and would be of benefit to users. It offers an option where you can get the output like a block theme - with top level buttons - but get more control over the scripting that handles it.
A workaround for now is to use "#" as the url.