Skip to content
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

navbar shouldn't contain the navbar mobile sidebar #275

Open
slorber opened this issue Oct 6, 2022 · 0 comments
Open

navbar shouldn't contain the navbar mobile sidebar #275

slorber opened this issue Oct 6, 2022 · 0 comments

Comments

@slorber
Copy link
Collaborator

slorber commented Oct 6, 2022

We should be able to set different stacking contexts (ie z-index layers) for the navbar and the mobile sidebar.

Not doing so is annoying because we want some elements to be able to cover the navbar (announcementBar shadow, skipToContent)... and yet have the mobile navbar cover those.

I gave it a try in facebook/docusaurus#7940 to increase the announcementBar z-index so that its shadow can be seen on top of the navbar (gives a better sensation of depth and seems the right thing to do)

CleanShot 2022-10-06 at 12 41 21@2x

But this leads to issues on mobile:

CleanShot 2022-10-06 at 12 42 47@2x

CleanShot 2022-10-06 at 12 43 25@2x

Due to the current inability of having 2 separate stacking contexts, I have to fix the 2 issues above by reverting my change, and removing the announcementBar shadow in favor of a bottom border.


We should refactor Infima to allow rendering the navbar and its associated mobile sidebar in 2 separate DOM trees. Ie not having classes such as .navbar.navbar-sidebar--show .navbar-sidebar like we currently have, assuming the sidebar is a child of the navbar.

@yangshun if it were me I'd remove all things related to macro-layout orchestration like fixed/sticky positioning and margins from Infima and only declare these things on the Docusaurus side. Having this in Infima creates DX friction to test the change easily locally and in PRs. I'd rather have Infima focus only on the design system elements and not how elements are displayed inside the app. Any opinion?

Note that if we want to have a Tailwind theme, it's likely to have the same mobile sidebar behavior, animation and positions. I'd rather have this CSS in @docusaurus/theme-common as shared CSS modules so that we can avoid duplicating it in each design system / theme.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant