HTML: Forms

A form is the part of a web page that collects information from the person using it and sends that information to a program running on a web server. Every time you search for a train on IRCTC, log in to a school portal, apply for an examination or pay a fee through UPI, you are filling in a form.

To follow where the data goes, recall the client-server model. The client is the browser on your computer or phone. The server is the computer that stores the website and answers requests for it. The two talk using HTTP (HyperText Transfer Protocol), the set of rules for transferring web pages, or its secure version HTTPS. The address you type, such as www.example.com/register.html, is a URL (Uniform Resource Locator) — the complete address of a resource on the web. A school website and IRCTC differ only in what they store; the mechanism is identical.

The journey of form data has four steps, and it is worth being able to state them in order:

1. The browser displays the page containing the form. The boxes, buttons and lists inside it are called controls (also called form elements).
2. The user types or selects values and clicks the submit button.
3. The browser gathers every named control into a set of name=value pairs and sends them to the address written in the form's action attribute.
4. A server-side script at that address — a program written in a language such as PHP or Python — reads the values, stores them in a database or file, and sends back a reply page such as Registration successful.

The single most important idea in this chapter is the name=value pair. The name attribute that you write in the HTML supplies the name; whatever the user typed or ticked supplies the value. If a student types Anjali into a box written as <input type="text" name="sname">, the browser sends sname=Anjali. Two or more pairs are joined by an ampersand:

sname=Anjali&cls=10&city=Delhi

Now the limitation you must be able to state. HTML only designs the form and sends the data. It cannot process anything. HTML has no way to add marks, compare a password with a stored one, or save a record. That work belongs to the server-side script. A form whose action points to nothing therefore collects data that is simply thrown away when the page is left. A safe one-line answer is: HTML is used only to design the form; the data entered is processed by a program on the server.

There is a small amount of checking the browser itself can do before it contacts the server — refusing to submit an empty box marked required, for example. This is called client-side validation. It is fast and saves a needless trip to the server, but how much of it happens depends on the browser and its version, and a determined user can get around it. Real websites therefore check the same data again on the server. For your paper, remember the pair of terms: client-side validation happens in the browser, server-side validation happens on the server, and serious sites do both.

Finally, note the difference between a form and a form control. The form is the container, written with the <form> tag. The controls are the individual items inside it — text boxes, radio buttons, checkboxes, drop-down lists, the submit button. Questions that ask you to name any four form controls want the controls, not the container.

Every control that is to be submitted must sit inside a <form> element. It is a container element: it has an opening tag <form> and a closing tag </form>, and everything between them belongs to that form. Its two attributes that CBSE tests are action and method.

<form action="register.php" method="post">
  <input type="text" name="sname">
  <input type="submit" value="Send">
</form>

action gives the URL of the program that will receive and process the data. It may be a full address such as action="https://www.example.com/register.php" or a relative one such as action="register.php" when the script sits in the same folder. If action is left out, browsers generally send the data back to the same page's address, which is rarely what a student intends — so always write it.

method states how the data travels. It takes one of two values, get or post. The value is not case sensitive, so method="GET" and method="get" behave the same. If method is omitted, GET is used, because get is the default value of the method attribute laid down in the HTML standard.

How GET sends data. The browser takes the name=value pairs, joins them with ampersands and attaches them to the URL after a question mark. The part after the question mark is called the query string:

search.php?city=Delhi&cls=10

Because the data is part of the address, it is visible in the address bar, it is stored in the browser's history, and the page can be bookmarked and reopened with the same values. The length of a URL is limited, so only a small amount of data can be sent this way. The exact limit is set by the browser and the server, not by HTML, so do not quote a number in your answer — write limited length.

How POST sends data. The pairs are placed inside the body of the HTTP request instead of in the address. Nothing appears in the address bar, the page cannot be usefully bookmarked, and the amount of data is not limited by the length of a URL, which is why file uploads always use POST. A server may still refuse an upload larger than a maximum size it has been configured with, so "no limit" means no limit imposed by the address.

