20: HTML forms—the basics

HTML forms are vital when you want to gather feedback or other information from your site visitors. This article will take you through the basics of creating HTML forms as gently as possible.

( Read the article )

I see in your code examples that you have generally given your form controls the same name and id. Yet, you didn't cover the difference between the two - i.e. that id is optional on form controls and is used to uniquely identify any element on a web page (not just form controls), while name is needed to identify the form field data when it is submitted to the server.

For example, a page may have two forms. Both forms might have a field named "address", but they cannot both have an id "address"!

The checkbox in step 3 is currently missing its name. I suspect browsers may fudge things by substituting the id that's there.

This is an aspect of forms that seems to confuse lots of people, so I think it deserves some attention here.

Thank you for writing the article!

I often use html forms for interfaces to client side scripts rather than server side eg 1 eg 2. The article doesn't mention client side interfaces so I don't know whether this question is beyond the scope of the article or not. I've not found any reference on how to markup a form for client side scripting which I think is strange because it is a very popular use for forms.

Through trial & error I've managed to find a combination of attributes for the form tag that work & pass the W3C validator:

<form action="" onsubmit="Validate();return false">

...but is it correct? The 'action=""' bit always seems wrong to me, & having to include 'return false;' on the event handler seems counter intuitive.


As for having to add an ID for all controls to associate a label with it. Is this not allowed?:

<label>Name: <input type="text" name="name" id="name" value="" /></label>

This method seems much cleaner & easier, & makes more sense.

Originally posted by orinoco:

I often use html forms for interfaces to client side scripts rather than server side eg 1 eg 2.

Which causes a dependency on JavaScript, which is generally considered to be A Bad Idea.
See [http://icant.co.uk/articles/seven-rules-of-unobtrusive-javascript/]

Originally posted by orinoco:

Through trial & error I've managed to find a combination of attributes for the form tag that work & pass the W3C validator:

<form action="" onsubmit="Validate();return false">

...but is it correct? The 'action=""' bit always seems wrong to me

Technically, it is OK (being a relative URI that resolves to the current URI), but browser support isn't quite perfect (sometimes it is treated as "./"), so using a more explicit URI is better.

Originally posted by orinoco:

, & having to include 'return false;' on the event handler seems counter intuitive.

An event handler does something when an event happens.

It seems intuitive enough to me that you should have to do something explicit to halt the normal event from occurring.

I'd try to avoid using intrinsic event handler attributes though, better to attach the events with scripting. It lets you keep them better separated. The YUI Event library is good for helping with this.

Originally posted by orinoco:

As for having to add an ID for all controls to associate a label with it. Is this not allowed?:

<label>Name: <input type="text" name="name" id="name" value="" /></label>

This method seems much cleaner & easier, & makes more sense.

It's less flexible regarding styling, and (more importantly) not so well supported by browsers.

Originally posted by dorward:

Which causes a dependency on JavaScript, which is generally considered to be A Bad Idea.

So it's use a server side script or don't do it? OK, I will take all my pages down immediately

Seriously though that is extremely limiting. Most web authors use free hosting servers & don't have access to server side scripting. I use JS because that is all I have access to.

Originally posted by dorward:

An event handler does something when an event happens.It seems intuitive enough to me that you should have to do something explicit to halt the normal event from occurring.

I say counter intuitive because for forms with server side scripts you don't use action="something.php;return false;"

It would be nice if the spec enabled you to specify a js file as the action & a function as the method, then submitting the form supplies all form values to the function as variables.

Originally posted by dorward:

It's less flexible regarding styling

How so? I can still add classes &/or IDs to any label that needed specific styling. What could I do with the method used in the article that I couldn't do with this one?

and (more importantly) not so well supported by browsers.

It's worked in O, FF & IE (WinXP) for as long as I've been using it (2 years at least). Do you know any browsers (that support labels) where it doesn't work (ie. clicking the label does not focus the form element)?

Originally posted by orinoco:

I say counter intuitive because for forms with server side scripts you don't use action="something.php;return false;"

You aren't trying to submit the form to a server side script and at the same time stop the form from being submitted.

Originally posted by orinoco:

How so? I can still add classes &/or IDs to any label that needed specific styling. What could I do with the method used in the article that I couldn't do with this one?

A common use case would be to cause all the inputs to line up along a vertical line, and have their labels on the left:

label {
width: 10em;
text-align: right;
margin-right: 1em;
float: left;
clear: left;
}

Originally posted by orinoco:

It's worked in O, FF & IE (WinXP) for as long as I've been using it (2 years at least). Do you know any browsers (that support labels) where it doesn't work (ie. clicking the label does not focus the form element)?

Internet Explorer 6 didn't support implicit association last time I checked, and it still has a huge market share.

Originally posted by dorward:

You aren't trying to submit the form to a server side script and at the same time stop the form from being submitted.

My point exactly. The spec incorrectly assumes that forms are *always* used for server side scripts. This is why I asked if there was a correct way to set up a form to use a client side script because from my limited understanding of the HTML specification I don't think there is

Originally posted by dorward:

A common use case would be to cause all the inputs to line up along a vertical line, and have their labels on the left:

???

test.htm

Seems to do as you suggest.

Originally posted by dorward:

Internet Explorer 6 didn't support implicit association last time I checked, and it still has a huge market share.

Ah IE6, standards be damned... (I know the for="id" way is also standard but it would be much simpler & cleaner if I didn't have to assign 140+ unique ID's to elements in an ever changing quiz!)

Originally posted by orinoco:

The spec incorrectly assumes that forms are *always* used for server side scripts.

That is what forms are designed for. (While DOM 0 adds a convenient way to access the controls of a given form with JS, you don't need a form to have form controls. But still, depending on client side scripting isn't a good idea and I don't buy into this idea that most authors don't have access to server side scripting).

Originally posted by orinoco:

Seems to do as you suggest.

Absolute positioning can be rather fragile, in this instance the controls were overlapping the text.

Fair enough, thanks for your replies.

"In the case of a checkbox, radio button, hidden, submit, or other type attributes you can set the value to equal what you want the default to be. In other cases, such as submit or hidden, you set the value to equal the final input."

I think that checkbox, radio button, hidden and submit attributes let you set the value to equal the final input; text, password or file attributes let you to set the value to equal what you want the default to be.

"(checkboxes allow you to select multiple options, radio buttons only one)"

I think it's the other way round.

Forget the second part of my previous post: checkboxes and radio buttons are fine. Sorry.

typo: correponding

Under Step one, "predetermined value": the text says that the user checks the checkbox, because he wants to join the mailing list. In this case the default value shouldn't be "no" instead of "yes" ?