Re: HTML+ Forms

Dave_Raggett <dsr@hplb.hpl.hp.com>
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-id: <9306181521.AA29719@manuel.hpl.hp.com>
Subject: Re: HTML+ Forms
To: TONYJ@scs.slac.stanford.edu
Date: Fri, 18 Jun 93 16:21:52 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]
Hi Tony,

Sorry for the delay in getting back to you, I am rather snowed under
these days.

> Hi Dave, do I take it from this comment that some examples exist of the 
> use of <INPUT> and other form stuff? If so can I access them somewhere? I 
> have a preliminary implementation of Forms for MidasWWW and would like 
> some examples to try them out on.

Can you tell more about your implementation of Forms for MidasWWW?

I enclose the current HTML+ definitions for forms at the end of this
message. The new FORM tag allows several forms to be included in
the same document. This tag also defines what to do when the user
presses the "commit" key (normally the Return key), e.g. to send the
form's contents as a query to a server or to send it to a designated
person as an email message. The new MH tag allows you to define
arbitrary email header fields at the start of each message.

We still need to pin down how form contents can be passed to
servers as queries etc. and I would be very grateful for some
help in this regard. Some ideas for doing this with URLs are given
later on.

Now for an example which supposes that a server has been set up to help
sales staff configure quotes for computer workstations. It is based on
an expert system I worked on a couple of years ago.

    <FORM action="http://ukrc.hp.com:8002/s720">
        <H1>HP 9000 Series 720 Workstation</H1>

        <UL>
            <LI> 50 MHz PA-RISC CPU
            <LI> Wide range of graphics options
            <LI> 16 to 128 Mb ECC RAM and 2 optional disks
        </UL>

        <INPUT id="f1" type="INT" width="2" value="1"> Quantity </INPUT>

        <SELECT id="f2" compact> Graphics
            <ITEM id="i1" selected> Mono GRX
            <ITEM id="i2"> Color CRX
            <ITEM id="i3"> 2D Color VRX
        </SELECT>

        <SELECT id="f3" compact> Internal hard disks
            <ITEM id="i4"> 1 x 420 Mb
            <ITEM id="i5" selected error> 2 x 420 Mb
        </SELECT>
    
        <INPUT id="f4" type="bool" value="true" error> 3.5 inch floppy drive

        <P>
        *** You are only allowed two internal drives! ***
    </FORM>

The form starts with a header and a list of features for the workstation.
A quantity field follows which allows users to type a two digit integer.
It is initialised to the value "1".

Next there is a selection menu. Users have to choose one of a range of
graphics options. The initial value is the first item as indicated by
the selected attribute. The compact attribute tells the browser to render
the menu in a compact style, e.g. as a button with a drop down menu. For
menus supporting multiple selections, you would need to show the current
selections as a (truncated) list next to the dropdown button. The normal
(uncompact) style would be a permanently visible list, perhaps with some
kind of button to the left of each item, but visually distinct from
bulleted lists defined with the UL tag.

Fields can be marked as being in error or greyed out (disabled). The latter
case means the field cannot be altered - perhaps because its value is
constrained by the values of other fields.

The next field is also a selection menu. In this case the selected item
is marked as being in error and needing to be changed. The browser could
indicate this by a red splash next to the menu item.

The last field is a boolean checkbox, currently checked. It too is marked
as being in error and needing to be changed. The static text message which
follows indicates the nature of the problem.

Menus and checkboxes can be altered by clicking the mouse. Other kinds of
input fields require the user to set the input focus to that field, e.g.
by clicking with the mouse or using the tab/shift tab keys. Input fields
needing keyboard input show a cursor (blinking?) when they have the input
focus.

Pressing the Return key sends the form's content to the server designated
by the URL in the FORM tag. The server evaluates the form's contents
and in this case replies by sending a document containing the form, but
marked up to indicate the user has made some inconsistent choices for
disk drives.

This assumes that the browser encodes the form's contents as a
list of field ids and values following a "?" suffix after the URL.
It may be better to define a HTTP method for form data with a clean
encoding.

A suggested URL encoding:

    ? FIELD [ + FIELD ]*        -- ie FIELDs seperated by "+" --

where FIELD is:
    id:value                    -- single valued fields --
    id:(value[+value]*)         -- multi valued fields --

Selections would use the item id in place of the actual
string value.

Special characters should be replaced by "%" followed by the
two hex digits encoding the ASCII value.

The special chars are (based on Tim's URL spec for xalphas:

        + - % ( ) ! ^ & * $         (and all white space chars)

Note that URLs would then be of arbitrary length!

Best wishes,

Dave Raggett

------------------------------------------------------------------------

<!-- Forms: these are composed from input fields and selection menus

    These elements define fields which users can type into or select
    with mouse clicks. The browser should manage the input focus
    e.g. with the tab/shift tab keys and mouse clicks.

    The enter/return key is then taken to mean the use has filled
    in the form and wants the apppropriate action taken:

        -   send as query/update to WWW server
        -   email/fax to designated person

    The action is specified as a URL, e.g. "mailto:dsr@hplb.hpl.hp.com

    You can specify additional mail headers with the MH tag:

    <MH>Subject: Please add me to tennis tournament</MH>
 -->

<!ELEMENT FORM - - (MH*, (%main;|INPUT|SELECT)*)>
<!ATTLIST FORM
    id      ID        #IMPLIED
    action  %URL;     #IMPLIED>

<!ELEMENT MH - - CDATA -- RFC 822 header fields -->

<!ELEMENT INPUT - - (%text;)>
<!ATTLIST INPUT
    id      ID      #IMPLIED
    type    CDATA   #IMPLIED    -- URL, INT, FLOAT, DATE, BOOL, TEXT --
    width   CDATA   #IMPLIED    -- precision e.g."32x4" for multiline text --
    value   CDATA   #IMPLIED    -- the current value (yes/no for boolean fields) --
    disabled (disabled) #IMPLIED    -- if grayed out --
    error   (error)    #IMPLIED    -- if in error -->

<!-- Menu selections one from many and many from many

  The compact attribute is a suggestion that the browser renders
  the list in compact style, e.g. as a dropdown menu.

  The multi attribute means the menu permits multiple selections -->

<!ELEMENT SELECT - - ((%text;)*, ITEM*)>
<!ATTLIST SELECT
    id      ID        #IMPLIED
    compact (compact) #IMPLIED
    multi   (multi)   #IMPLIED>

<!-- menu items with attributes for menu selections -->
<!ELEMENT ITEM - O (%text;)>
<!ATTLIST ITEM
    id          ID         #IMPLIED
    selected    (selected) #IMPLIED -- if selected in list --
    disabled    (disabled) #IMPLIED -- if grayed out --
    error       (error)    #IMPLIED -- if in error -->