Re: request for new forms submission consensus

marca@ncsa.uiuc.edu (Marc Andreessen)
X-Delivered: at request of secret on dxcern.cern.ch
Date: Tue, 12 Oct 93 16:54:41 -0700
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-id: <9310122354.AA20711@wintermute.ncsa.uiuc.edu>
To: kevin@scic.intel.com (Kevin Altis)
Cc: Dave_Raggett <dsr@hplb.hpl.hp.com>, www-talk@nxoc01.cern.ch,
        ebina@ncsa.uiuc.edu
Subject: Re: request for new forms submission consensus
In-reply-to: <9310121747.AA19301@rs042.scic.intel.com>
References: <9310121747.AA19301@rs042.scic.intel.com>

Kevin Altis writes:
> (Dave Raggett writes one level deeper:)
> >Password fields: e.g. <INPUT NAME="f3" TYPE=password>
> >
> >    Like TYPE=text but not echoed to the screen.
> 
> Just as an interface point. We already have the problem of "focus"
> in XMosaic, where depending on configuration, if the user doesn't
> have the pointer over a field, their keystrokes don't go into the
> field. 

This was a design decision, as the alternative is even more confusing
(normal Motif focus tracking and traversal).  As it is, you *always*
just put the pointer where you want to type and then you type.  This
can be overridden at the system or user level using X resources (see
src/xresources.h for the gory details).

> I forsee many X people thinking they're typing in their password,
> only to find out they entered nothing.

Nope, you get asterisks instead of characters -- it's completely
obvious what's happening.

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

No, they're different -- they support explicit specification of toggle
buttons with either one or n of many behavior, with other intermixed
elements, including text.

> >These field types force the author to list each option as part of
> >an HTML list. 

Yup.  I don't see how that's a problem.

> >The browser can't do anything clever like drop-down scrollable
> >combo-boxes.

What?  What's a "drop-down scrollable combo-box", and how would option
menus and lists prohibit their use?

> >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!

Everyone will find what easy to use?

I'm confused...

> >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?

The reason we're doing it in the first place is to adhere cleanly to
the URL schema, which is used as a "level 0" submission method.  

The reason we'll do it for at least one "real" (HTTP/1.0) submission
method -- sending an application/x-www-form-simple body via a POST
message to the server, or something very similar -- is because it is
very close to the URL method, but provides the advantage of shipping
the data as a real message rather than slapped in a URL.

Future submission methods can use better encoding methods if they
want, and I expect they will.

In any case, it really shouldn't matter (except for reasons of
efficiency), since it's just back-end plumbing -- users never need to
see it.

> I don't suppose anyone wants to make explicit support for 16-bit
> characters, maybe UNICODE? UNICODE is biased towards European
> languages (according to my Japanese friends) but I don't think we
> have enough people on this list (if any) versed in Hebrew, Arabic,
> Kanji, etc. to give us direction. OS vendors are quickly adopting
> UNICODE as their standard (some products already use UNICODE
> internally for everything), we at least need to think about it, if
> we want HTML+ to be truly international.

NOOOOOOOOOOOOOOOOOOOOOOOOOOO!  Not a character set debate!  Not here!
I'm still having nightmares from the 822 list debates...

Marc