Re: request for new forms submission consensus

Dave_Raggett <dsr@hplb.hpl.hp.com>
X-Delivered: at request of secret on dxcern.cern.ch
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-id: <9310121218.AA27649@manuel.hpl.hp.com>
Subject: Re: request for new forms submission consensus
To: marca@ncsa.uiuc.edu
Date: Tue, 12 Oct 93 13:18:16 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

Here are my (current) views on forms. I have nearly finished the new
draft for HTML+ but will revise the forms stuff to match recent events.

First as a general principle, I feel we want to avoid presentation specific
stuff as much as possible. I would prefer to keep the number of attributes
down, but detect that other people don't feel the same way. So learning
from history :-)

Range controls: e.g. <INPUT NAME="f1" TYPE=range MIN=10 MAX=100>

    These offer the user a choice between the lower and upper values
    and can be rendered in various ways: sliders, spin buttons, and
    direct entry of the number. Initially restricted to integer ranges.

Multiline text fields: e.g.<INPUT NAME="f2" TYPE=text COLUMNS=32 ROWS=4>

    I am not convinced this needs a distinct name from TYPE=text, since
    the presence of the ROWS attribute is clear enough!

Password fields: e.g. <INPUT NAME="f3" TYPE=password>

    Like TYPE=text but not echoed to the screen.

Image fields: e.g. <INPUT NAME="f4" TYPE=image SRC="map.gif" ALIGN=middle>

    These allow users to click on an image/icon within the form. The
    x and y coords of the event are included with the other fields
    only when the image is clicked.  Compound names are used to specify
    the coords as parameters to the field, e.g. f4.x=12&f4.y=17
    This paves the way to more complex objects with multiple parameters.

Option lists:

    These are already supported via TYPE=checkbox and TYPE=radio
    which support multi and single selection lists respectively.

These field types force the author to list each option as part of
an HTML list. The browser can't do anything clever like drop-down
scrollable combo-boxes. I felt this was quite reasonable as it fits
well with paper forms and simple text-only terminals. Everyone will
find them easy to use!

NCSA propose a TYPE=options field with the list as an attribute value:

 <INPUT TYPE="option" NAME="what-to-do" OPTIONS="Drink Coffee,
     Read A Book, Take A Walk, Buy A Bagel, Watch TV" VALUE="Read A Book">

This design leads to arbitrarily long attribute values, which is bad SGML,
and could break some parsers. I recommend instead, the SELECT tag as in:

    <SELECT NAME="what-to-do">
        <LI>Read A Book
        <LI>Take A Walk
        <LI>Buy A Bagel
        <LI>Watch TV
    </SELECT>

You use <SELECT SEVERAL NAME="what-to-do"> if several selections are possible
simultaneously.

TYPE=submit and TYPE=reset
==========================

It seems to me that this is a kludge, and that it would be much better to
leave it up to the browser and platform specific form conventions. For most
systems, the browser should show Submit and Reset buttons automatically at
the end of the form. For a form with a single text input field, the browser
can omit these buttons and assume use of the "Enter" key instead. This
doesn't cost much since by the time the browser reaches the </FORM> tag it
already knows what fields there are in the form.

Transfer formats
================

For simple implementations the URL?name=value&name=value&... scheme is fine.
But in the near future we will want fields that can accept scribble (e.g.
hand-written signatures) and voice input. MIME multipart messages seem like
the right way to go:

    MIME-Version: 1.0
    Content-Type: multipart/mixed;
        boundary=unique-boundary-1

    --unique-boundary-1
    Content-Type: application/html-form

    name: value
    name: value
    name: @part-name
    --unique-boundary-1
    Content-Type: audio/basic
    Content-Transfer-Encoding: Base64
    Part-Name: part-name

    ... the encoded audio data goes here
    --unique-boundary-1--

The above uses the new MIME content type "application/html-form" to
transfer the basic form data as one or more lines each of which
has one of the following formats:

    a)    field-name: field-value

    b)    field-name: @part-name

The second one specifies the field's value indirectly as a named MIME
message part. This allows us to use the normal MIME mechanisms for
different data types, in this case audio/basic with base64 encoding.
The header "Part-Name:" should be used to declare the name of each
part in a multipart message.

I am worried about using % followed by the hexadecimal code as a means
of escaping significant characters in attribute values. It seems to
closely linked to using 7 or 8 bit US ASCII. What should we use instead?

Comments please as soon as possible so that I can get the draft out.

Dave Raggett