Previous discussions suggested including the HTTP method as an optional prefix
in the action e.g. ACTION="POST http://..." but I agree that where possible
authors should design the form so that the effect of submitting the form is
explicitly chosen by the user's actions and not via the HTTP method.
> This (a database interface) does bring up another issue. Let's say I have
> a database where one of the elements is a large piece of text (e.g., a
> bug report). You cannot currently represent this with forms. Why?
> Because when you try and put the "VALUE" in <INPUT SIZE="64,30"
> VALUE="...50K of text..."> I'll bet just about every parser we have is
> going to break.
Don't worry! The HTML+ Internet Draft (due out by the end of this week :)
covers this. The HTML/HTML+ DTD limits attribute literals to 1024 characters,
(the SGML default is only 240 chars!). You can include line breaks in literals
as these are mapped to spaces. In fact, any contiguous sequence of white space
characters in attribute literals are defined by SGML to map to a single space
character.
The spec now uses a separate element for multiline text fields to allow
the value to be arbitrarily long. You can specify the visible extent of
the field in rows and columns, but browsers are free to allow users to
enter arbitrarily amounts of text - not restricted by the visible extent.
Option lists will also be represented by a separate element <SELECT> to
allow arbitrarily long option lists.
The spec also covers scribble fields upon which you can write with a pointing
device such as a pen, and audio fields for entering spoken messages. This
is made possible through the use of multipart MIME messages for sending
form contents to servers.
Cheers,
Dave Raggett