docs: prevent header tabs from overlapping on search expand

[jijo-OO7]

Header tabs overlap when search expands [Fixes #6332]

BEFORE

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/

AFTER

[netlify]

✅ Deploy Preview for knative ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	99d4d03
🔍 Latest deploy log	https://app.netlify.com/projects/knative/deploys/698c69fc4310fa00087ca52a
😎 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

[codeEvolveZenith345]

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

[codeEvolveZenith345]

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.

[codeEvolveZenith345]

@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?

[codeEvolveZenith345]

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

[codeEvolveZenith345]

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]

I’ve pushed a follow-up that fixes the version selector overlap when the search bar is expanded.

I’ve verified the latest preview on my end and it now behaves as expected. Could you please take another look and let me know if this works for us? I’m happy to make further tweaks if needed.
Thanks!

[dprotaso]

I still see home, docs etc shifting around in the preview

[jijo-OO7]

In that case do we expect the knative logo and the version selector to be static as well cause right now they just hide on search bar expansion or we are okay with the behavior the way it is at present?

[dprotaso]

Clicking the search bar shouldn't move/hide anything. there should just be an gray overlay ontop of everything

[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!