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

Making navbar width consistent with the main layout on large displays #7562

Open
1 of 2 tasks
jetxr opened this issue Jun 4, 2022 · 16 comments
Open
1 of 2 tasks

Making navbar width consistent with the main layout on large displays #7562

jetxr opened this issue Jun 4, 2022 · 16 comments
Labels
better engineering Not a bug or feature request domain: theme Related to the default theme components status: accepting pr This issue has been accepted, and we are looking for community contributors to implement this

Comments

@jetxr
Copy link

jetxr commented Jun 4, 2022

Have you read the Contributing Guidelines on issues?

Description

  • On large displays, the navbar's width isn't matched to the main content, footer, and it expands to the edges of the screen making it easy to miss the navbar's contents. (demonstrating the issue on docusaurus.io below in screenshot)

  • However, if max-width and justify-content are applied, it makes the navbar more consistent with the rest of the design.

  • I've added the following to my custom.css, and it seems to be working

.navbar {
	justify-content: center;
}

.navbar__inner {
	max-width: var(--ifm-container-width-xl);
}
  • Should this be Docusaurus' default behavior?

Issue

docusaurus(iMac) - Issue


Suggested Change

docusaurus(iMac) - Suggestion

Has this been requested on Canny?

No response

Motivation

  • On large displays, with main body having a max width, it's looks a bit out of place to have the menu items at the edges, and not have the navbar as the same width as the rest of the content.

  • When the nabar is the same max width as the content area, you don't need to scan the entire width of the screen. The entire page stays a vertical scannable area. For ex. https://developer.apple.com/documentation/Xcode/Xcode-Cloud

API design

No response

Have you tried building it?

No response

Self-service

  • I'd be willing to contribute this feature to Docusaurus myself.
@jetxr jetxr added feature This is not a bug or issue with Docusausus, per se. It is a feature request for the future. status: needs triage This issue has not been triaged by maintainers labels Jun 4, 2022
@Josh-Cena Josh-Cena added better engineering Not a bug or feature request domain: theme Related to the default theme components status: accepting pr This issue has been accepted, and we are looking for community contributors to implement this and removed feature This is not a bug or issue with Docusausus, per se. It is a feature request for the future. status: needs triage This issue has not been triaged by maintainers labels Jun 5, 2022
@Josh-Cena
Copy link
Collaborator

Josh-Cena commented Jun 5, 2022

Agree, feel free to send a PR!

Note, there are a few nuances. For example, I think it's perfectly fine for my 1440px screen to have the navbar take up the entire width, so maybe the navbar should still be a bit wider than the main content, just not stretching all the width.

@jetxr
Copy link
Author

jetxr commented Jun 5, 2022

Yes, makes sense to apply it to screens > 1440px. Could use a media query to do that. Will try and send a PR this week.

@Josh-Cena
Copy link
Collaborator

It's a bit awkward that we only have 996px as the only cutoff currently. We should have a more nuanced screen width system, like xl/lg/md etc... For example, we would want to display icons-only on medium-sized screens (e.g. ipads) (ref #7566)

@LichLord91
Copy link
Contributor

LichLord91 commented Jun 8, 2022

Added this to my own website, however I noticed the Sidebar in docs (at least when set to hideable) sticks to the left as well and in @jetxr example of the Apple site it remains centered with the rest of the content. Any suggestions in changing this behavior?

image

image

@jetxr
Copy link
Author

jetxr commented Jun 9, 2022

Adding a max-width and margin: auto to main-wrapper seemed to work. Not sure if it's the best way to do it. Also, new to Docusaurus, so I don't know if this will have an effect on something else. Maintainers can confirm.

Screen Shot 2022-06-09 at 10 17 28 AM

To be honest, sidebar sticking to the edge of a large screen, while having the navbar centered does looks odd. So on docs pages, if the navbar has to be centered, the sidebars should be as well.

On non-docs pages, the centered navbar might be preferable for some. But on the docs pages, both the options (full-width navbar + left-aligned sidebar vs centered page) have their uses.

Might be a better idea to make this configurable, and part of a larger task?

@Josh-Cena
Copy link
Collaborator

We'd rather offer a good default and let users override with custom CSS.

@jetxr
Copy link
Author

jetxr commented Jun 9, 2022

Makes sense. Adding a couple of lines of CSS does the work.

I do however think having the navbar centered for large-screens on non-docs pages is a better default.

@Josh-Cena leaving it up to you if we can keep this issue open. As such, there is a solution.

@Josh-Cena
Copy link
Collaborator

