Fix mobile compatibility: viewport meta, hide TOC on small screens, r…#5
Conversation
…emove dead newsletter CSS - Update viewport meta tag to include initial-scale=1, viewport-fit=cover for proper mobile scaling - Add media query to hide TOC elements on screens below 1200px width - Remove 62 lines of unused newsletter CSS (Revue integration legacy code) code written with the help of Claude code
WalkthroughYou know what's cool about this? The entire pull request is focused on making your site actually work on mobile devices. We're talking viewport configuration tweaks, responsive typography across multiple breakpoints, improved touch targets for navigation, and mobile-first CSS media queries that consolidate layout adjustments across the board. Pretty straightforward stuff—no behavioral changes, just smart viewport and styling work. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes These are consistent, repetitive responsive design adjustments following predictable patterns across multiple files—mobile-first breakpoints with predictable tweaks to spacing, typography, and touch targets. Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (1)
src/content/posts/gatsby-to-astro-with-claude-code.md (1)
60-89: Consider using proper heading tags for better document structureYou're using bold text for the "Wave" sections (lines 60, 64, 73, 77, 85, 89), but these would be more semantic and accessible as
###headings. This helps with:
- Document outline and navigation
- Screen reader accessibility
- Automatic table of contents generation
Also, on line 18: "react" should be capitalized as "React" since it's a proper noun (the framework name).
🔎 Suggested improvements
-**Wave 1: Core Migration** +### Wave 1: Core Migration Converting layouts, components, and pages from React/JSX to Astro's `.astro` format... -**Wave 2: Dead Code Cleanup** +### Wave 2: Dead Code Cleanup I gave Claude Code a cleanup plan thanks to Traycer: -**Wave 3: Bug Fixes** +### Wave 3: Bug Fixes While the migration was one-shotted by Opus 4.5... -**Wave 4: Asset Cleanup** +### Wave 4: Asset Cleanup More cruft removal: -**Wave 5: Lighthouse Optimization** +### Wave 5: Lighthouse Optimization I shared a Lighthouse report PDF... -**Wave 6: Final Polish** +### Wave 6: Final Polish Navbar styling tweaks, updating my contact email...And for the React capitalization:
-I was a fan of Hugo and always wanted to try a react framework for building personal site +I was a fan of Hugo and always wanted to try a React framework for building personal site
📜 Review details
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
⛔ Files ignored due to path filters (2)
public/images/post-images/gatsby-to-astro-with-claude-code/claude-code-mobile.pngis excluded by!**/*.pngpublic/images/post-images/gatsby-to-astro-with-claude-code/dead-code-traycer.pngis excluded by!**/*.png
📒 Files selected for processing (3)
src/content/posts/gatsby-to-astro-with-claude-code.mdsrc/layouts/BaseLayout.astrosrc/style.css
🧰 Additional context used
🪛 LanguageTool
src/content/posts/gatsby-to-astro-with-claude-code.md
[uncategorized] ~18-~18: “React” is a proper noun and needs to be capitalized.
Context: ... fan of Hugo and always wanted to try a react framework for building personal site, G...
(A_GOOGLE)
[style] ~36-~36: ‘none at all’ might be wordy. Consider a shorter alternative.
Context: ...by default, support any UI framework or none at all, and treat content as a first-class con...
(EN_WORDINESS_PREMIUM_NONE_AT_ALL)
[style] ~44-~44: To elevate your writing, try using a synonym here.
Context: ... I still dragged my feet because it was hard to prioritise against work. Claude code...
(HARD_TO)
[style] ~87-~87: Consider using a different verb for a more formal wording.
Context: ...use report PDF and asked Claude Code to fix the issues. It improved color contrast ...
(FIX_RESOLVE)
[style] ~95-~95: In formal / written English, it is recommended that you use a subject pronoun.
Context: ... work. Not because they're smarter than me at any individual task, but because the...
(THAN_I)
🪛 markdownlint-cli2 (0.18.1)
src/content/posts/gatsby-to-astro-with-claude-code.md
60-60: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
64-64: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
73-73: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
77-77: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
85-85: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
89-89: Emphasis used instead of a heading
(MD036, no-emphasis-as-heading)
🔇 Additional comments (1)
src/style.css (1)
1395-1400: Smart responsive TOC handling! 👍Hiding the table of contents at 1200px makes perfect sense given your fixed positioning calculation (
left: calc(50% + 400px)). On narrower viewports, the TOC would either overflow or create horizontal scroll issues, sodisplay: noneis the right call here.The media query syntax is clean and the breakpoint aligns well with your layout math.
| I still dragged my feet because it was hard to prioritise against work. Claude code Desktop was the final nudge. In Oct 2025, I tried Blog migration as a test session, and damn, it worked out well. Claude code from mobile one-shotted the entire migration. All I need to do is make sure bugs are fixed. | ||
|
|
||
| //claude code todo - import this image well. | ||
| public/images/post-images/gatsby-to-astro-with-claude-code/claude-code-mobile.png |
There was a problem hiding this comment.
Fix the date and complete the image TODOs before publishing
Hey friend! A couple of things to clean up:
- Line 44: "In Oct 2025" should probably be "In Oct 2024" - unless you've got a time machine I don't know about! 😄
- Lines 46-47: There's a TODO comment about importing the Claude Code mobile image that still needs to be addressed.
These TODOs will show up in your published post if not resolved.
Want me to help you generate the proper Markdown image syntax for these images?
🔎 Suggested fix for the date
-I still dragged my feet because it was hard to prioritise against work. Claude code Desktop was the final nudge. In Oct 2025, I tried Blog migration as a test session, and damn, it worked out well. Claude code from mobile one-shotted the entire migration. All I need to do is make sure bugs are fixed.
+I still dragged my feet because it was hard to prioritise against work. Claude code Desktop was the final nudge. In Oct 2024, I tried Blog migration as a test session, and damn, it worked out well. Claude code from mobile one-shotted the entire migration. All I need to do is make sure bugs are fixed.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| I still dragged my feet because it was hard to prioritise against work. Claude code Desktop was the final nudge. In Oct 2025, I tried Blog migration as a test session, and damn, it worked out well. Claude code from mobile one-shotted the entire migration. All I need to do is make sure bugs are fixed. | |
| //claude code todo - import this image well. | |
| public/images/post-images/gatsby-to-astro-with-claude-code/claude-code-mobile.png | |
| I still dragged my feet because it was hard to prioritise against work. Claude code Desktop was the final nudge. In Oct 2024, I tried Blog migration as a test session, and damn, it worked out well. Claude code from mobile one-shotted the entire migration. All I need to do is make sure bugs are fixed. | |
| //claude code todo - import this image well. | |
| public/images/post-images/gatsby-to-astro-with-claude-code/claude-code-mobile.png |
🧰 Tools
🪛 LanguageTool
[style] ~44-~44: To elevate your writing, try using a synonym here.
Context: ... I still dragged my feet because it was hard to prioritise against work. Claude code...
(HARD_TO)
| //claude code todo - import this image well. | ||
| public/images/post-images/gatsby-to-astro-with-claude-code/dead-code-traycer.png |
There was a problem hiding this comment.
Second image TODO needs completion
Another image that needs proper Markdown formatting before this post goes live.
Replace the TODO with proper Markdown image syntax:
🤖 Prompt for AI Agents
In src/content/posts/gatsby-to-astro-with-claude-code.md around lines 68 to 69,
replace the plain text TODO reference to the image file with proper Markdown
image syntax: add an image tag that points to
/images/post-images/gatsby-to-astro-with-claude-code/dead-code-traycer.png and
use a descriptive alt text such as "Dead code cleanup plan in Traycer" so the
image renders correctly in the post.
| <head> | ||
| <meta charset="UTF-8" /> | ||
| <meta name="viewport" content="width=device-width" /> | ||
| <meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover" /> |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
viewport meta tag syntax initial-scale viewport-fit cover MDN best practices
💡 Result:
Short summary + MDN best practices:
-
Syntax (canonical example):
Use a comma/space/semicolon-delimited list of key=value tokens (browsers accept commas, spaces, semicolons). [1][2] -
Common properties:
- width (e.g. device-width) — sets layout viewport width. [1]
- initial-scale — initial zoom level (1 = no zoom). [1]
- minimum-scale / maximum-scale / user-scalable — control zoom behavior (avoid disabling zoom for accessibility). [1]
- viewport-fit — auto | contain | cover (use cover to allow content into display cutout area; pair with safe-area insets). [2]
-
viewport-fit=cover best practice:
- When using viewport-fit=cover, apply CSS padding/margins using the safe-area inset environment variables so important UI doesn’t sit under notches/rounded corners:
padding-top: env(safe-area-inset-top);
padding-left: env(safe-area-inset-left);
padding-right: env(safe-area-inset-right);
padding-bottom: env(safe-area-inset-bottom);
This ensures content remains visible on devices with display cutouts. [2]
- When using viewport-fit=cover, apply CSS padding/margins using the safe-area inset environment variables so important UI doesn’t sit under notches/rounded corners:
-
Accessibility & responsiveness rules of thumb:
- Include the viewport meta on mobile-first responsive sites: content="width=device-width, initial-scale=1". [1]
- Do not set a fixed pixel width unless necessary; prefer device-width or responsive CSS. [1]
- Avoid preventing user zoom (user-scalable=no or maximum-scale=1) because it harms accessibility. [1]
Sources:
[1] MDN — Using the viewport meta tag / Viewport meta element. (devdoc.net).
Citations:
Solid mobile viewport setup! 🎉 The initial-scale=1 and viewport-fit=cover combo is definitely the way to go for modern mobile experiences.
Here's the thing though—when you use viewport-fit=cover, you gotta pair it with the CSS safe-area insets to keep your content out of those notches. Otherwise, important UI can get hidden under the display cutout. Just add something like:
padding-top: env(safe-area-inset-top);
padding-left: env(safe-area-inset-left);
padding-right: env(safe-area-inset-right);
padding-bottom: env(safe-area-inset-bottom);This way, you get the best of both worlds—your content extends into the safe area where it makes sense, but critical UI stays visible. Good practice to implement this wherever you're using viewport-fit=cover. Let me know how that goes!
🤖 Prompt for AI Agents
In src/layouts/BaseLayout.astro around line 23, the meta tag uses
viewport-fit=cover but there is no CSS to account for device safe-area insets,
which can let content be hidden under notches; add CSS on the top-level
layout/container (and any fixed headers/footers) that applies padding-top,
padding-right, padding-bottom, and padding-left using env(safe-area-inset-top),
env(safe-area-inset-right), env(safe-area-inset-bottom), and
env(safe-area-inset-left) respectively (with sensible fallbacks if desired), so
UI is pushed inside safe areas when present.
- Add mobile typography scaling at 600px, 480px, 360px breakpoints - Progressive container padding reduction for smaller screens - Navbar touch targets meet 44x44px accessibility guideline - Optimize homepage, blog, and about pages for mobile viewports - Add lead section and section spacing mobile adjustments code written with the help of Claude code
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
src/pages/about.astro (1)
160-169: Consider consolidating the timeline breakpoint.You've got a 500px breakpoint here for timeline flex-direction changes, and then new 600px/480px breakpoints below. While they target different properties and won't conflict functionally, having three closely-spaced breakpoints (500px, 600px, 480px) could make maintenance trickier. Consider whether the timeline flex-direction change could move to the 600px breakpoint for consistency with the rest of the mobile-first approach.
src/style.css (1)
156-178: Container padding progression is well-thought-out.The four breakpoints (800px, 600px, 480px, 360px) provide granular control over spacing. While you could potentially consolidate to three breakpoints, the current implementation ensures comfortable padding across the full spectrum of device sizes.
📜 Review details
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (5)
src/components/astro/Nav.astrosrc/pages/about.astrosrc/pages/blog.astrosrc/pages/index.astrosrc/style.css
🔇 Additional comments (9)
src/pages/index.astro (1)
116-147: Excellent mobile responsive implementation! 🎉The progressive font size and padding adjustments at the 600px and 480px breakpoints are well-structured and follow a logical scaling pattern. The media query order is correct, and the specificity ensures proper cascade behavior.
src/pages/about.astro (1)
171-194: Sweet mobile optimizations! 🚀The responsive adjustments follow the same pattern as the index page—progressive padding reduction and sensible spacing tweaks. The year min-width adjustment keeps the timeline readable on smaller screens.
src/pages/blog.astro (1)
127-158: Solid responsive styling here! 💯The progressive typography scaling and spacing adjustments create a smooth mobile experience. The post-date min-width reduction ensures the layout doesn't get cramped on smaller screens while maintaining visual hierarchy.
src/components/astro/Nav.astro (1)
98-128: Fantastic accessibility work with those touch targets! 🎯The 44×44px minimum dimensions for navigation links and the dark mode button perfectly align with WCAG 2.1 Level AA guidelines for touch target size. The progressive gap reduction prevents layout overflow on smaller screens while maintaining usability. This is exactly the kind of inclusive design we want to see!
src/style.css (5)
124-143: Nice progressive section spacing!The mobile section margin reductions create tighter, more appropriate spacing for smaller screens while maintaining visual rhythm. The heading size adjustments keep content readable without dominating the viewport.
379-429: Excellent mobile typography hierarchy! 📝The progressive font size reductions across three breakpoints maintain readability while optimizing for smaller viewports. The h1 scaling from 2.5rem down to 1.6rem is particularly well-calibrated—enough reduction to fit comfortably without becoming cramped.
642-674: Lead section mobile adjustments are on point! 👌The hero section scales nicely for mobile—reducing the image from 150px to 120px prevents it from dominating small screens, and the progressive heading/text adjustments maintain hierarchy. The button padding tweak at 480px is a nice touch for preventing cramped tap targets.
800-828: Touch target sizing is perfect for accessibility! ✨These navbar adjustments mirror the component-level changes in Nav.astro and maintain the 44×44px minimum touch target size for WCAG compliance. The progressive padding reduction at 480px keeps the navbar from feeling too spacious while maintaining usability.
1550-1555: TOC hiding threshold is spot-on! 🎯The 1200px breakpoint for hiding the fixed-position TOC is well-calculated. Given the TOC positioning (
left: calc(50% + 400px)) and its 340px width, it would overflow on screens narrower than ~1340px, so hiding it at 1200px prevents any layout issues. Simple and effective.
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
src/style.css
🔇 Additional comments (5)
src/style.css (5)
124-143: Nice mobile spacing adjustments! 🎯Hey there! These progressive spacing reductions look great. You're following a solid mobile-first mindset by scaling down the margins and heading sizes appropriately. The values are reasonable and should improve readability on smaller screens.
156-178: Container padding scales nicely! 📱Awesome work scaling the container padding across all those breakpoints. This ensures your content won't be cramped against the edges on tiny screens. The progressive values (2rem → 1rem → 0.875rem → 0.75rem) are thoughtful.
379-429: Typography scaling FTW! 📝This is really well done! You're maintaining the typographic hierarchy while making everything readable on small screens. The progressive scaling of headings and body text shows you're thinking about the reading experience across devices.
592-624: Lead section mobile optimization looks great! 🎨These adjustments to your hero/lead section are spot on. Reducing the padding, typography, and image size progressively ensures your lead section doesn't overwhelm mobile users. Nice work maintaining proportion!
1376-1381: Smart move hiding the TOC on smaller screens! 📚This is the right call! Given that your TOC uses fixed positioning with
calc(50% + 400px), it would definitely break or overlap content on screens narrower than 1200px. Hiding it cleanly withdisplay: noneis a solid solution.If you wanted to get fancy in the future, you could consider adding a collapsible/toggleable TOC for tablet-sized screens, but for now, this keeps things simple and functional.
| /* Mobile navbar touch targets */ | ||
| @media screen and (max-width: 600px) { | ||
| .navbar a { | ||
| font-size: 0.85rem; | ||
| padding: 0.4rem; | ||
| min-height: 44px; | ||
| display: flex; | ||
| align-items: center; | ||
| } | ||
|
|
||
| .navbar button { | ||
| min-width: 44px; | ||
| min-height: 44px; | ||
| } | ||
| } | ||
|
|
||
| @media screen and (max-width: 480px) { | ||
| .navbar { | ||
| padding: 0.4rem; | ||
| } | ||
|
|
||
| .navbar a { | ||
| padding: 0.3rem; | ||
| font-size: 0.8rem; | ||
| } | ||
|
|
||
| .navbar a.brand { | ||
| font-size: 0.9rem; | ||
| } | ||
|
|
||
| .navbar button { | ||
| min-width: 40px; | ||
| min-height: 40px; | ||
| } | ||
| } | ||
|
|
||
| @media screen and (max-width: 375px) { | ||
| .navbar a { | ||
| padding: 0.25rem; | ||
| font-size: 0.75rem; | ||
| } | ||
|
|
||
| .navbar a.brand { | ||
| font-size: 0.85rem; | ||
| } | ||
|
|
||
| .navbar button { | ||
| min-width: 36px; | ||
| min-height: 36px; | ||
| font-size: 0.9rem; | ||
| } | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, let's check if the file exists and examine the specific lines
if [ -f "src/style.css" ]; then
wc -l src/style.css
echo "---"
sed -n '746,797p' src/style.css
else
echo "File not found at src/style.css"
# Try to find it
find . -name "style.css" -type f 2>/dev/null | head -20
fiRepository: aravindputrevu/aravind.dev
Length of output: 865
🌐 Web query:
WCAG 2.1 touch target size requirements Level AA vs Level AAA minimum pixel dimensions
💡 Result:
- Level AA (WCAG 2.2, SC 2.5.8): minimum 24 × 24 CSS pixels. [1][2]
- Level AAA (WCAG 2.1, SC 2.5.5): minimum 44 × 44 CSS pixels. [3][4]
Sources:
[1] W3C — WCAG 2.2 Success Criterion 2.5.8.
[2] wcag.com — 2.5.8 Target Size (Minimum) (Level AA).
[3] W3C / WCAG guidance — SC 2.5.5 Target Size (Enhanced).
[4] Deque University — 2.5.5 Target Size (AAA).
Touch targets progression looks solid, but let's chat about that 375px floor 👆
Alright, I love what you're doing here! The way you're thoughtfully stepping down touch target sizes as the viewport shrinks shows you're really thinking about accessibility. Starting with 44x44px at 600px is fantastic—that's hitting the WCAG 2.1 Level AAA target, which is the gold standard.
But here's the thing: at 375px, you're dropping to 36x36px. Now, that still clears the Level AA minimum of 24x24px, so you're not breaking accessibility standards. But it's below that AAA sweet spot of 44x44px, and folks with motor impairments or just bigger fingers might feel a little squeeze there.
The reality is that 375px (iPhone SE width) is tight, and sometimes you gotta make trade-offs. If this 36px floor is something you've intentionally decided on, that's totally reasonable! But if you haven't given it some thought yet, maybe explore whether you could bump that back up to 40px or even find ways to restructure the navbar earlier (think hamburger menu at wider breakpoints, or collapsing some items) so you can keep more breathing room for touch targets.
You might also wanna do some real-world testing with folks to see how it feels, or double-check against your project's accessibility requirements to make sure you're good.
1 participant
…emove dead newsletter CSS
code written with the help of Claude code
Summary by CodeRabbit
Release Notes
✏️ Tip: You can customize this high-level summary in your review settings.