fix(footer): Make footer responsive (closes #793) #796
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.
Implemented Comprehensive Mobile Responsiveness for Footer (Closes #793)
This PR addresses and completely resolves Issue #793 by making the application's footer fully responsive across all major device widths.
The goal was to ensure a clean, legible, and correctly spaced footer layout, adapting gracefully from large desktops down to small mobile screens.
Key Changes & Accomplishments:
Comprehensive Media Queries (in Footer.css): I implemented a series of nested media queries to provide a progressive and optimized layout experience across four major breakpoints. This isn't just a basic stack—it's a truly adaptive design:
Laptops (max-width: 1024px): Adjusted the main padding and column gaps for a tighter, yet comfortable layout.
Tablets (max-width: 768px): Significantly reorganized and reduced sizes for logos, social icons, and text to prevent clutter on horizontal tablet views.
Mobiles (max-width: 480px): Finalized the layout for optimal viewing on vertical phones, including minimizing padding, spacing, and font sizes to maximize readability.
Server/Routing Configuration Fix: While testing the build process, I noticed an issue where the client-side routes failed to load when serving the production build (a common issue with SPAs). This was fixed by adding historyApiFallback: true to vite.config.js, which ensures proper client-side routing and successful deployment of the site.
Production Readiness Confirmed: The application now successfully builds and serves locally without any 404/server errors, confirming that the footer and surrounding build environment are stable.
This fix significantly improves the user experience for anyone browsing the site on a non-desktop device.