Josh-Cena commented Jun 9, 2022

The site with the closest layout that comes to mind is https://www.typescriptlang.org/. Here's what they got:

image

image

The navbar grows infinitely, but the main content has max-width. That's very close to what we do. OTOH, https://mui.com/ has a constrained navbar for the landing page but a wide navbar for the docs, which is what you want.

image

image

In Docusaurus v1, the navbar always has a constrained width.

image

Related to #4347. @orta ideas on how the navbar should grow?

@orta
Copy link
Contributor

orta commented Jun 9, 2022

Alas "it depends" there are a few constraints to consider with this decision (I'll describe them from TS' side)

  1. The navbar being consistent feels pretty important as its a primary way to get around IMO
  2. Different pages need different width constraints
    • Long bodies of text gets much harder to read at wider widths,
    • Pages like the playground want to be full bleed at whatever side

For the TS site, I opted to have a consistent left nav rather than having it changing because the playground represents a large amount of the site traffic.

Looking at Jest's docs, there isn't really a page which needs a full bleed layout - the biggest design conflict comes from the nav column which always aligns left edge and the content which is max width and centered. If the navigation column moves in with the center, then I'd say its a pretty easy win for team 'center the top nav'

image

If keeping that permanently right aligns is a preferred, then I think it might still feel better to keep the nav also right + left aligned

@jetxr
Copy link
Author

jetxr commented Jun 9, 2022

Just a thought.. would it be ideal to set the max width of the entire site to 1730px? (16" MBP)

Anything wider would probably be an external display/very large display, and it's not too comfortable to scan content horizontally at that width.

It would:

  • Make the navbar be consistent on all pages, and keep sidebar navigation close/closer to content
  • Suits a documentation site, which will mostly be readable content
  • Can be turned off for the whole site with global CSS if the user wants to make whole site full bleed
  • On pages which need to be 100% full bleed even on super large screens, the max-width can be turned off, and the content can be placed in 'break-out' sections and won't look broken (?)

Screen Shot 2022-06-09 at 1 23 45 PM

(TypeScript Playground with full-bleed but constrained navbar)

@LichLord91
Copy link
Contributor

LichLord91 commented Jul 6, 2022

Looking at https://theochu.com and reading the css in dev tools. I like the solution he came up with. Seems to work great on mobile/full screen and with collapsible button.

@media (min-width: 1416px) {
	.main-wrapper {
		align-self: center;
		max-width: 1400px;
		width: 1400px;
	}
}

.navbar .navbar__inner {
    margin: 0 auto;
    max-width: 1360px;
}

image

@alanlivio
Copy link

The @jetxr initial proposal worked for me.
Other method is this css used by the ReactNative website, for instance, in this page

@oyatek
Copy link

oyatek commented Apr 30, 2024

@LichLord91 solution works well but I've added this to have 100% navbar width on the docs pages, where sidebar sticks to the left side of the screen:

  html.docs-doc-page .navbar .navbar__inner {
    max-width: 100%;
  }

@rtxa
Copy link

rtxa commented Aug 21, 2024

@LichLord91 What if I just want to apply the centered content to the Docs page only? I have some indivual pages that requires the background to expand to 100% width.

This CSS code fixes the issue by applying full content centering only on the Docs page, while leaving the navbar centering enabled on the rest of the pages (Thanks @oyatek for mentioning about html.docs-doc-page).

/* This will fix the navbar and sidebar not being centered on large screens */
@media (min-width: 1416px) {
  /* Only apply sidebar centering on Docs page */
  html.docs-doc-page .main-wrapper {
		align-self: center;
		max-width: 1400px;
		width: 1400px;
	}
}

.navbar .navbar__inner {
    margin: 0 auto;
    max-width: 1360px;
}

@rtxa
Copy link

rtxa commented Aug 21, 2024

I just find out an annoying issue with the navbar shifting to the left when the scrollbar appears or dissappear. The issue wasn't very noticeable before because the shift only affected the elements on the right side of the navbar, but now that is centered, the shifting is affecting the entire navbar. Hope someone can find a workaround for this.
Animation

@slorber
Copy link
Collaborator

slorber commented Aug 21, 2024

@rtxa the scrollbar layout shift is annoying but unfortunately I wasn't able to work around it so far. Tracked in #7130

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
better engineering Not a bug or feature request domain: theme Related to the default theme components status: accepting pr This issue has been accepted, and we are looking for community contributors to implement this
Projects
None yet
Development

No branches or pull requests

8 participants