Makes the browser code cleaner -- they have to be handled differently
internally. Not a big deal, but I always thought following the
"different things have different names" philosophy led to greater
cleanliness.
> 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.
Whatttttttt????? Really??? Ick. SGML is starting to look worse and
worse.
> 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.
That's not very elegant -- looks and feels like bastardized text
markup (which it is :-).
> 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.
And that, in fact, is what we already do -- except we provide the
document writer the flexibility to have, if he so chooses, arbitrary
layout and numbers of the buttons. All else being equal, flexibility
is good, experience has shown, otherwise we get blamed for making the
wrong decision by someone -- this avoids that.
> 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?
Oops, disregard most of my previous message replying to this -- I
didn't see all the context. (My mail reading skills are declining
rapidly...)
Cheers,
Marc