fix(masthead): prevent megamenus from overlaying global banner #11779
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…e is also a ToC (carbon-design-system#11734) none Given the page uses both an L1 menu and a table of contents (ToC), and the page is displaying at a mobile breakpoint, and the ToC menu is the sticky element (i.e. stuck to the top of the viewport), and the user scrolls up slightly to reveal the L1 dropdown, and the user open the L1's dropdown menu, then the dropdown menu gets hidden above the viewport, forcing the user to scroll up more to access it. Instead, the top of L1 dropdown menu should be visible when opened. This problem is occurring because the dropdown exists in the document flow, and the StickyHeader utility doesn't reset stuck elements' positions when the menu is opened. The easiest solution I found was to position the dropdown menu absolutely like most other dropdown menus you might encounter. This bypasses the tricky problem of trying to get the StickyHeader to recalculate, and in my opinion is a slight enhancement in both performance (avoids layout shifts and associated repaint costs) and overall UX (gives dropdown a more expected behavior). **Changed** - Prevents mobile L1 dropdown menu from becoming hidden above viewport when opened while there is currently a sticky table of contents menu. - Prevents L1 from scrolling away when a submenu is open on desktop or the dropdown is open on mobile. - Consolidates StickyHeader utility tracked data to make debugging easier. - Refactors StickyHeader logic to support all potentially sticky elements being on page at the same time. To test the main fix: 1. Visit [the Dotcom Shell > With L1 story](https://ibmdotcom-webcomponents.s3.us-east.cloud-object-storage.appdomain.cloud/deploy-previews/11734/index.html?path=/story/components-dotcom-shell--with-l-1) in the deploy preview. 2. Change the preview size to "Large mobile" or "Small mobile" 3. Scroll down the page until the ToC is stuck to the top of the viewport. 4. Scroll back up just enough to see the L1. 5. Open the L1 and verify the top of it doesn't jump back up above the viewport. 6. Scroll down and verify the L1 stays stuck to the top of the viewport. 7. Close the L1 and verify the ToC gets stuck to the top of the viewport as you scroll down. You should also test the L1 remains stuck when open at desktop widths. This PR also changes a good amount of the StickyHeader class logic. To support regression testing the existing sticky element behaviors, I've added the [Sticky Element Sandbox story](https://ibmdotcom-webcomponents.s3.us-east.cloud-object-storage.appdomain.cloud/deploy-previews/11734/index.html?path=/story/components-dotcom-shell--sticky-element-sandbox). Test various knob configurations at both desktop and mobile viewport sizes and let me know how you were able to break it 😄 **Note:** If you find the sticky elements aren't working correctly when switching between stories, try reloading the window.
jkaeser
added
package: styles
|
Deploy preview created for package Built with commit: a80ea5c5522724adefe8c8fbd644c9fd96e1720a |
|
Deploy preview created for package Built with commit: a80ea5c5522724adefe8c8fbd644c9fd96e1720a |
|
Deploy preview created for package Built with commit: a80ea5c5522724adefe8c8fbd644c9fd96e1720a |
|
Deploy preview created for package Built with commit: a80ea5c5522724adefe8c8fbd644c9fd96e1720a |
jkaeser
force-pushed
the
fix/masthead-megamenu-banner-position
branch
from
4fbb429
to
0050368
Compare
jkaeser
force-pushed
the
fix/masthead-megamenu-banner-position
branch
from
b9357fb
to
a80ea5c
Compare
|
Closing in favor of #11837 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Note: This PR currently relies on changes from #11773, which is why there are extra commits. We'll want to hold off on merging this until that PR has been merged.
Related Ticket(s)
Closes #11775
Description
Currently,
<c4d-megamenu>are slotted into a<ul>that isposition: fixed;. This is what allows them to extend the full width of the viewport on desktop, but it also means they cannot align themselves relative to other elements using CSS alone. At this stage in the jenga tower, there's not a great CSS-only fix for our issue.So we turn to our good friend JavaScript for assistance.
<c4d-top-nav-menu>items now report the position of their bottom edge via a--c4d-masthead-top-nav-menu-bottom-edgeCSS custom property when toggled open.<c4d-megamenu>elements reference this prop to position themselves in the exact right place when they get loaded into the DOM.Changelog
New
<c4d-top-nav-menu>items expose the position of their bottom edge via a--c4d-masthead-top-nav-menu-bottom-edgeCSS custom property.Changed
<c4d-megamenu>CSS to reference--c4d-masthead-top-nav-menu-bottom-edgevalue to position themselves correctly when they load into the DOM.