rh-secondary-nav component - stickiness

[alypilkons-RH]

Hey all - I'm starting work on rebuilding redhat.com secondary navs using the new rh-secondary-nav component. 🎉

Currently, on pages with the main nav but no secondary nav, the main nav is sticky as the user scrolls. On pages with the main nav and a secondary nav, the main nav loses its stickiness and the secondary nav is sticky on scroll. (Example here: https://www.redhat.com/en/technologies/management/ansible)

It sounds like there's nothing within the rh-secondary-nav component to handle that kind of functionality, so I would need to write my own JS to handle that. I was curious the team's thoughts on that. I would be writing separate JS that is basically essential for the component to work as expected with the RH main nav. Could that JS be 'part' of the component itself?

[zeroedin]

I can see a possible long-term solution being to create a wrapper component around both <rh-nav> and <rh-secondary-nav>:

Example:

<rh-nav-position>
  <rh-nav>...</rh-nav>
  <rh-secondary-nav>...</rh-secondary-nav>
</rh-nav-position>

This rh-nav-position wrapper element or whatever we might call it could provide some level of customization to how the two navs interact on page scroll and provide the appropriate CSS changes or JS API calls to either of the navs when needed.

For the time being because rh-nav isn't provided by @rhds/elements at the moment, we will have to implement this some other way.

Feel free to look at the JS code in the spandx proxy demo in secondary-nav.

I'm positive that this demo code is not production ready as there may be more thoughts on how to better handle throttling of the scroll event, and it does not take into consideration anything that is placed above the primary nav increasing the spacing between the top and the navs. This was workable for demo purposes at the time. Essentially all it is doing is swapping the z-index values to allow the secondary-nav sticky position to overlay the primary nav when scrolled beyond 40px from the top of the screen. Any other requirements would have to be resolved on a per-implementation page spec.

Any code written for RHDC though would definitely inform how we would/should build the <rh-nav-position> wrapper component later.

[alypilkons-RH]

Thanks @zeroedin !

Content placed above the primary nav is definitely a concern, since personalization banners are frequently placed there. Some of these banners even expand and collapse when interacting with them, pushing the nav down and further complicating things.

Ideally the secondary nav would become sticky right when it reaches the top of the screen so it's a super smooth experience, but if there's potentially a banner above that expanded after load, we'd need mutation observers I think to even get an accurate read of the y value for the nav.

I like the rh-nav-position idea, but the personalization banners are still an issue 🤔

Sounds like I'll have to write some JS to get this working for now at least, but curious is anyone else has thoughts!