When each is used. Use GET when the request only fetches or searches for something and repeating it does no harm — searching for trains between two stations, filtering a list of books in a school library catalogue. Use POST when the request changes something on the server or carries private data — creating an account, logging in, submitting an examination form, making a UPI payment, uploading a photograph.

One correction worth carrying into the exam: POST is not encrypted. It only keeps the values out of the address bar. Anything travelling over plain HTTP can be read on the way, whichever method is used. It is HTTPS that encrypts the data. So the correct sentence is POST is more private than GET because the data is not shown in the URL, not POST is secure.

A good difference-between answer gives at least four contrasted points: where the data is placed, whether it is visible in the address bar, how much data can be sent, and a typical use of each. Add bookmarking or history if a fifth point is wanted.

The <input> tag creates most of the controls on a form. It is an empty element — it has no closing tag, and nothing is written between tags because there is no second tag. Its type attribute decides which control appears; its name attribute decides the label under which the data is sent. If type is left out, browsers generally treat the control as a text box, but you should always write it.

These are the type values in the syllabus.

• type="text" — a single-line box for ordinary text such as a name or a city.
• type="password" — the same box, except the characters are masked as they are typed. Whether they show as dots or asterisks depends on the browser. Masking hides the typing from someone looking over the shoulder; it does not encrypt anything.
• type="radio" — a small round button. Radio buttons that share the same name form one group, and only one member of a group can be selected. Use it for gender, or for a single stream choice.
• type="checkbox" — a small square box that is independently ticked or cleared. Several checkboxes may be ticked at once, so it is used for hobbies or optional subjects.
• type="submit" — the button that actually sends the form to the address in action. A form without one cannot normally be submitted by clicking.
• type="reset" — a button that returns every control to its original value. Note carefully: reset restores the values that were written in the HTML, it does not empty a box that had a value to start with.
• type="button" — a plain push button with a caption. By itself it does nothing at all; it is meant to be attached to a script.
• type="email" — a text box meant for an e-mail address. Browsers that support it may refuse to submit an entry with no @ sign; browsers that do not support it simply show an ordinary text box, which is a safe fallback.
• type="number" — a box for a numeric entry, often shown with tiny up and down arrows. min and max may be added to fix a range, for example a roll number from 1 to 60.
• type="date" — a control for choosing a date. How the calendar looks, and the order in which the day and month are displayed, differs between browsers and regional settings, but the value sent to the server is written as YYYY-MM-DD.
• type="file" — shows a file-choosing button — its caption reads Choose file, Browse or something similar depending on the browser — so the user can pick a file to upload, such as a passport photograph. For an upload to actually work the form must use method="post" and carry enctype="multipart/form-data".
• type="hidden" — nothing is displayed on the page, yet the name and value are sent along with the rest. It is used to carry a fixed piece of information such as a school code or a form number. It is hidden from the page, not secret — anyone can read it in the page source.

<input type="text"     name="sname">
<input type="password" name="pwd">
<input type="radio"    name="gender" value="Male">
<input type="checkbox" name="hobby"  value="Music">
<input type="email"    name="mail">
<input type="number"   name="roll">
<input type="date"     name="dob">
<input type="file"     name="photo">
<input type="hidden"   name="code" value="SCH-2026">
<input type="submit"   value="Register">
<input type="reset"    value="Clear">

Two distinctions are asked again and again. First, radio versus checkbox: radio is one-from-many within a shared name, checkbox is many-from-many and each one is independent. Second, submit versus reset versus button: submit sends the data, reset restores the starting values, and a plain button does nothing on its own. For submit, reset and button the value attribute is not data at all — it is the caption printed on the button.

Attributes are what turn a bare control into a useful one. Learn them by what they do to the control and to the data.

name — the essential one. The browser sends only those controls that have a name. A text box written as <input type="text"> appears on the page, accepts typing and then contributes nothing to the submitted data, because there is no label to send it under. The server-side script also looks the data up by that name, so a spelling mismatch between the HTML and the script loses the value. If a question asks why is the name attribute essential, answer in two parts: it identifies the control so its data can be sent, and it is the key the server uses to read the value.

