Re: Paul Burchard on HTML 2.0 FORMs
Larry Masinter <masinter@oclc.org>
Date: Mon, 11 Jul 94 18:31:47 EDT
Message-id: <94Jul11.152946pdt.2760@golden.parc.xerox.com>
Reply-To: html-ig@oclc.org
Originator: html-ig@oclc.org
Sender: html-ig@oclc.org
Precedence: bulk
From: Larry Masinter <masinter@oclc.org>
To: Multiple recipients of list <html-ig@oclc.org>
Subject: Re: Paul Burchard on HTML 2.0 FORMs
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: HTML Implementation Group (Private)
> It appears from this example that your design makes the FORM author
> the designer of the client user interface. One of the basic design
> principles of the web is that the client should be smart enough to do
> the interaction with the user in the "best" way, where best is subject
> to local considerations.
You've said this before, but the distinction between "interactive" and
"file" is no more normative about what the client user interface is
than the "size" attribute on input type=text, or, for that matter,
that the data requested is `audio' rather than `text'. (Or, to pick an
example that is even more prescriptive about user interface, <hr>
instead of <br>.)
Asking for data-that-was-prepared-offline ("file") vs
data-that-you-create-at-the-time-you-fill-out-the-form ("interactive")
seems like it is generic, transcends any particular kind of user
interface design, and a distinction that holds independent of the
platform and user interface.
As for PROPOSED features, I'd propose that HTML 2.0 contain elements
that are generally implemented, the PROPOSED parts of the
specification contain only those things that have at least one
demonstration implementation, and that you omit those things for which
there are no working examples. I'm assuming SCRIBBLE and AUDIO have no
working examples, or else we would have resolved more quickly the
question of how the resulting data gets communicated back when the
form is submitted.