W3C Style Guide


Allowing input

Your site may be quite static, or it may allow user input in one form or another. Input varies from the vary finely controlled form in which the user taken down a carefully prepared path, to the open collaborative editing system in which users can create their own spaces according to their own imagination and the concepts they have to communicate.

Forms: GET and POST

There is a very important distinction in society and in software, and certainly on the Web, between reading and writing; between having no effect and making changes; between observing and making a commitment. This is fundamental in the Web and your web site must respect it. Currently the line is often fuzzily drawn, which is very bad for many reasons.

Form can work in two ways corresponding to this distinction.

One way is to direct the user, like a link, to a new resource, but one whose URI is constructed from the form's field values. This is typically how a query form works. (It uses HTTP's GET method.) The user makes no commitment. Once he or she has followed the link, he or she can bookmark the result of the query. Following any link to that same URI will perform the same query again. It is as though Web space were populated by lots of virtual pages, one for the results of each possible query to the server. There is no commitment by the user. The operation can be undone simply by pressing the Back button on a browser. The user can never be held responsible for anything which was done using HTTP GET. If your website fills a shopping cart as a user follows normal links, and sometimes users end up ordering too much or too little as they use a web accelerator or a cache, then it is your fault. You should have used the second way.

The second way a form can work is to take a command, or commitment, from the user. This is done using HTTP POST or sometimes by sending an message. "Submit this order", and "unsubscribe from this list" are classic examples. It is really important that the user understands when a commitment or change is being made and when it isn't. Hopefully, clients will help by changing the cursor to a special one when a commitment is about to be made. Such an operation, like sending an email, or signing and mailing a paper document, cannot be undone. It is socially quite different. Browsers and servers and proxies which understand HTTP treat it quite differently. You should never confuse these two types of interaction on your web site, either way. If you do, you break the web, and the web will break your site.

For more information about this issue, see

If you allow editing, allow direct editing

Good clients should (as for example Amaya and AOLPress always have) allow users to modify pages and, when authorized, save them directly back to the web site. This is the way to do it - don't ask people to download, change application, edit, and upload. Remember, in editing as in browsing the location of information should not be anything the user is aware of. Location independence in an abstract space.

Example: To allow a message to be input, follow a link to a new resource initialized from a template. Allow the resource to be edited with the user's favorite hypertext editor. The template should be cross-linked with a submission form which captures metadata about the message. The form has a submit button. After this is pressed, the message is no longer editable, but has been "sent" in that the user is now committed to its contents and others can access it.

For more information about this issue, see


(Part of the Style Guide for Online Hypertext . Back to Within each document , On to Background reading )

© 1991-95 Tim BL