value does three different jobs depending on the control, and mixing them up is a common error:

• On a text, password, email, number or date box, value is the initial content shown in the box, which the user may edit.
• On a radio button or checkbox, value is the data that will be sent if that item is selected. Without it the browser sends a default such as on, which is useless to the script, so always supply it.
• On submit, reset and button, value is the caption printed on the button.

placeholder puts faint hint text inside an empty box, such as placeholder="you@example.com". It vanishes the moment the user types. It is a hint only — it is not sent to the server and it is not a substitute for a proper label.

size and maxlength are the pair examiners love. size sets the visible width of the box, measured roughly in characters; the user may keep typing past the end and the text simply scrolls. maxlength sets the maximum number of characters that may be typed at all; once the limit is reached the box refuses further input. So size="10" maxlength="30" is a short box that still accepts thirty characters, and this is perfectly legal.

checked is written on a radio button or checkbox to make it already selected when the page loads. It needs no value: checked alone is enough. Within one radio group only one button should carry it.

required tells the browser not to submit the form while that control is empty; the browser shows its own message. Support and the wording of the message vary between browsers, and older ones ignore the attribute completely — another reason the server must re-check.

readonly and disabled look similar on screen and differ where it matters:

• readonly — the user can see, select and copy the text but cannot change it, and the value is still submitted. Use it for a figure fixed by the school, such as an examination fee of ₹500.
• disabled — the control is greyed out, cannot be used or focused, and its value is not submitted at all.

Grouping radio buttons. A radio group is created purely by giving the buttons the same name and different values:

Gender:
<input type="radio" name="gender" value="Male" checked> Male
<input type="radio" name="gender" value="Female"> Female
<input type="radio" name="gender" value="Other"> Other

Hobbies:
<input type="checkbox" name="hobby" value="Music"> Music
<input type="checkbox" name="hobby" value="Sports" checked> Sports

If the three radio buttons above were given three different names, the browser would treat each as a group of one and the user could switch on all three together — the classic find the error question. Only one pair is sent from a radio group, here gender=Male; checkboxes send one pair for each box that is ticked.

Three controls are written with tags of their own rather than with <input>.

The textarea. <textarea> creates a multi-line box for longer text such as a postal address, a complaint or a short answer. Unlike <input> it is a container element with a closing tag, and whatever is written between the tags becomes the default text shown in the box.

<textarea name="address" rows="4" cols="40">Type your full address here</textarea>

• rows — the number of lines of text visible at a time.
• cols — the number of characters visible across one line.

Both control only the visible size of the box. The user may type far more than rows × cols characters; the box simply scrolls. If the amount of text must actually be limited, add maxlength. Also note the trap: writing value="..." on a textarea does nothing — the default text goes between the tags. And, as always, no name means no data.

The drop-down list. A list is built from two tags working together. <select> is the list itself and carries the name; each choice inside it is an <option>.

<select name="city">
  <option value="DEL">Delhi</option>
  <option value="MUM">Mumbai</option>
  <option value="CHE" selected>Chennai</option>
</select>

Points worth remembering. The name belongs on <select>, never on <option>. The value attribute of an option is what is sent to the server; if it is omitted, the text written between <option> and </option> is sent instead. The selected attribute marks the option that is shown when the page loads — the example above submits city=CHE if the user changes nothing. Without selected, browsers generally display the first option. Two optional extras are worth one line each: size="4" turns the drop-down into a scrolling list box showing four items, and multiple allows more than one option to be chosen.

The label. <label> attaches a piece of text to a particular control. Its for attribute must contain the id of that control — not the name.

<label for="sname">Full name:</label>
<input type="text" id="sname" name="sname" size="30">

When they are linked this way, clicking the words Full name: places the cursor in the box. The gain is largest with radio buttons and checkboxes, whose clickable circle or square is tiny, and on a phone screen where accurate tapping is hard:

