intelligent internet agents

The form percept
August 10, 2009, 2:33 pm
Filed under: forms, percepts | Tags: , ,

In general the form tag has an method “GET” or “POST” that can be associated with and an action. The action is defined by a target URL (relative or absolute) behind which, some piece of software on the server side will pick up and process the data that the user provided through the input elements from withing the form tags on the HTML page.


This specification does not specify all valid submission methods or content types that may be used with forms. However, HTML 4 user agents must support the established conventions in the following cases:

  • If the method is “get” and the action is an HTTP URI, the user agent takes the value of action, appends a `?’ to it, then appends the form data set, encoded using the “application/x-www-form-urlencoded” content type. The user agent then traverses the link to this URI. In this scenario, form data are restricted to ASCII codes.
  • If the method is “post” and the action is an HTTP URI, the user agent conducts an HTTP “post” transaction using the value of the action attribute and a message created according to the content type specified by the enctype attribute.

For any other value of action or method, behavior is unspecified.

Inputs outside form tags.

You might think that this is invalid:


And of course it is.

What does it mean? Why are input elements outside a form tag valid.
Actually in the case above the form tags are irrelevant because they have no elements within them.

So a more appropriate notation would be:


Inputs can be children of and block element. Why?, well you can of course let users input data, manipulate it and display the results using client side javascript without ever having to send it to the server. This is the idea behind inputs outside the form tags.

Think of a simple calculator on a Html page – this need no server side processing at all, put it does need input from the user.

What does this mean?

1. If input elements are outside a form then we can take for granted that they javascript will be processing them. BUT we do not know if they will be processed entirely by the client, partly by the client and partly by the server, or entirely by the server.

2. If input elements are within a form then we know that the inputs will be sent to the server IF there is a submit button defined. If there is no submit button defined then we can take it for granted that some client side javascript will be listening to some element like a link and will send some, or all – as is – or changed – parameters to the server, either using standard or custom javascript methods.

3. If input elements are outside a form then we can not identify which inputs belong together. Again, different pieces of javascript code could be responsible for sending different sets of input values to the server.

The answer is clustering input using the DOM tree:

This will have the best indication of what inputs belong together from a user perspective. This also has the advantage that a “unique set” can be identified – this means that we can identify the the form as being unique on any leaf of the website tree.


Leave a Comment so far
Leave a comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: