feat(navigation-primary): add navigation primary #2171
Conversation
|
❌ Deploy Preview for red-hat-design-system failed. Why did it fail? →
|
|
Size Change: +13.6 kB (+6.61%) 🔍 Total Size: 220 kB
ℹ️ View Unchanged
|
|
Thanks for pushing this branch, @zeroedin. I'm interested in learning more about the issues you had with rh-disclosure, because it would be good to recycle that as much as possible. Perhaps there's room for |
I felt like the changes that were to be requested were beyond the scope of what a simple disclosure would do, and the styles needed were also quite different. I also needed an element that handled dropdowns and slotted links, so I settled on |
| this._details.open = false; | ||
| } | ||
|
|
||
| public open() { |
There was a problem hiding this comment.
Should there be a declarative way to open a navigation item?
I want to lean towards no as an answer, and this may be where this details summary implementation splits from an rh-disclosure, which can be set to open on page load by default.
I'm unsure of a use case where you would want the navigation to auto-load with a dropdown open declaratively. I think that might confuse a user when they do not trigger the interaction, as well it would "hide" content below it, unlike a disclosure, which pushes it down.
I can see this behavior for jump links nav or an accordion/disclosure where you would potentially follow a #hash link to that section of the page, and you would want the disclosure open, but hiding page content with an open nav on load might be where my opinion splits.
Note, this is an early draft
❗ Expect many broken things.
Short list of current dev issues:
rh-navigation-universalneed to be moved and merged on its own branch; the component in this branch is a duplication of that effort with changes dictated in the Dec 2024 primary nav design. The intent is to merge these changes back into the previous PR. That PR will then need to merge prior to this PR.rh-navigation-itemis broken out as its own component in this branch. I have been going back and forth where this component should live. The idea is thatrh-navigation-itemcan be shared betweenrh-navigation-primary,rh-navigation-secondary, and potentiallyrh-navigation-universalfor any dropdown mechanisms. However, I encountered issues with styling and API, so I am sort of backtracking that idea a little bit. Also, ifrh-navigation-universalgoes away with the redesign, maybe it could just continue to live in the primary folder and be shared from there to the secondary nav in the future. Note: there is potential with the redesign of the primary nav that the secondary nav could also be deprecated. Originally this component named wasrh-dropdown, but I later discovered I would need to deal with both dropdowns and links in the same wrapper for style consistency. I do wonder if there is still potentially forrh-dropdownto exist here or if/howrh-dropdownmay differ fromrh-disclosure. We are sort of bending in between the two with navigation dropdowns.:8000, but linking to another component lightdom CSS exposes this linking issue with our demos.standalonerh-navigation-item. The intent was to provide a stylable surface on the secondary-links slotted nav items. They appear different on mobile as they are their own "hamburger" menus so to speak. I'm wondering if that idea should be reversed, maybe agroupattribute or something to denote belonging to a hamburger.... opinions are welcome here.rh-overlayfragment also exists in this branch, the idea is again this would be shared betweenrh-navigation-primary,rh-navigation-secondary, andrh-sidenavTODO
ul > livia element internals instead of slotted lightdom. @bennypowers thank you for reminding me this is the path.What I did
Testing Instructions
Notes to Reviewers