<input type="radio" id="g1" name="gender" value="Male">
<label for="g1">Male</label>

This forces a distinction you must be able to state: id versus name. The id identifies the element within the page and must be unique on that page; it is what for points to. The name identifies the data for the server; radio buttons in one group deliberately share it. A control that needs both simply carries both, and they may be given the same spelling, as id="sname" name="sname" above, without any conflict — but writing for="sname" and then giving the input only a name and no id leaves the label joined to nothing.

<fieldset> draws a box around a set of related controls so that a long form reads as a few small sections instead of one crowded list. <legend>, written as the first thing inside a fieldset, supplies its caption, which browsers generally draw sitting on the top border of the box. Both are container elements, and neither sends any data — they are for organising the form only.

<fieldset>
  <legend>Personal Details</legend>
  <input type="text" name="sname">
</fieldset>

Here is a complete registration form for a school website, using every item in the syllabus. Read it once as a whole, then read the notes below it.

<form action="register.php" method="post" enctype="multipart/form-data">

  <fieldset>
    <legend>Personal Details</legend>

    <label for="sname">Full name:</label>
    <input type="text" id="sname" name="sname" size="30" maxlength="40" required>
    <br>

    <label for="mail">E-mail:</label>
    <input type="email" id="mail" name="email" size="30"
           placeholder="you@example.com" required>
    <br>

    <label for="pwd">Password:</label>
    <input type="password" id="pwd" name="pwd" size="20" maxlength="12" required>
    <br>

    <label for="dob">Date of birth:</label>
    <input type="date" id="dob" name="dob">
    <br>

    Gender:
    <input type="radio" id="g1" name="gender" value="Male" checked>
    <label for="g1">Male</label>
    <input type="radio" id="g2" name="gender" value="Female">
    <label for="g2">Female</label>
  </fieldset>

  <fieldset>
    <legend>Academic Details</legend>

    <label for="cls">Class:</label>
    <select id="cls" name="cls">
      <option value="9">Class 9</option>
      <option value="10" selected>Class 10</option>
      <option value="11">Class 11</option>
    </select>
    <br>

    Optional subjects:
    <input type="checkbox" id="s1" name="subject" value="AI">
    <label for="s1">Artificial Intelligence</label>
    <input type="checkbox" id="s2" name="subject" value="IT">
    <label for="s2">Information Technology</label>
    <br>

    <label for="roll">Roll number:</label>
    <input type="number" id="roll" name="roll" min="1" max="60">
    <br>

    <label for="pic">Passport photo:</label>
    <input type="file" id="pic" name="photo">
    <br>

    <label for="addr">Address:</label><br>
    <textarea id="addr" name="address" rows="4" cols="40"></textarea>
  </fieldset>

  <label for="fee">Fee (Rs.):</label>
  <input type="text" id="fee" name="fee" value="500" readonly>

  <input type="hidden" name="schoolcode" value="SCH-2026">

  <input type="submit" value="Register">
  <input type="reset" value="Clear form">
</form>

What is actually sent. Suppose a student fills the form, ticks only Artificial Intelligence, leaves the class as Class 10 and clicks Register. The browser builds pairs such as sname=Anjali, email=..., pwd=..., dob=2010-06-14, gender=Male, cls=10, subject=AI, roll=27, address=..., fee=500 and schoolcode=SCH-2026, plus the chosen file, and posts them all to register.php. The fee box is sent although the user could not edit it, because it is readonly; had it been disabled it would not have been sent. The unticked Information Technology checkbox sends nothing. The fieldsets, legends and labels send nothing.

A checklist for writing a form in the examination. Open with <form> and give it both action and method. Give every control a name. Give radio buttons in one group the same name and different values. Give every checkbox and radio a value. Close <textarea>, <select>, <option>, <fieldset>, <legend>, <label> and </form>. Finish with a submit button. If the question mentions uploading a file, write method="post". Answers to these questions are judged on correct tags, attributes and closing tags, so neat, correctly closed code matters more than pretty layout.