HTML and the form are intertwined very confusingly.

Looking at forms, you immediately see more than HTML. You see communication, you see CGI and interface, HTTP, blah, blah, and blah. You could almost think that the form was the main thing, and not the HTML. You would be partly right.

I have an HTML forms summary and example page with a list of all the form elements.

Belonging also here is probably a synopsis of the query string, for lack of another place.

name=jo&email=jo%40bo.no
name=jo;email=jo%40bo.no

Above is a complete explanation of the query string format, by way of a picture.

Every bit of form information is tagged with a name, e.g., <input name="email" .... Upon the submission of the form, this field is encoded into the form email=blah, where blah is the email value itself.

Special characters, like the @ sign, are "url-encoded." Multiple fields are joined by either an ampersand, &, or a semicolon, ;.

There is also a multipart/form-data method of encoding, similar in composition to an email message. It is the only mechnism for file upload fields (e.g., <input type="file"). My main gripe is that no browsers seem to specify a content length for any files transferred--making it a pain to properly implement, to say the least!

Another horrible complaint I have about MIME in general is this. Line-folding and non-line-folding.

There is no logical reason why a line cannot contain any arbitrary amount of characters. In fact, there is no good reason at all why a single line could not contain the entire encoded text of all books ever written.

However, some ignorant and careless (and downright thoughtless and stupid) people have written programs which blindly assume that all lines will be less than, say, 1,000 characters.

I say, hey! of course the lines that you read can be less than that, and probably a lot shorter (anyone want a four-foot-wide book?). But, deep inside a computer there is no need for text wrapping. It certainly doesn't help the computer read!

So there are these programs which crash horribly and die with the meanest sorts of exceptions (and security holes!) any time they see something as simple as 1025 hyphens in a row.

The attitude in regard to MIME boundaries doesn't help any, either. In fact, it is theoretically impossible to guarantee that any random MIME message will even be readable! Nice way to write letters. Yeah, right.

In terms of HTML itself, I must say that I disagree with the required action="foo" attribute. Suppose you search Google from right here: I would need to set the action to http://www.google.com/search in order to direct the form to Google's search engine. However, the search program itself should have no need to respecify its own location. It is redundant. Forms should use their own URL as a default action.

Another complaint I have about forms is the class act of stupidity committed by the document "object model" (referred to as the DOM, which I'd revise to the Dumb Dom) people.

As the standards are written, there may be any number of like-named fields submitted through any form. Yet, the same standards don't provide any consistent interface to access the fields, such as through JavaScript.

If I had the field <input type="text" name="file" ..., I would say [form].file.value in order to get at its value. If I later added another field, also named "file"--perfectly legal and right in all resepcts--suddenly my code would be invalid. Instead I would be required to say [form].file[0].value, or some such cruel nonsense.

This is seriously bad. The same standards invalidate themselves.

I would make two models, each distinct, and each non-contradictory: a machine model, and an interface model.

The machine model is like bytes--independent of character set, document type, etc., etc. It is what the computer really does, the bottom line. It is how a parser works, how an image is decoded, how an email is sent.

The interface model is what things actually mean. You know, things with names and places and faces. It is how you click on a button, how you open a file, how you look at a website.

The problem now is that we're trying to mix up the two, and it doesn't work. Let the computer speak like a machine, and let us talk like humans.