fix: include a left class to navbar

[wellwelwel]

Pre-flight checklist

• I have read the Contributing Guidelines on pull requests.
• If this is a code change: I have written unit tests and/or added dogfooding pages to fully verify the new behavior.
• If this is a new API or substantial change: the PR has an accompanying issue (closes #0000) and the maintainers have approved on my working plan.

Motivation

Currently, in a custom CSS, I can modify the direct navbar children by using selectors like :first-child for the left element, while I can select the right element using the .navbar__items--right class.

This PR improves DX by including the same approach/semantic for both left and right classes for direct children in navbar, improving the selectors' consistency.

• There is no change to styles, it's more about the final user (an extra intuitive class for us) 🙋🏻‍♂️

Why

After this PR we'll be able to use both the current approach, as well as choosing a navbar__items--left class selector.

Practical example:

✅ Current approach	✅ New approach
.navbar__inner { :first-child { // ... } .navbar__items--right { // ... } }	.navbar__inner { .navbar__items--left { // ... } .navbar__items--right { // ... } }
Examples using SCSS.

⛓️‍💥 An extra motivation

If, for some reason, a new first element is added to navbar (for example, a non-visible element), the first approach will break, while the new one maintains a safe selectors' consistency.

Thanks for Docusaurus's existence 🦖💙

Test Plan

Test links

Deploy preview: https://deploy-preview-10843--docusaurus-2.netlify.app/

Related issues/PRs

[facebook-github-bot]

Hi @wellwelwel!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

[netlify]

✅ [V2]

Built without sensitive environment variables

Name	Link
🔨 Latest commit	ef30d93
🔍 Latest deploy log	https://app.netlify.com/sites/docusaurus-2/deploys/6788755736cb100008d4e292
😎 Deploy Preview	https://deploy-preview-10843--docusaurus-2.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[facebook-github-bot]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!

[github-actions]

⚡️ Lighthouse report for the deploy preview of this PR

URL	Performance	Accessibility	Best Practices	SEO	Report
/	🟠 62	🟢 98	🟢 96	🟢 100	Report
/docs/installation	🔴 48	🟢 97	🟢 100	🟢 100	Report
/docs/category/getting-started	🟠 72	🟢 100	🟢 100	🟠 86	Report
/blog	🟠 60	🟢 96	🟢 100	🟠 86	Report
/blog/preparing-your-site-for-docusaurus-v3	🔴 46	🟢 92	🟢 100	🟢 100	Report
/blog/tags/release	🟠 61	🟢 96	🟢 100	🟠 86	Report
/blog/tags	🟠 73	🟢 100	🟢 100	🟠 86	Report

[slorber]

These classes are coming from Infima as a styling implementation detail.
https://infima.dev/docs/components/navbar

They are not meant to be used as a reliable way to select CSS elements. In the future, we may remove Infima, and use inline styling solutions instead, and your selectors will break. For example, we may introduce a Tailwind theme in the future, that won't have any of these 2 class names.

I'm not fan of introducing an Infima-looking class that does nothing and is only meant to be used as a CSS selector.

We have ThemeClassNames for that:
https://docusaurus.io/docs/next/styling-layout#theme-class-names

I'd prefer to introduce ThemeClassNames.layout.navbar.{left/right}Container stable classNames instead.

[wellwelwel]

I'd prefer to introduce ThemeClassNames.layout.navbar.{left/right}Container stable classNames instead.
I'm not fan of introducing an Infima-looking class that does nothing and is only meant to be used as a CSS selector.

Thanks, @slorber! I really like this idea. It would be great to make it possible to dynamically add classes to navbar and its direct elements/items using the configuration file (similar to how it already works for navbar items).

---

I'd like to illustrate an useful aspect from the developer's side before:

• I needed a simple way to hide the left menu at the top (but not the one on right).
• When scrolling down, I'd like it to reappear after a specific point.
• To do this, the general navbar would need to be always visible, enabling me to choose showing only the specific items (using the empty, but consistent selector — inserting classes via the configuration file would fit nicely here).

Resulting in:

---

"OSI thinking": I brought this simple PR because I think it can be useful for developers who customize the style at a lower level (including more advanced levels using swizzle) and I'm totally open to contribute with a possible ThemeClassNames.layout.navbar.{left/right}Container implementation.

Please let me know what you think.

Note

I would like to contribute to the Portuguese (BR) translations in the future, which are quite outdated and also incomplete. So, I'll be here a few times yet 🙋🏻‍♂️

[slorber]

Feel free to modify this PR and add ThemeClassNames for various navbar layout elements you'd find convenient to be able to target reliably. I'll review your propositions and eventually merge.

Adding classNames through the configuration file is more complicated, notably for the left/right containers because our current API doesn't really permit it, it would require a breaking change. Hardcoding 2 ThemeClassNames classes should be good enough and doesn't require to modify the API.