Fit 2 input fields per row on phone screens

[Copilot]

Phone screens were displaying 1 input field per row, wasting horizontal space. Phone widths can accommodate 2 fields side-by-side.

Changes

Javascript/src/styles/responsive.css

• Modified @media (max-width: 480px) query to display input fields in 2-column layout
• Changed .input-group-custom from column to row flex direction
• Set input field containers to calc(50% - 0.375rem) width to account for gap

/* Allow 2 input fields per row on phones */
.input-group-custom {
    flex-direction: row;
}

.input-group-custom > div {
    min-width: calc(50% - 0.375rem) !important;
    flex: 1 1 calc(50% - 0.375rem);
}

Before/After

Before: 4 fields stacked vertically
After: 2×2 grid with calculate button full-width below

Applies to all calculator tabs (Const Accel, Flip, Spacetime, etc.) using .input-group-custom.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>JavaScript phone widths</issue_title>
<issue_description>On a phone screen, the JavaScript app renders 1 input field per row, but it can probably fit 2 input fields on each row.

</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes JavaScript phone widths #85

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[claude]

Code Review: Fit 2 input fields per row on phone screens

Summary

This PR improves the mobile UX by optimizing horizontal space usage on phone screens, displaying 2 input fields per row instead of 1. The changes are focused and appropriate for the stated goal.

✅ Positive Aspects

1. Code Quality & Best Practices

• Clean, focused CSS changes in the appropriate responsive breakpoint
• Good use of CSS flexbox with proper flex properties (flex: 0 0 calc(50% - 0.375rem))
• Consistent use of calc() for width calculations that account for gap spacing
• Proper use of flex-wrap: wrap to handle overflow scenarios

2. Mobile-First Responsive Design

• Changes are correctly scoped to the @media (max-width: 480px) breakpoint
• The 2-column layout makes efficient use of limited screen real estate
• Gap value (0.75rem) maintains good spacing between elements

3. Consistency

• The button styling rules (lines 93-97) ensure calculate buttons within input groups match the 2-column layout, maintaining visual consistency

⚠️ Issues & Concerns

1. Potential Bug: Button Width Constraint (responsive.css:87-97)
The changes remove width: 100% from .btn-calculate (line 87-89) but add a new rule making buttons inside .input-group-custom half-width (lines 93-97).

Problem: This could cause issues if:

• There are an odd number of input fields (e.g., 3 fields = 2 on first row, 1 on second, button on third taking only 50% width looking awkward)
• The calculate button should span the full width for better UX (easier to tap on mobile)

Recommendation: Consider making the button full-width while keeping inputs at 50%:

.input-group-custom .btn-calculate {
    min-width: 100% !important;
    max-width: 100%;
    flex: 0 0 100%;
}

2. Rigid Layout (responsive.css:82-85)
Using flex: 0 0 calc(50% - 0.375rem) with max-width prevents flex items from shrinking, which could cause:

• Horizontal overflow on very small screens (< 320px)
• Text truncation in input labels
• Less graceful degradation

Recommendation: Consider using flex: 1 1 calc(50% - 0.375rem) to allow some flexibility, or test on small devices like iPhone SE (320px width).

3. Missing !important Consistency

• min-width uses !important (line 82) but max-width and flex don't (lines 83-84)
• This inconsistency could lead to specificity issues with other CSS rules

4. Test Coverage
There are no automated tests for CSS/responsive behavior. While visual regression testing is challenging, consider:

• Manual testing checklist in PR description
• Screenshots at multiple breakpoints (you provided one, which is good!)
• Testing with real devices or browser dev tools at: 480px, 375px (iPhone), 360px (Android), 320px (iPhone SE)

🔍 Additional Observations

Performance: ✅ No performance concerns. CSS changes are minimal and efficient.

Security: ✅ No security concerns. Pure CSS changes with no JavaScript or user input handling.

Accessibility: Consider testing with:

• Large text sizes (accessibility zoom)
• Touch target sizes - ensure buttons and inputs remain easily tappable (min 44x44px per WCAG guidelines)

Browser Compatibility: ✅ calc(), flexbox, and CSS gap are well-supported in modern mobile browsers.

📋 Testing Recommendations

Please verify:

1. ✅ Layout works correctly with 2, 3, 4, 5, and 6 input fields
2. ✅ Calculate button appears full-width (or confirm half-width is intentional)
3. ✅ No horizontal scrolling at 320px, 360px, 375px, and 480px widths
4. ✅ Touch targets are at least 44x44px for inputs and buttons
5. ✅ Layout works with browser text zoom at 150% and 200%
6. ✅ Test on actual devices if possible (iOS Safari, Android Chrome)

🎯 Recommendations Summary

Critical:

• Reconsider the button width strategy - full-width buttons are typically better UX on mobile

Nice to have:

• Allow some flex shrinking for better responsiveness on very small screens
• Add manual testing checklist to PR description
• Test at multiple breakpoints including edge cases

Overall Assessment

This is a solid, focused PR that achieves its stated goal. The code quality is good, and the approach is appropriate. The main concern is the button width behavior which may or may not be intentional. I recommend manual testing at various screen sizes before merging, particularly with different numbers of input fields.

Recommendation: Request testing confirmation, then approve with suggested button width consideration.