I am noticing that organizations are looking for products which leverage
their support efforts with common access tools rather than the deployment
of proprietary applications. This is not to suggest that proprietary
application interfaces are ever going away ... rather that the is a
bigger market for casual access to the application which will never be
satisfied by installing the application on every desktop for use a few
times a month.
FORMs capabilities are a very important aspect of this mode of HTML
deployment. To that end we need to provide for rendering which better
mimics user interface characteristics of native MAC/Windows/X applications.
Some issues I've encountered:
a) Alignment the relationship between various elements of the form
including arbitrary text graphics, etc.
b) POPup 'documents' with the source origin with all the flexiblity
we now have for anchors and forms actions. I could offer a bunch
of details but that would extend beyond my intent of introducing and
addressing forms issues. The paradigm is to cover most of the kinds
of situations that window managers use popups for... confirmations,
error messages, etc.
c) Replacement documents ... in many forms applications it would be
useful to return a document which is identified as a replacement for
a document already at the client. I would see implementing this
using logical names so that in reality arbitrary documents within
the use client space could be 'replaced' BUT the basic requirement is
to take partial or incorrect input from a user and regenerate the
document/form with additional information or added error messages,
etc. For example in a customer support application, it might be
reasonable to take the input with just a customer name, have a
search at the server of the customer data base, discover several
Morrises send a pop-up with the choices, have the user request
the details from one or more of the customers listed in the popup
before selecting the correct pre-existing record which would then
be used to regenerate the original form with customer record
information.
d) Required fields ... if the field isn't changed by the user the
submit button won't work (and should be greyed out?).
e) Value edits, like range, format, etc.
On Tue, 7 Feb 1995, Eric Bina wrote:
>
> Well, I am certainly an advocate of putting anything in table cells.
> I do feel they should be complete sub-documents.
I don't think I can agree. Individual form elements need to be in table
cells to achieve the kind of alignment requirement as expressed above.
> The one exception (which is giving me fits) is forms. Nested forms really
> don't make much sense, and I want/need to have a single form span multiple
> table cells.
I agree that nested forms don't make much sense to me but I think I could
define consistent handling. From my requirements perspective, FORMs and
tables are somewhat like orthogonal dimensions of the space which can
overlay each other in the same presentation space. I would envision
creating a FORM which would contain multiple TABLES. The FORM groups
logical input for the server while the TABLE groups logical output
from the server. Ideally, each TABLE within my FORM would contain
the minimum number of cells/nested TABLES to group a set of input fields
and associated text. For example if my application had three input
fields on a line, each with a label above it, I would probably use
a 6 cell table with the first row containing labels and the second
row the input fields (<INPUT>, <SELECT>, <TEXTAREA>, etc.). By using
multiple tables, browsers could better understand what information to
group for scrolling, printed pages, etc.
I also envision a need for multiple FORMs within a table. For example,
two side by side forms (which could contain nested tables).
> I worry that the functionality I want cannot be legally implemented
> in SGML. (see my previous note on this topic for more detail).
I'm far from being an SGML lawyer but I would guess that this notion I'm
advocating of overlaping containers would be difficult to express
as correct SGML. The concept that a TABLE is an output container
and a FORM is an input container where the TABLE elements specify how
it looks and the FORM pieces specify the desired input may provide
a framework with which rationalize the conflicts.
David Morris