fix(navbar): make non-scrolled blog navbar full width on desktop#384
Open
mvanhorn wants to merge 2 commits into
Open
fix(navbar): make non-scrolled blog navbar full width on desktop#384mvanhorn wants to merge 2 commits into
mvanhorn wants to merge 2 commits into
Conversation
Closes keploy/keploy#3428 The expanded (non-scrolled) blog navbar was capped at `w-[96%] md:max-w-6xl`, which on >=1280px viewports rendered as ~80% of the header — out of step with keploy.io's landing-page navbar that spans the full header. Changing the expanded width classes to `w-full md:max-w-none` lets the navbar fill its parent (the `Header` wrapper at `components/header.tsx` line 33 is `fixed left-0 right-0 z-30 w-full ...`, so this resolves to 100% of the viewport on desktop). The scrolled state is unchanged — `w-[82%] md:max-w-5xl` still applies, and the existing scroll-shrink animation is preserved verbatim. Single-line diff in the `navWidthClasses` ternary; no other components or styles touched. Signed-off-by: Matt Van Horn <455140+mvanhorn@users.noreply.github.com>
42caa09 to
60b0c60
Compare
Contributor
There was a problem hiding this comment.
Pull request overview
Adjusts the blog’s floating navbar expanded (non-scrolled) desktop layout to span the full header width, aligning with the desired visual parity for the blog landing page.
Changes:
- Updated the non-scrolled
navWidthClassesfrom a capped desktop max-width (md:max-w-6xl) to an uncapped full-width configuration (w-full md:max-w-none). - Left the scrolled/shrunken navbar width branch unchanged (
w-[82%] md:max-w-5xl).
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+45
to
+47
| const navWidthClasses = isScrolled | ||
| ? "w-[82%] md:max-w-5xl" | ||
| : "w-[96%] md:max-w-6xl"; | ||
| : "w-full md:max-w-none"; |
Per Copilot review feedback: w-full applied at every breakpoint and lost the previous mobile gutter. Restore w-[96%] on mobile, lift to full-width at md: so the desktop intent is preserved without edge-to-edge mobile.
Author
|
Fixed in 2f9caab -- restored |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes keploy/keploy#3428
What this PR does
In
components/navbar/FloatingNavbar.tsx, thenavWidthClassesternary now resolves tow-full md:max-w-nonefor the non-scrolled state instead ofw-[96%] md:max-w-6xl. The scrolled-state branch (w-[82%] md:max-w-5xl) is unchanged.Net diff: 1 line in 1 file.
Why
The blog landing page's expanded navbar was being capped at
max-w-6xl(72rem = 1152px) on desktop, so on a 1920px-wide viewport it rendered as ~60% of the header bar — visually about 80% (which is what the issue screenshot shows). The issue specifically asks for parity with keploy.io's landing-page navbar, which spans the full header.The container that wraps
<FloatingNavbar />(components/header.tsxline 33) isfixed left-0 right-0 z-30 w-full ...and has no horizontal padding, so removing the max-width cap from the expanded navbar lets it fill the viewport, matching the issue's described behavior.The non-blog-reading positioning class (
fixed left-1/2 -translate-x-1/2) keeps the navbar centered, andw-fullplus the-translate-x-1/2math results in a centered full-width element. The blog-reading positioning class (relative top-0 mx-auto) similarly works withw-full.What's NOT changed
isScrolledbranch returnsw-[82%] md:max-w-5xlexactly as before).navPaddingClasses.Verification
npm installsucceeded (490 packages).WORDPRESS_API_URL=https://example.com npm run lintpasses — only pre-existing warnings appear in unrelated files (components/post-body.tsx,components/testimonials.tsx, etc.); no new errors or warnings onFloatingNavbar.tsx.components/header.tsx'sw-fullwrapper). Maintainer should still browser-check before merge — labeled draft for that reason.Note re: PR #334
PR #334 ("Fix: Align Hero Section and Navbar Widths") is open and also touches
FloatingNavbar.tsx, but it pursues a different alignment goal (capping at 1200px and adding hero/testimonials padding). The change here is independent of that work and addresses issue #3428 specifically (full-width expanded navbar). Happy to rebase if #334 lands first.