-
Notifications
You must be signed in to change notification settings - Fork 149
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
chore(sticky-header): port refactor to v2 #11773
chore(sticky-header): port refactor to v2 #11773
Conversation
…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.
Deploy preview created for package Built with commit: 12ecf8fd9bc8c407c58c467c7e6691345ce25c49 |
Deploy preview created for package Built with commit: 12ecf8fd9bc8c407c58c467c7e6691345ce25c49 |
Deploy preview created for package Built with commit: 12ecf8fd9bc8c407c58c467c7e6691345ce25c49 |
Deploy preview created for package Built with commit: 12ecf8fd9bc8c407c58c467c7e6691345ce25c49 |
Deploy preview created for package Built with commit: 12ecf8fd9bc8c407c58c467c7e6691345ce25c49 |
I was seeing some strange behavior at mobile viewport resolutions while using Chrome's dev tools. Stuck elements were being positioned something like 40 pixels above the top viewport edge. However, I do not see the same issue when simply resizing my window down, nor do I see it in Firefox or Safari. It's making me nervous, though, so I'd appreciate if reviewers could test the mobile sticky behaviors quite thoroughly! |
2b1b9a7
to
4d0f1ec
Compare
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.
All the dotcom-shell stories look good to me
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.
LGTM!
Looks like Percy isn't happy about a missing snapshot? Doesn't seem releated this this... |
I'll try closing & reopening the PR to re-run the job first. If that doesn't work, time to call in a Carbon team member. |
365c9b6
into
carbon-design-system:main
Description
Ports changes made to feat/masthead-v2-dev branch in #11734 to v2 branch.
In order to adequately test the new Sticky Header Sandbox story, I had to clean up the Dotcom Shell stories. The
mock
secret menu item works again now, and I've reduced a good amount of bloat in the stories' markup. While I was at it, I noticed I never updated Dotcom Shell'snavLinks
prop for L0 items to Masthead's newl0Data
prop, so I added support for that as well.Testing
The code changes here are mostly identical to the aforementioned PR, with the only divergences being changes necessary for v2. Please verify each of the Dotcom Shell stories works as expected, taking particular care to test the sticky elements behaviors on both desktop and mobile.