HTML receipt review form project: one native flow with clear server boundaries

Use it for a real task

The reviewer selects approve or hold and may leave a short note. The receipt ID is shown in the heading and carried as a hidden request value. Every submitted value remains untrusted: the server must resolve the record, authorize this reviewer, reject stale state, and protect the POST action against request forgery.

<main>
  <h1>Review receipt R-47</h1>
  <form action="/receipts/review" method="post">
    <input type="hidden" name="receipt_id" value="R-47">
    <fieldset>
      <legend>Decision</legend>
      <label><input type="radio" name="decision" value="approve" required> Approve</label>
      <label><input type="radio" name="decision" value="hold"> Hold</label>
    </fieldset>
    <label for="review-note">Reason</label>
    <textarea id="review-note" name="reason" maxlength="240"></textarea>
    <button type="submit">Save decision</button>
  </form>
</main>

What the markup guarantees

This is a front-end document, not a running approval service. A full implementation also needs a server endpoint, data persistence, an error response, and tests for repeated submission and changed receipt status.

Cost and limits

The static HTML is small and works without a client bundle. The service side owns the expensive part: validation, transaction isolation, audit history, and failure recovery.

Common Mistakes

• Do not trust the hidden receipt ID as authorization.
• Do not leave a required decision without a group legend.
• A successful native submission still needs a confirmation or error page.

Connected lessons

• HTML forms: choose GET for retrieval and POST for a state change
• HTML radio and checkbox controls: submit choices with explicit values
• HTML labels: bind each control to a durable accessible name
• HTML constraint validation: improve feedback without trusting the browser