Menu for Enabled vs Disabled Pages with Submenus

[jncraig]

Describe the bug

If a page is enabled for navigation and has subpages, there is a separation between the page name and the down arrow.

if a page is disabled for navigation and has subpages, there is no separation.

To Reproduce

Go to a page with children, and disable the page for navigation. The separator disappears when the page is reloaded.

Expected behavior

The menu entries should look the same. There should not be a hand pointer for disabled pages.

(Note that when the separator appears, the page name and the down arrow have different mouseover characteristics, too.)

Screenshots

If applicable, add screenshots to help explain your problem.

Errors

Paste the error(s) related to this issue.

Additional context

[Tychodewaard]

This is as intended, AFAIK.
If the top level (or any other) is active, you should be able to get to that page by clicking or tapping. But you should also be able to get to pages on sub level by hovering or tapping. That's why there are 2 parts in the button.

If the toplevel is disabled, this is done because it is just a gateway to sublevel and the toplevel has no actual content. So, the ux does not require 2 functions but just one: show me the sub level.

[jncraig]

I understand that, but ... if the top level is disabled, can't hovering over the button show the dropdowns? If the top is enabled, hovering over the button part can also show the dropdowns. I suppose I can always modify the menu to do that. I have that kind of behavior on another site, and change the hand to a pointer and vice versa depending on enebled/disabled. That makes more sense to me. So, maybe modifying the menu is the way to go. I could even post it back as an alternative.

…

On Wed, Apr 24, 2019 at 3:18 PM Tycho de Waard ***@***.***> wrote: This is as intended, AFAIK. If the top level (or any other) is active, you should be able to get to that page by clicking or tapping. But you should also be able to get to pages on sub level by hovering or tapping. That's why there are 2 parts in the button. If the toplevel is disabled, this is done because it is just a gateway to sublevel and the toplevel has no actual content. So, the ux does not require 2 functions but just one: show me the sub level. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#148 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABEDMRPF6D2BE45GZ3R4SYLPSCW7DANCNFSM4HCGIY2Q> .

[david-poindexter]

@jncraig the way it is implemented by default is the intended implementation and is the "standard" (common) UX for this type of split menu. This is mainly for mobile (touch) devices so that there is a clear distinction between actions to "expanding the menu" versus "visiting a page". When a page is disabled and has subs, there is only one action for the disabled page (expand the menu) versus two, so there is no need for a split button.

That said, there is no problem in replacing this with an experience you believe better suits your client's or your needs. We do that all the time for our client sites. 😉

We'll go ahead and close this issue out since there are no specific changes to be made to the base starting point. Thanks for the dialog!

[jncraig]

👆

…

On Thu, Apr 25, 2019 at 2:25 PM nvisionative ***@***.***> wrote: @jncraig <https://github.com/jncraig> the way it is implemented by default is the intended implementation and is the "standard" (common) UX for this type of split menu. This is mainly for mobile (touch) devices so that there is a clear distinction between actions to "expanding the menu" versus "visiting a page". When a page is disabled and has subs, there is only one action for the disabled page (expand the menu) versus two, so there is no need for a split button. That said, there is no problem in replacing this with an experience you believe better suits your client's or your needs. We do that all the time for our client sites. 😉 We'll go ahead and close this issue out since there are no specific changes to be made to the base starting point. Thanks for the dialog! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#148 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABEDMRIZPDXFLVOZB6QH7PDPSHZQ3ANCNFSM4HCGIY2Q> .