UX: add horizontal gap between form labels and inputs (Account Settings, auth forms)

[schlajo]

Problem

On Account Settings (and similar auth forms), field labels sit flush against — or overlap — their input boxes horizontally. There is no readable gap between the end of the label text and the start of the fill-in control.

Observed on RescueDogs fork (same template components):

• Profile Settings — Display Name, Bio: label text runs into the input/textarea border
• Change Password — New Password, Confirm Password: same tight horizontal squeeze; longer labels (Confirm Password) shift the input column inconsistently

This is a horizontal spacing issue (label ↔ input), not vertical spacing between rows.

Expected

A consistent horizontal gap between each label and its control — e.g. gap-x-4 / gap-x-6 — so labels and inputs are visually distinct and scannable.

On narrow viewports, prefer stacking label above input (flex-col) and switch to side-by-side with gap at sm+ per docs/MOBILE-FIRST.md (flex flex-col sm:flex-row).

Likely touch points

• src/components/auth/AccountSettings/AccountSettings.tsx — Profile Settings + Change Password cards
• Audit sibling auth forms for the same pattern:
  • src/components/auth/SignInForm/SignInForm.tsx
  • src/components/auth/SignUpForm/SignUpForm.tsx

Suggested approach

Replace cramped side-by-side form-control rows with an explicit row layout, e.g.:

<div className="flex flex-col gap-2 sm:flex-row sm:items-center sm:gap-x-6">
  <label className="sm:w-36 sm:shrink-0 sm:text-right" htmlFor="…">
    <span className="label-text">Display Name</span>
  </label>
  <input className="input input-bordered min-h-11 min-w-0 flex-1" … />
</div>

Use a shared label-column width across fields on the same form so inputs align.

Acceptance criteria

• Profile Settings: visible horizontal gap between each label and its input/textarea at desktop widths
• Change Password: same for New Password and Confirm Password
• Mobile: labels stack above inputs (no crushed ~120px-wide inputs on portrait phones)
• No overlap of label text and input borders at 320–1280px viewports
• Storybook / existing unit tests updated if layout assertions exist

Context

Filed from RescueDogs fork testing while reviewing account settings UI. Happy to attach screenshots in a follow-up comment if helpful.

[TortoiseWolfe]

Audit: this is fork-scoped — ScriptHammer's template forms are already correct

Investigated against the current ScriptHammer code (4-reader audit of every auth form). The horizontal label/input cram described here does not exist in the template. Every text field stacks its label ABOVE the input as a block — there is no side-by-side flex-row that could cram them.

Evidence (all three named files):

• AccountSettings.tsx (Display Name, Bio, New Password, Confirm Password): each field is a plain block <div> → block-level <label className="label"> → control on its own line. No flex-row, grid-cols-*, gap-x-*, or float.
• SignInForm.tsx (Email, Password): identical block-stacked pattern. Only same-line pair is the Remember-Me checkbox, which already has gap-3.
• SignUpForm.tsx (Email, Password, Confirm Password): identical. Checkbox has gap-2.

