HTML Forms

Responsive made the page fit many screens. Forms open a new chapter: visitors type and submit information — search, signup, contact, checkout. The container is the form element. Later lessons deepen attributes and input types; this session locks the skeleton.

Why forms matter

Static pages show content. Forms collect it. Without a form wrapper, browsers do not know which controls belong to one submission. Think “one form = one send action,” then place fields inside that boundary.

Direct answer

1) Wrap controls in <form action="URL" method="get|post">.
2) Add controls (input, textarea, button, …) with a name so each value has a key.
3) Pair every visible field with a <label for="…"> that matches the control’s id.
4) Provide a submit control (button type="submit" or input type="submit").
action is where data goes; method is how it is sent. Backends come later — correct markup first.

Minimal form skeleton

Start with the container and the two attributes you will see on almost every real form. Empty action or a practice path is OK while you learn structure.

Reading the skeleton

• form is the submission boundary — not a visual box by itself
• action="/subscribe" points at a path the browser will request on submit
• method="post" sends field data in the request body (beginner-level idea)
• method="get" appends data to the URL — useful for search boxes, less ideal for passwords
• Comments inside are fine; real pages replace them with controls
• Without a live server, submit may 404 — that still teaches markup

Labeled field plus submit

A useful first form needs at least one field users can fill and a way to send it. Match label for to input id, and give the input a name.

Reading the subscribe demo

• for="email" and id="email" connect the label to the control
• name="email" keys the value in the submitted payload
• type="email" hints browsers and mobile keyboards (deeper types come later)
• button type="submit" sends the form; other button types can confuse beginners
• Keep the button inside the same form as the fields

GET vs POST (first pass)

Use get when the result should be bookmarkable or shareable (classic search). Use post when sending data that should not sit in the address bar (signup, messages). Form attributes lessons go deeper; pick post for most practice contact-style forms.

Practice — build a tiny subscribe form

1. Create a form with method="post" and a practice action path.
2. Add a labeled email input with matching id / for and a name.
3. Add a button type="submit".
4. Open the page and confirm the label, field, and button render.
5. Temporarily move the input outside the form and note it no longer participates in that submit group.
6. Put it back inside; confirm name is still set.
7. Write one sentence: form + action/method + named labeled controls = a sendable form.
8. Optional: try method="get" once and watch the query string after submit (if a handler exists).

Easy mistakes

• Putting inputs outside the form when you meant one submission group
• Missing name so the field has no key in submitted data
• Buttons without type="submit" when other types steal the click
• Skipping label / mismatched for and id
• Confusing action (where) with method (how)
• Expecting a real backend from a static practice page — structure first, servers later

Summary

• form wraps controls for one send action
• action + method describe the submission target and style
• Labels, id/for, and name make fields usable and sendable
• Submit with an explicit submit control
• Deeper attributes and input types come in the next sessions
• Next: form attributes — refining how forms behave