The HTML construct form is your primary gate to the interactive properties of the Internet. Without form, there is emptiness and void...well, not quite. Every static page you visit on the Intarweb, is basically what would exist without forms. Rather like a page out of a newspaper or magazine, it offers read-only entertainment. Well, I suppose you can doodle on a newspaper, so a form-less web page is even less fun-filled.

Add a form into the mix. Lo, and the power of input is given to you (or if you're the author, you bestow it upon your visitors) - there are so many possibilities now!

A few examples include (explanation of terms and more depth below):
- Shoutboxes (like the catbox, dig?): Type in the input field (attribute TEXT) and hit the "Talk" button (attribute SUBMIT) and the form takes your invaluable words, sends them into the server for storekeeping and refreshes the page. Very similar to a guestbook in that respect.
- Poll: Click in the so called "radio button" (attribute RADIO, believe it or not) - these special types of checkboxes will only allow you to make one penultimate choice, perfect for taking a poll from your kingdom's subjects. Once again, the form takes your choice, sends it into the depths of the server for storekeeping and refreshes the page (or sends you to results). The clever bit here is that all of the radio buttons share the same name. More on that later.
- Survey: Well, apart from the text boxes and multiple choice questions, surveys also have those "Check all that apply" things. Those would be "checkboxes" (attribute CHECKBOX, oddly enough), and they're just as above.
So basically, what a form does is take any input entered into it and send it elsewhere (CGI, perl, PHP or ASP scripts for example) - that's all. What's done with that information is up to other code on the receiving end, and can be anything from emailing the information somewhere, to adding it to the database, performing some calculations on it and then spitting it back out.

These are the form specifications: its name, its destination (called "action") and the method of sending the data (called "method"). Let's take a look at the form called the catbox to illustrate how these specs are used.

<form name="formcbox" action="/index.pl" method="POST" enctype="application/x-www-form-urlencoded">

The "name" is pretty simple; it's just what the form is called within the HTML; this is useful when you have other stuff referring to it - like the (r) link, which has to know where to put the reply. Without it, you might find your reply going into your scratchpad...

The "action" is where the data is sent - E2 is pretty nifty in that everything gets processed through its index.pl file. As mentioned, what happens afterwards is beyond the form's knowledge; it just knows it's sending your catbox spewings to itself. On other sites, action may be something like "email_the_form.html" or "process_data.php".

The "method" refers to HTTP Methods; since the form requires the transmission of data from one page to another, only two methods are relevant: GET and POST; the POST is used probably 99.99% of the time. The former will look like this, for example:

http://www.everything2.com/index.pl?node=HTTP&lastnode_id=1294649

The node=HTTP and lastnode_id=1294649 are GET variable/value pairs. Anything appended to the URL with a ? and separated with & applies to this definition.

There's a lot of jargon and recursive definitions (My favourite: "The POST method means that a HTTP POST request is made") about POST, but the truth is far simpler: it's magic¹. The data gets from here to there without being externally visible anywhere in-between. This makes for shorter URLs (just think if the entire text of this was in the URL after sending it to my Scratchpad! Ick!) and is overall rather NEAT.

Finally, the "enctype" tells the server how to encode the data for transmission. The one seen above is the default for forms and simply tells the server to expect ... stuff from a form. Pretty straightforward. The other popular type is "multipart/form-data", and tells the server to expect a binary file - you'll see this wherever uploads are offered via the web. It is required for uploads, otherwise the file will be garbled on receipt and unusable.

Okay, we now have our form named, aware of where it's going and how it's getting there. Time for some inputs.

The Components; INPUT; TEXT

Note that the input tag does not require closing tags - check Empty HTML Tags for clarification.

Text:
<input type='text' name='text_input' value='Your name here...' size='40' maxlength='60' readonly='readonly' disabled='disabled'>

Pretty easy stuff. Let's break it down:
  • type is simply the type of the input you're using. In this case you want a single-line box where you can enter text. This parameter is used with all input-type tags (not textarea).
  • size refers to the size (in characters) of the input box - this is how wide it will be on your screen. Beware though - since anyone can now use the zoom ability on their browser, or override your style with their own CSS, this method of limiting the size is fairly useless. It can still serve as a guideline to how much text you're expecting though.
  • maxlength is far more useful. It limits the number of characters the user can type into the box. If maxlength is larger than size, your text will scroll sideways inside the box - you can observe this in the catbox or in the searchbox. Keep in mind that this is a guideline, not a rule and can be circumvented. Always verify your user input.
  • name, as mentioned, is used as an identifier for the input you're using. The receiving script will need to know what's what, basically. This parameter is used with all inputs.
  • value lets you place a value into the textbox before the user types anything in. This is useful when you want to provide the user with previously entered data - like the Scratchpad does.
  • disabled allows you to include an input element which ... is not used. When is this useful? When you want to remind the user about unalterable input they've already submitted. I find this useful on forms that are composed of multiple pages; info entered on page 1 cannot be changed on page 3, for example. This parameter can be used with any input.
  • readonly is much like disabled, except that the data is sent along with the form (disabled does not send the data, just displays it). It is still unalterable. This is useful when you want to explicitly show some extra information that the user will sending along with the form (say you want to inform the user that their IP address is being logged - this would be the way to do it). This parameter can be used with any input.
Password:
<input type='password' name='password_input' value='' size='40' maxlength='60' readonly='readonly' disabled='disabled'>

This one acts just like text, except the screen displays only * instead of letters, to protect from someone trying to peer over your shoulder as you type in your password. You see this one anywhere you have to enter a password (including for logging into your E2 account). All parameters act the same way as text, although it'd be pretty silly to disable someone's password entry box...
File:
<input type='file' name='file_input'>

This input comes with a "Browse..." button of its own; clicking it will open up your computer's browsing utensil for your uploading needs. The user can also type in the filename by hand; either way, be sure to either leave maxlength off, or make it long enough (150+) for the entire convoluted path to fit! Otherwise, the file won't upload and your user will be quite, quite vexed.
Hidden:
<input type='hidden' name='hidden_input' value='hidden_info!'>

This is a way to include information you don't necessarily require the user to see (such as their unique ID number in your system, or special parameters passed to the receiving script/server). The value for this is always preset by your form and cannot be altered by the user. Anyone viewing the HTML source of your form will be able to see this however, so it's definitely not a good idea to use this for secret or confidential info.

The Components; INPUT; Widgets

Checkbox:
<input type='checkbox' name='checkbox_input' value='1' checked>

As mentioned, checkboxes are great for selecting multiple choices in a survey, or yes/no questions or options. You'll see quite a few of them in your E2 Preferences. Checked means Yes, enable this choice. Unchecked means no. Curiously, leaving a checkbox unchecked does NOT send an empty choice - it simply does not send that INPUT at all (this means if you have a true/false question, choosing false - unchecked - is the same as not choosing at all). This can sometimes lead to erroneous results, so be sure to check for missing inputs (a sort of "Raise your hand if you're absent" situation).
Radio Button:
<input type='radio' name='radio_input' value='Choice 1' checked>
<input type='radio' name='radio_input' value='Choice 2'>


Radio buttons are neat because a single group of them allows only one choice - great for multiple choice questions - as long as you're sure that the answer is really only one choice. One tricky part to remember here is that a group of buttons - like the two above - shares the same name. Another tricky part is that by default, no buttons are checked - make sure to "checked" one of them on your form to force user input.

Note that radio "button" is a misnomer; it is really a circular checkbox. The term stems from old-style radios where pushing one-button (for a preset station) would eject another; radio buttons also function on the "only one at a time" principle.

The Components; INPUT; Buttons

Note that despite the buttons not really adding any data to your form, they are inputs, and their values will be sent with the form. Make sure to filter them out with your script.
Reset:
<input type='reset' name='reset_input' value='Clear Form!'>

This button (actually renders as a button, it has a built-in push-down animation) resets the form to initial values, and is usually used for wiping out data. The value attribute lets the author change the default text on the button.
Submit:
<input type='submit' name='submit_input' value='Stumbit'>

Pressing this button sends the form to the file defined in the ACTION parameter (way up there at the start) using the METHOD specified. The value attribute lets the author change the default text on the button. Just about every button on E2 is a submit.
Image:
<input type='image' name='image_input' value='Clear Form!' src='some_image_file.jpg' usemap='map.html'>

This one acts just like SUBMIT, except it's an image - this is generally used for making a nicer looking submit button. In the olden days there were such things as image maps, where clicking on different parts of the image resulted in different behaviors.

While tools such as DreamWeaver simplify the creation of image maps, most developers of dynamic websites don't bother (since they're a hassle to update whenever new content is created) - it's still nice for static pages though, if you have a permanent (hopefully) showcase. The usemap parameter is used to define the location of image maps.

