Form input and output (was: <pre>)

Daniel LaLiberte (liberte@ncsa.uiuc.edu)
Fri, 7 Oct 1994 18:08:26 +0100

From: "Brian Gaines" <gaines@fsc.cpsc.ucalgary.ca>

Root problem is that the client side is responsible for such
matters of style and one is talking of features not
standards. However, it would make more sense if the expected
default behavior of a TEXTAREA was to wrap. Forms are now
being used for major data entry functions that go way beyond
their origins as a basis for more complex search requests.

There is a server side issue here too. What can server cgi programs
expect to receive? If the form input is going to a mailbox, the
receiver of the mail may see only long lines truncated at 80 columns.
If the form input is going to be displayed within an HTML document, it
will be wrapped properly if it is not within <PRE></PRE> tags, but
then it will be one big paragraph.

It may not be sufficient for servers to automatically insert newlines
in the form input because perhaps the user intended some lines to be
longer. Clients might have the same problem. The bottom line is that
different kinds of text entry fields are required: no word wrap, word
wrap with no conversion, and word wrap with auto-insertion of newlines
by clients. Servers should be able to specify what kind of text they
want back and clients should be able to let users specify what kind of
text they want to enter. Conversion is required if there is a mismatch
between what serves and clients want.

Another related issue is how a newline is sent by clients. It is not
a big deal for (Unix) servers to always do the following (in Perl):

# Must be done in this order.
$articleContent =~ s/\015\012/\012/g; # Convert PC's CR/LF into just LF.
$articleContent =~ s/\015/\012/g; # Convert Mac's CR into LF.

But it is one extra annoying thing that always has to be done, so why
not just have clients do it? Servers might have to convert back to
their preferred standard, but there should be one intermediary standard.

Another related issue is how large VALUE strings and input fields can
be. Servers have to know how large of a VALUE string they can send,
and clients have to know how large of an input string they can send.
Similarly, how large can URLs be?

Daniel LaLiberte (liberte@ncsa.uiuc.edu)
National Center for Supercomputing Applications