Not a recent regression: the three form files were last touched by the DaisyUI v4→v5 class-rename (#151, 260ee29) — a class migration, not a relayout. The stacked structure predates this issue and is unchanged.

Root cause: the issue itself notes it was "Observed on RescueDogs fork" / "Filed from RescueDogs fork testing", and no screenshots were attached (only an offer to). The cramped side-by-side layout is a fork divergence, not template debt.

Per the fork-bug-transfer rule, transferring this to TortoiseWolfe/RescueDogs where the affected layout actually lives. If a template case does surface later (with a screenshot at 320–1280px showing label↔input overlap in unmodified ScriptHammer forms), re-open here.

[TortoiseWolfe]

Reopening the question — screenshots needed before any disposition

Correcting my earlier call: I transferred this to the fork on the strength of a code audit alone, which was premature. Bringing it back and keeping it open pending confirmation.

What the code audit found (still useful as a baseline): ScriptHammer's AccountSettings, SignInForm, and SignUpForm currently stack each label above its input as a block — no side-by-side flex-row — so I couldn't reproduce a horizontal label↔input cram in the unmodified template. The layout hasn't changed structurally since the DaisyUI v5 class rename (#151).

But that doesn't close it. The report was filed from real UI testing, and the offered screenshots would show exactly what I can't see from the markup — rendered overlap, a wrapping long label, or a viewport-specific squeeze.

@TortoiseWolfe — could you attach the screenshots you mentioned? Specifically:

• Profile Settings (Display Name / Bio) and Change Password (New / Confirm Password)
• At the viewport where it looks worst (a portrait-phone width ~320–390px is most useful)
• Note whether this is on ScriptHammer itself or the RescueDogs fork

Once I can see the rendered problem I'll fix it in the right repo. Leaving open until then.

[TortoiseWolfe]

@schlajo — verification prompt (Cursor)

Assigning this to you. The code audit says ScriptHammer's forms already stack labels above inputs (no cram) and this is a RescueDogs-fork issue — but we need rendered screenshots to be sure. Full runbook: docs/verification/schlajo-tickets.md.

Manual (the real signal): sign in as the test user → Account Settings (Profile Settings + Change Password), Sign In, Sign Up. Screenshot each at 320 / 768 / 1280px. Look for label text touching/overlapping the input border. Attach here and say whether it reproduces on ScriptHammer or only the fork.

Paste into Cursor (Agent mode):

You are verifying GitHub issue TortoiseWolfe/ScriptHammer#212 (horizontal label/input gap on auth forms). Claim: ScriptHammer forms already stack labels ABOVE inputs (no cram); the defect is fork-only. Confirm or refute against the code. Do NOT change code yet.

1. Read these files; for every label+input pair quote the className on the wrapper div, <label>, and <input>, and classify:
   - src/components/auth/AccountSettings/AccountSettings.tsx (Display Name, Bio, New/Confirm Password)
   - src/components/auth/SignInForm/SignInForm.tsx (Email, Password)
   - src/components/auth/SignUpForm/SignUpForm.tsx (Email, Password, Confirm Password)
   Classify each as "label-above-input" (plain block div, label on its own line, no flex-row → no cram) or "side-by-side-flex-row" (same line → check for gap-x-*; if absent that's the cram).

2. If ALL fields are label-above-input, report that the #212 premise does NOT reproduce here, with evidence.

3. Note that a human screenshot pass at 320/768/1280px is still required (see docs/verification/schlajo-tickets.md).

4. ONLY if you find a real cram (side-by-side, no gap): propose the minimal fix (flex flex-col gap-2 sm:flex-row sm:items-center sm:gap-x-6 + shared sm:w-36 label column) but do NOT apply without confirmation.

Post your verdict + screenshot-requirement note as a comment here.

Close criteria: code audit + screenshots at 3 widths for all 3 forms + a clear "reproduces on ScriptHammer / fork-only" verdict. If fork-only → transfer to RescueDogs; if it reproduces here → fix.

[schlajo]

These are screenshots of there being no gap between to the labels and their fill-in boxes.

The top 2 here are from HeldPaws.com, which was built with Scripthammer:

This one is from Scripthammer itself:

[schlajo]

Options so we can proceed — pick one:

1. Fork the repo to your account (recommended)

On GitHub: open https://github.com/TortoiseWolfe/ScriptHammer and click "Fork".
Or with GitHub CLI: gh repo fork TortoiseWolfe/ScriptHammer --clone=false --remote=false
Tell me the fork repo name (likely schlajo/ScriptHammer). Once your fork exists I will create branch fix/ux-label-input-gap in your fork and open a PR to the upstream repo.

2. I produce a patch/PR payload here (diff + the exact git commands) and you apply it locally

I will generate the code changes (for the three files referenced in the issue) and provide:
the unified diff or file contents to replace,
the exact git commands to apply and push (create branch, commit, push, open PR).
This is good if you prefer to run changes inside your Docker container locally.

3. Grant me push access to the upstream repo (less common)

If you give me collaborator permission on TortoiseWolfe/ScriptHammer I can create the branch directly there and open the PR.

What I will change (high level)

Replace cramped label/input markup with a responsive row pattern:
Wrap each label+control in:

… <input className="input input-bordered min-h-11 min-w-0 flex-1" … />

Stack on mobile, side-by-side with a fixed label column and gap at sm+.
Apply to AccountSettings (Display Name, Bio, New Password, Confirm Password) and to SignInForm and SignUpForm fields (Email, Password, Confirm Password). Keep checkboxes and inline hints as-is but ensure they don't cause overlap.

If you want me to proceed now, reply with one of:

"Fork created: schlajo/ScriptHammer — proceed" (I will create branch in your fork and open PR), or
"Produce patch" (I will prepare the patch + git commands for you to apply), or
"I'll add collaborator" (then grant push access and confirm and I'll retry).
Which option do you want?

If you fork it for me to have my own, then can you still push a change upstream, at least for him to choose to accept it and merge it?

Yes — absolutely. The normal workflow is:

You fork the repo to your account (creates schlajo/ScriptHammer).
I create a branch on your fork (fix/ux-label-input-gap), make the edits there, and push the branch to your fork.
I then open a Pull Request from your fork/branch into the upstream repo (TortoiseWolfe/ScriptHammer). The upstream repo owner can review, request changes, and merge if they accept it.

Notes and details

The PR will show the diff and let the upstream maintainer run CI and review before merging. They do not need to give me direct access to their repo.
I will target the upstream repository's default branch (I will detect it when creating the PR).
Branch name, PR title, and description are up to you (I can use the branch name you suggested and include the issue number and a short summary).
I can also include Storybook / test updates and screenshots in the PR if you want.
If the fork doesn't exist yet, I can't create it on your behalf without your GitHub auth — you can fork via the GitHub UI (click Fork on the repo) or with gh: gh repo fork TortoiseWolfe/ScriptHammer --clone=false --remote=false.
Once your fork exists, tell me the fork NWO (likely schlajo/ScriptHammer) or confirm you've forked, and I'll create the branch, apply the changes, and open the PR.

If you prefer not to fork, I can instead produce a patch + exact git commands for you to apply locally. Which would you like me to do now?

I can do the work, but I need your fork of the repo so I can push a branch there and open a PR against TortoiseWolfe/ScriptHammer. Please create a fork (GitHub UI or gh CLI) and tell me the fork NWO (likely schlajo/ScriptHammer). Once the fork exists I'll:

create branch fix/ux-label-input-gap on your fork,
apply the edits,
push the branch and open a PR to TortoiseWolfe/ScriptHammer with the changes and a summary referencing issue #212.
If you want to fork now, you can:

Click Fork on this page: https://github.com/TortoiseWolfe/ScriptHammer
Or run (if you have gh): gh repo fork TortoiseWolfe/ScriptHammer --clone=false --remote=false
After you confirm the fork exists (reply "Fork created: schlajo/ScriptHammer" or similar), I'll push the branch and open the PR.

While you fork, here are the changes I will make (preview). I kept logic and imports unchanged and only updated the markup for each label+control to use a responsive layout: stack on mobile, side-by-side at sm+ with a fixed label column (sm:w-36), an sm:gap-x-6 horizontal gap, and inputs constrained with min-w-0/flex-1 so they don't get crushed.

tsx name=src/components/auth/AccountSettings/AccountSettings.tsx url=https://github.com/TortoiseWolfe/ScriptHammer/blob/c2f46976d512021fbb5c224920b209c0e17a9c43/src/components/auth/AccountSettings/AccountSettings.tsx