The image type will send x,y coordinates of where the user clicked on the image along with the rest of the form inputs.
Button:
<input type='button' name='a_button' value='Do Something!'>

This button is a curious specimen; by itself, it does nothing. It needs the addition of scripting and the addition of onClick=doSomething(); parameter (of course doSomething has to be defined above, but that's another node) for it to do anything at all. It is the only input whose behaviour has to be explicitly specified before it's useful.

The Components; TEXTAREA

TEXTAREA:
<textarea name='textarea_input' cols='40' rows='40''>Scratchpad Contents</textarea>

This one's even easier, although a little different than standard inputs. While an input tag doesn't require an ending </input>, the textarea does. In addition, the value='' parameter does not exist; the value goes in between the opening and closing tags.
  • name - as above.
  • cols is the horizontal size of the textarea box, in columns.
  • rows is the vertical size, in rows obviously.

The Components; SELECT

SELECT:
<select name='select_input'>
<option value='1' selected>Choice 1</option>
<option value='2'>Choice 2</option>
<option value='3'>Choice 3</option>
</select>


This one's another oddball. Not only do you need an end </select>, you also need stuff in the middle which has its own starting and ending tags. This is a drop-down menu, such as is presented in forums for navigation purposes - but really can be used for anything where you have a LOT of choices to present, and want to restrict the user to only one choice.

Alternately, you can add the attribute multiple to your select - this will let the user make more than one choice. This is useful in combination with attribute size - this tells the browser how many lines of choices to display. This is a very versatile type of input.

If you don't add a "selected" to one of the choices, the browser will default to the LAST choice; it is recommended that you do.
We are finally done. We have made a complete form with one of each available inputs; now we must close it with </form>. We are now ready to ask our intrepid webpage explorers all sorts of inane poll questions (remembering to put in the insensitive clod choice), or accept all sorts of nutty writeups; exchange flurries of insults via a shoutbox, or even run a serious survey. You are armed with the knowledge. IT IS TIME.
¹The specifications say "The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line." I prefer my definition.

http://www.htmlhelp.com/reference/html40/forms/input.html helped me make sure I didn't miss any input types.