fix: improve banner mobile responsiveness and remove unused sidebar calculations

[HarshMN2345]

What does this PR do?

Before:

After

Test Plan

(Write your test plan here. If you changed any code, please provide us with clear instructions on how you verified your changes work.)

Related PRs and Issues

(If this PR is related to any other PR or resolves any issue or related to any issue link all related PR and issues here.)

Have you read the Contributing Guidelines on issues?

(Write your answer here.)

Summary by CodeRabbit

• Style

  • Improved responsive design for the teaser banner across mobile, tablet, and desktop viewports.
  • Adjusted typography sizing for better readability on smaller screens.
  • Optimized logo scaling across different screen sizes.

• Refactor

  • Simplified mobile navigation layout and positioning logic.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

This pull request simplifies the MobileNav component by removing banner-height dependency from its layout logic and removes unused UI imports (InlineTag, Icon). Concurrently, the teaser-banner component is refactored to use responsive sizing instead of fixed dimensions, with adjusted typography and logo sizing across multiple viewport breakpoints (375px, 640px, 768px). The changes decouple the mobile navigation from banner state management while introducing fluid responsive behavior to the banner component.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

• MobileNav.svelte: Verify that removing the dynamic top offset based on bannerHeight doesn't create layout overlap issues or unintended spacing changes; confirm that the simplified nav element with class:hidden={!open} maintains expected positioning behavior.
• teaser-banner.svelte: Validate that the new responsive breakpoints (375px, 640px, 768px) render correctly across device sizes; confirm font size transitions and logo sizing don't cause visual inconsistencies at breakpoint boundaries; test that the shift from fixed to fluid dimensions (width: 100%, min-height: auto) functions as intended on narrow and wide viewports.

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main changes: improving banner mobile responsiveness and removing unused sidebar calculations from MobileNav component.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix-sidebar-in-mobile-view-and-banner-for-small-devices

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (3)

src/routes/(marketing)/(components)/teaser/teaser-banner.svelte (3)

106-108: Consider removing redundant max-width property.

The banner container changes from fixed to responsive sizing look good. However, max-width: 100% is redundant when width: 100% is already set. Consider simplifying:

🔎 Proposed simplification

 .banner-container {
     width: 100%;
     min-height: auto;
-    max-width: 100%;
 }

---

188-189: Consistent responsive sizing pattern across all banner elements.

The logo container follows the same non-linear responsive pattern as the text elements (smaller → larger at 375px → smaller at 640px → larger at 768px). This consistency suggests a deliberate design decision.

A few observations:

1. The fractional pixel dimensions (143.384px, 35.785px) suggest these values may be exported from a design tool or calculated from an aspect ratio. Consider whether rounding to whole pixels would be acceptable for simpler maintenance.

2. The coordinated size reduction at the 640px breakpoint across all elements (text + logo) suggests this range may target specific devices or design requirements.

If the fractional pixels aren't critical to maintaining aspect ratios, consider rounding:

🔎 Optional: Round to whole pixels

 @media (min-width: 375px) {
     .logo-container {
-        width: 143.384px;
-        height: 35.785px;
+        width: 143px;
+        height: 36px;
     }
 }

 @media (min-width: 768px) {
     .logo-container {
-        width: 143.384px;
-        height: 35.785px;
+        width: 143px;
+        height: 36px;
     }
 }

Also applies to: 197-202

---

106-217: Overall responsive strategy: verify the 640px breakpoint design rationale.

The PR successfully implements a comprehensive mobile-responsive banner with coordinated sizing adjustments across all elements. However, the responsive strategy introduces a distinctive pattern where elements reduce in size at the 640px breakpoint before growing again at 768px.

Pattern summary across all elements:

• <375px: Smallest (mobile-first base)
• 375px: Increased (likely targeting iPhone SE and similar)
• 640px: Reduced again (sm breakpoint)
• 768px: Increased (md breakpoint)

This creates a non-monotonic progression that differs from typical mobile-first responsive design, where sizes generally scale up or plateau as viewports grow.

Recommendations:

1. Document the design rationale for the 640px reduction, especially which devices or use cases it targets
2. Test thoroughly on actual devices at each breakpoint to ensure the size transitions feel intentional rather than jarring
3. Consider whether this complexity serves the user experience or if a simpler progression would be equally effective

The implementation is technically sound, but the UX implications of the non-linear sizing should be validated with design stakeholders and real-world testing.

📜 Review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 22707ba and b81c394.

📒 Files selected for processing (2)

• src/lib/components/MobileNav.svelte (1 hunks)
• src/routes/(marketing)/(components)/teaser/teaser-banner.svelte (5 hunks)

🔇 Additional comments (5)

src/lib/components/MobileNav.svelte (3)

28-28: Verify mobile nav positioning without banner height offset.

The removal of the dynamic top: {bannerHeight}px style means the mobile nav no longer accounts for the banner's height when positioning itself. While this simplifies the code and removes the coupling, ensure that:

1. The mobile nav doesn't overlap with or get hidden by the banner when opened
2. The sticky positioning works as expected across different viewport sizes
3. The banner's new responsive sizing (from the teaser-banner changes) doesn't cause layout issues

Test the mobile nav behavior manually on devices with different screen sizes, especially:

• Very small screens (<375px)
• iPhone SE width (375px)
• Standard mobile (640px)
• Tablet sizes (768px+)

---

23-26: LGTM! Clean simplification of resize handler.

The resize handler now only manages the nav's open state without coupling to banner height calculations. This is a good simplification that maintains the expected behavior of closing the mobile nav on resize.

---

7-7: No changes needed. The import statement at line 7 shows only Button from '$lib/components/ui'. Git history and codebase searches confirm that InlineTag and Icon were never imported in this file.

Likely an incorrect or invalid review comment.

src/routes/(marketing)/(components)/teaser/teaser-banner.svelte (2)

125-125: Verify the non-linear font-size progression is intentional.

The introducing text font-size follows an unusual pattern across breakpoints:

• <375px: 18px
• 375px-639px: 20px
• 640px-767px: 18px (decreased)
• 768px+: 20px

The decrease at 640px breakpoint creates a non-linear progression (18→20→18→20), which is atypical for responsive design. Typically, font sizes scale monotonically or remain constant as viewports grow.

Confirm this stepped pattern aligns with your design specifications. If the goal is optimal readability at different viewport sizes, consider whether this complexity is necessary or if a simpler progression would suffice.

Also applies to: 137-141

---

158-158: Similar non-linear progression observed for right text sizing.

The right text sizing follows the same non-linear pattern as the introducing text:

• <375px: 14px / 20px line-height
• 375px-639px: 16px / 22px
• 640px-767px: 15px / 20px (unique intermediate size)
• 768px+: 16px / 22px

The 640px breakpoint introduces a unique intermediate size (15px) that doesn't appear elsewhere, adding complexity to the responsive behavior. This pattern should align with the overall design system and be intentional rather than accidental.

Also applies to: 160-160, 165-170