-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(react): uishell sidenavmenu active descendants #15027
fix(react): uishell sidenavmenu active descendants #15027
Conversation
✅ Deploy Preview for v11-carbon-react ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for carbon-elements ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for v11-carbon-react ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for carbon-elements ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
when more than two levels of navigation are in the page heirarchy
Unfortunately this is out of spec for this component.
The left panel does not support three tiers of navigation. If you have additional content to display beneath a sub-menu, use tabs within the page.
@laurenmrice could you confirm this is still an intentional limitation of the UI Shell left side nav? I know we've had some variations of this for the platform work, etc. but I think in those instances we used TreeView? I recall @alisonjoseph mentioning this at one point.
@cordesmj similar to my comment on the other PR, can we learn a little more about your need for the 3rd level? we have had some teams ask for this and i think it's a more common pattern to have a 3rd level on the side navigation than the header nav. the only thing is that we've seen it implemented as a tree view rather than a navigational component. this is done so users are able to navigate with the keyboard easier. i'm wondering if something like that would be a good fit? |
Thanks for you response @kingtraceyj. So I'm not sure how familiar you may be with w3 publisher. It is basically a webapp that allows people within IBM to create their own internal websites. We are currently in the process of converting it to carbon. w3 Publisher has historically permitted users to create sites with up to three levels in the page hierarchy, and also, we allow users to choose between top-nav (header nav) or side nav, depending on their preferences or needs. We currently have tens of thousands of live sites, many of which use 3 levels. In support of the transition to carbon, our design team has designed extensions to carbons navigation elements to accomodate 3 levels in header nav, similar to: and side nav, similar to: These components have already undergone development, and have taken into account keyboard accessibility. The one hole that remains is when there is an active page highlighted. Similar to the implementation in carbon, when a parent has an active child, the parent is marked when the dropdown is not open. Unfortunately, marking the top level link when a third level nav element is active is not supported by carbon, which is what caused me to create these PR's, to add such support. I am not sure if I am getting to the heart of your question, and being a developer and not a designer, I can't really speak to the design choice of tree view vs navigational component... I am not sure I even understand the implications of the distinction, beyond the fact that the TreeView component already exists. If there is anything I could elaborate on to clarify things, or if it would help to tie in one of our design team, let me know. |
@cordesmj @tay1orjones after further discussion with the team, we don't want to be a blocker for your team to implement your requirements. for side navigation, teams have asked for the third level for sometime and we ourselves have done design explorations around this. our specs can be found in figma. we are a bit more cautious about opening up a third level for header navigation—it can begin to complicate the information architecture structure pretty quickly and hide information. but, again, we don't want to block you from delivering your specific requirements so we can push this through as well. thanks for contributing! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @kingtraceyj!
Thanks for approving, @tay1orjones - can you also review #14942 please? |
72c2a05
Changelog
Changed
Testing / Reviewing
Related to #14942