Let me know if you want me to see how these additions can be formalised
within your DTD, as I know you are being kept rather busy.
--------------
(in: Dan Connolly Tue, 19 Jan 93 Re: INPUT tag - was: Searching)
The client C sends GET foo to server S. S returns:
<HEAD>
<TITLE>Search Template</TITLE>
<QUERYFORM base="medibase">diagnose condition where age is
<recall name="age">and symptoms includes (<if name="headache">
headache</if><if name="blackouts">blackouts</if>)
</QUERYFORM>
</HEAD>
<BODY>
How old are you? <input name="age" type="number"
width="5" help="http:s/help/inputs#age">
<P>
Do you have any of the following symptoms?
<UL>
<LI>headache? <input name="headache" type="boolean" width="3">
<LI>blackouts? <input name="blackouts" type="boolean" width="3">
</UL>
I like the idea, and am glad to see people are now taking an interest in html
and forms. Study of related projects suggests you need several things:
A variety of input fields:
o checkbox (boolean)
o text field
o numeric field (integer and floating point)
o radio-button groups
o one-from-many menu
o n-from-m menu
Summarising what you suggest above:
<input name=FIELDNAME type=FIELDTYPE [width=FIELDWIDTH] [help=HELPUDI]>
FIELDNAME is a unique identifier for this form
FIELDTYPE ::= "boolean" | "text" | "integer" | "float"
The [ ] brackets denote optional attributes.
The width can be optional, since the browser can support sideways scrolling
of the input field when the entry exceeds the current display width.
Multiple choice items need a richer structure, e.g.
<select name=FIELDNAME type=CHOICETYPE [value=VALUE] [help=HELPUDI]>
<choice>item 1
<choice>item 2
<choice>item 3
</select>
CHOICETYPE ::= "radio" | "single" | "multiple"
The choice initially shown is given by the value attribute for the <select>
token, defaulting to the first choice. The value returned is the item text
unless a "value" attribute is defined for that <choice>.
<choice value=VALUETEXT>
I think that <a> tags should be permissible for <choice> text so that you can
provide further explanations upon request for each choice. If there isn't a
value attribute then the displayable text for the anchor would form part of
that choice in the obvious manner.
It is also useful to distinguish form decorations from output fields. I think
this can be adequately handled using the existing emphasis tags though.
How will the <queryform> tag take over from the <ISINDEX> mechanism? Right
now, the browser provides an input field and search button, but I assume that
in future, searchable documents will use the queryform approach instead.
Forms generally involve additional ideas:
a) expressions and queries for output fields
b) edits (constraints) on input field values
c) dependencies between fields
These can all be handled by the server, albeit with a performance penalty as
perceived by the user.
It is important to be able to show the current values as currently being in
error (along with an explanation). For example you could have a form for
configuring a computer system, which gives you choices for the number of hard
and soft drives:
---------------------------------------------------------------------------
* Fixed Drive(s): [2 x 512 Gb disk]
* Soft Drive(s): [1 x 1.44 Mb 3.5" floppy]
(*) Error: you are only allowed a combined total of 2 fixed and soft drives
---------------------------------------------------------------------------
So we need to provide attributes to:
a) signify that the current choice is in error in some way
b) that a given choice is not currently permissible (grayed out)
This can be done with two attributes (both default to "yes"):
ok="yes" | "no" ;; for <input> and <select>
enabled="yes" | "no" ;; for <choice>
Best wishes
Dave Raggett