Bypass nav sub-menus for single-child top-level links on mobile viewports

Use case: we want a “Contact Us” tab/link that displays a simple single-section contact page with no additional nav or toc for all viewports

For viewports above 1220px, this can be achieved by:

theme:
  features:
    - navigation.tabs

nav:
  - Home: index.md
...
  - Contact Us:
    - contact.md

and then including the front matter hide: - navigation - toc in contact.md

(we can not use - Contact Us: contact.md under nav because it will be grouped under Home and not displayed as a tab)

However in smaller viewports, when the top hamburger button is clicked, this will render a top level menu:

Nav Menu | ----------- | | Home | | Contact Us > |

And when Contact Us is clicked, a sub menu is rendered with another Contact Us link to the page:

Contact Us | ----------- | | Contact Us |

Feature request: Clicking twice for a single-child nav is confusing to the user who just wants to see the Contact Us page. Include a flag that allows sub-menus to be bypassed for single child top-level links on mobile viewports, so that the first “Contact Us” link takes the user directly to contact.md. Or alternatively, include a flag that allows top-level direct links ie - Contact Us: contact.md to have their own tab.

[squidfunk]

I refactored navigation tabs to be much more predictable in the latest version of Insiders, which resolves this issue - all first level items are now rendered as-is as part of the tabs, including external links and top-level pages:

When a top-level page is rendered, the navigation is rendered empty and can be hidden (if desired). The tabs navigation now effectively mirrors the first level of mobile navigation. Before, I tried to be too clever by transparently moving all top-level pages into the first tab which received the title of the first page. Over the years, I realized that this leads to confusion among users. I decided to simplify the current implementation. Navigation tabs should now be much simpler to use.

While this is more or less unintended behavior (i.e. a bug), it’s not feasible to fix this as part of the community edition, as backporting it would require significant effort. However, if growth continues at this rate, the next funding goal should be reached at the end of this month and all new navigation options will be generally available as they’re merged back into the community edition 😊

[squidfunk]

I agree that extra options are probably not a good way to go, as we’d break out of the navigation definition and could only add to the front or back, so let’s scrap that.

The grouping behavior does mainly exist for historical/legacy reasons. However, changing that would definitely be a breaking change, at least in behavior. Adding more options would make it more complicated. I think we could tackle this together with #2060 as part of another refactoring of navigation. We can evaluate it when the next funding goal is reached, and all navigation improvements have been merged into master. It would actually make the theme lose some weight, which is a good thing. This would also mean we could remove the extra logic introduced in #1885.