I'm a fan of this, but definitely gonna defer to @dorafc

Oh, but how does this work on mobile?

The whole page is not responsive. It's wider than typical mobile screens. Therefore, you have to scroll horizontally. This is not getting better or worse by moving the search field. IMHO responsiveness is for a separate PR.

Link to built docs

Apart from #15717, an additional motivation was that the top position in the sidebar would be a good place to announce our job offering. For that, it would be helpful to move this PR forward rather soon.

Yes I agree responsiveness is for a seperate PR, but what I'm wondering is when/if we ever do responsiveness, if search would still make sense in the nav bar. Basically I'm worried search would be moved only to be moved back & that might be disorienting for users. Agree with you though on side panel being a good place for announcements.

I'm not concerned that we would have to move the search field back for responsiveness. With responsive designs, you typically fold the navbar and expand it on demand. It's common to take the search bar along. Take https://seaborn.pydata.org/ for example:

Menu folded:

Menu unfolded:

Apologies for somewhat disappearing - I started a job search and its taken up more time / emotional bandwidth than I anticipated. I think moving the search bar into the nav bar is fine idea. It's still pretty close to where it is in the current site, which should help if anyone is surprised to not see the search bar where they anticipate. Moving the search bar into the nav is probably better for future responsiveness. As Tim pointed out, search fields do often get moved into expandable menus on mobile devices, and it would make more sense to keep the nav here than in the sidebar when things shrink down.

Code looks fine too.

Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

1. Checkout backport branch and update it.

$ git checkout v3.1.1-doc
$ git pull

2. Cherry pick the first parent branch of the this PR on top of the older branch:

$ git cherry-pick -m1 ec123758821827b66ed591b3e2abbdcdd59c9175

3. You will likely have some merge/cherry-pick conflict here, fix them and commit:

$ git commit -am 'Backport PR #15859: Doc: Move search field into nav bar'

4. Push to a named branch :

git push YOURFORK v3.1.1-doc:auto-backport-of-pr-15859-on-v3.1.1-doc

5. Create a PR against branch v3.1.1-doc, I would have named this PR:

"Backport PR #15859 on branch v3.1.1-doc"

And apply the correct labels and milestones.

Congratulation you did some good work ! Hopefully your backport PR will be tested by the continuous integration and merged soon!

If these instruction are inaccurate, feel free to suggest an improvement.

I don't think it's necessary to backport to 3.1.1-doc. There are some other issues with the nav bar in there, which prevents a clean backport.