docs: prevent header tabs from overlapping on search expand

[jijo-OO7]

Header tabs overlap when search expands [Fixes #6332]

Proposed Changes

• Fixed navigation layout shift when search is activated
• Restructured header to use separate sticky navigation container
• Maintained responsive design across all breakpoints

Reference: https://squidfunk.github.io/mkdocs-material/tutorials/

[netlify]

✅ Deploy Preview for knative ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	a9e322a
🔍 Latest deploy log	https://app.netlify.com/projects/knative/deploys/699b52f8ba00a90008aa32d0
😎 Deploy Preview	https://deploy-preview-6556--knative.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 project configuration.

[knative-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: jijo-OO7
Once this PR has been reviewed and has the lgtm label, please assign dprotaso for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[lakxy]

Hi @jijo-OO7 I don't think you have actually followed the issue discussion, read it then open the PR.

[lakxy]

This is totally mis-aligned from what @dprotaso described there.

[dprotaso]

Yeah I don't see any difference on Chrome Desktop.

[dprotaso]

Note the idea is for the home, docs etc in the top row to not move when the search bar has focus

[jijo-OO7]

Thanks for the pointer. I’ve re-read the original issue discussion and I see where the intent differs from the current implementation.
Based on @dprotaso’s clarification, I’ll update the PR so the top navigation remains static when the search bar gains focus

[jijo-OO7]

Hi @dprotaso Updated the implementation based on your feedback. The top navigation now remains static when search gains focus by moving to a separate sticky container, following the Material for MkDocs pattern.

Would appreciate your review to ensure this matches the intended behavior. Let me know if any further adjustments are needed.

[lakxy]

@jijo-OO7 I am not sure if this is what was described? the before version is not complete, initially there were elements in nav beside the search bar, which have been removed in after version,
You explicitly hid that part in PR description? why?

[lakxy]

Final review to @dprotaso . Does not seem optimal to me.

[lakxy]

Thanks for the pointer. I’ve re-read the original issue discussion and I see where the intent differs from the current implementation. Based on @dprotaso’s clarification, I’ll update the PR so the top navigation remains static when the search bar gains focus

@jijo-OO7 Again, you did not follow the issue discussion, as Far as I know the nav elements were described to be overlayed by search bar expansion and not removed.

[dprotaso]

Yeah this doesn't look correct

[jijo-OO7]

@dprotaso Could you try reloading the preview? The navigation elements remain visible on my local build and the search expands as expected per the Material for MkDocs pattern. A cache refresh might resolve any discrepancies.

[dprotaso]

I would expect Home etc. to be at the same horizontal line as the search bar

[jijo-OO7]

Got it, thank you for clarifying. I understand now, the navigation items should remain aligned on the same horizontal line as the search bar. I'll revisit the implementation to ensure proper alignment and will push an updated commit shortly with Home, Docs, About, Blog, and Community properly aligned alongside the search bar.

[jijo-OO7]

Do we expect the top nav to be static as well upon search expansion ?

[dprotaso]

Do we expect the top nav to be static as well upon search expansion ?

Yeah

[jijo-OO7]

Hi @dprotaso, I’ve updated the PR with the latest changes. Could you please take a look when you have a moment and let me know if this aligns with the intended vision, or if any further tweaks are needed?

[jijo-OO7]

Fixed a broken redirect for the contributing docs that was causing the strict docs build to fail after rebasing onto the latest upstream/main

[jijo-OO7]

@dprotaso I ran ./hack/build.sh --strict locally and the build fails with:
WARNING - Redirect target 'community/contributing/README.md' does not exist!

I verified the current docs structure and we have docs/community/contributing.md (file), not docs/community/contributing/README.md (directory + file). I tried updating the redirect target to community/contributing.md, but the strict check still fails.

This makes me think the CI check might be validating redirects against a different path layout (or across release branches where the structure differs). Could you confirm the expected redirect target here, or whether the strict check needs an update to reflect the current docs structure?

[jijo-OO7]

@dprotaso i have updated the pr with expected changes .
can you check on this once on your end .
Thank you for your time and patience.

[dprotaso]

I see the menu doesn't move but everything else is broken.

@jijo-OO7 At this point I don't want to keep reviewing this PR while things remain in a broken state. This has happened on about 10 times now.

I'm moving this back to draft and I want you to verify things are working as expected prior to marking this as done. To make open source managable I can't be 'testing' your changes when clearly you have not.

[dprotaso]

Everytime you push a change the preview is updated here: #6556 (comment)

You should be using that to verify your work.

[jijo-OO7]

I see the menu doesn't move but everything else is broken.

@jijo-OO7 At this point I don't want to keep reviewing this PR while things remain in a broken state. This has happened on about 10 times now.

I'm moving this back to draft and I want you to verify things are working as expected prior to marking this as done. To make open source managable I can't be 'testing' your changes when clearly you have not.

I understand the concern, and apologies for the repeated broken states I’ll make sure this is properly validated against the preview going forward before marking it ready again.

[jijo-OO7]

I’ve made some progress on reducing the overlap behavior, but resolving this cleanly across viewports is turning into a larger layout refactor than initially anticipated.

To avoid blocking other work, I’m going to pause on this for now. I’m happy to revisit and iterate further if this is still considered a priority.

Thanks!

[jijo-OO7]

UPDATE

I revisited this and scoped the header/search layout fixes to desktop breakpoints only, so mobile behavior remains unchanged.
I’ve verified the overlap is resolved on desktop and that mobile viewports behave as before (including on deploy preview).

[dprotaso]

The search functionality is still broken - please test your changes before marking the PR as ready

[jijo-OO7]

Hi @dprotaso — thanks for the continued feedback and for your patience here.

I’ve been rechecking the latest Netlify preview and confirmed the search interaction is still not behaving as expected with my recent changes. I’m keeping this in draft until that’s resolved.

While debugging, I also noticed that even after reverting my CSS updates, the search remains in an “Initializing search” state in:

Docker preview (./hack/docker/run.sh)

Netlify preview

Since this differs from production, I might be missing something in the preview/dev setup. If there’s a known setup or reference branch you’d recommend for validating search behavior locally, I’d appreciate the pointer.

Thanks again for the guidance.

[dprotaso]

unsure @evankanderson do you know why the search might be broken in the preview?