What mechanism do you want to see for adding some simple extensions to HTML
e.g. to support forms and tables? As you know, I have thought quite a bit
about both of these. Perhaps an experimental browser and sample docs are
needed?
What happened to our ideas for having richer forms with support for
multiple fields? I enclose for you my proposal for extending HTML to
support such forms. An outstanding issue is how you can escape special
characters in search string. I seem to remember that   style
sgml character references are permitted, but this seems to be missing from
the current addressing bnf doc:
http://info.cern.ch:80/hypertext/WWW/Addressing/BNF.html
The following is part of an exchange I had with Dan Connolly in January on
the modifications to HTML needed for such forms:
1) server sends whole form in response to a GET command
2) user interacts with client only to fill out form
3) user instructs client to send completed form to server
4) client sends form contents to server as a query string
5) server executes query and returns results
A smarter/more sophistocated system would include scripts as part of the
queryform document, which apply the constraints locally WITHOUT any network
delays. BUT that seems too open-ended and complex for us to put in HTML for
now!
Best wishes,
Dave Raggett
p.s. Did you get my suggestions for tables in HTML?
---A brief explanation of HTML forms:---------------------------------------
Forms are composed from the following elements
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
These are specified with 4 new tags:
<queryform> appears between <head> and </head>
to indicate that this document is a query form, it
optionally specifies an href for processing the query
<input> boolean values, text, integer and floats
<select> radio buttons and selection menus
<choice> specifying alternatives for <select>
A formal definition is given later on as an extension to the DTD. An informal
definition is given first:
When the browser finds the <queryform> the user can fill in the form
and use it to make a request. The browser should offer a search button or
menu action. The <input> and <select> tags are then used to build the text
search string to send to the user.
The format for sending form contents back to the server has been chosen to
be backwards compatible with older HTTP servers. Thus the search string is
restricted to letters, digits, and chars from the string "$_@!%^&*()."
QUERY ::= FIELD [+QUERY]
FIELD ::= name@value | name@(VALUES)
VALUES ::= value [&VALUE]
e.g. "name@value+name@(value&value)
The use of brackets for multiple values allows servers to continue to treat
the characters &, ^, ! for logical operators.
The tags for form fields look like (more detail in the DTD):
<input name=FIELDNAME type=FIELDTYPE [width=FIELDWIDTH]>
FIELDNAME is a unique identifier for this form
FIELDTYPE ::= "boolean" | "text" | "date" | "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. For line
mode browsers, this requires a cursor addressing functionality, like CURSES.
The "date" format accepts a date in one of the following formats:
o 12th June 1992
o June 12th 1992
o 12/6/92
0 6/12/92
o 12-6-92
o 12 Jun 92
The format is indifferent to MM/DD/YY or DD/MM/YY, and the form's text should
make it clear which is expected.
Multiple choice items need a richer structure, e.g.
<select name=FIELDNAME type=CHOICETYPE [value=VALUE]>
<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. The DTD includes a help parameter which
would permit browsers to offer help on form elements.
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>
-----Additions to HTML DTD for QueryForms----------------------------------
<!-- uses Dan's definition for %URL, %inline and %text -->
<!-- The queryform element needs adding to the spec for HEAD -->
<!ELEMENT HEAD - - (TITLE ? & ISINDEX ? & QUERYFORM ? & NEXTID ? & LINK *
& BASE ? )>
<!ELEMENT QUERYFORM - 0 EMPTY]
<!ATTLIST QUERYFORM HREF %URL; #IMPLIED>
<!-- The following defines the <input> tag with the attributes:
name (required)
unique name used to identify field to server
type (required)
indicates type of input value (boolean, text, date, integer, float)
width (optional, defaults to 20)
width for field in terms of average char width
browsers should allow users to type up to this number of chars
and no more (except for dealing with control keys e.g. backspace)
value (optional, defaults to null or "")
initial value to display in the input field
ok (optional, defaults to yes)
when no, signifies that the current value is in error.
enabled (optional, default to yes)
when no, prevents user from changing this field's value
help (optional, default provided by application)
a URI which would provide explanatory information for this field
-->
<!ENTITY % url "CDATA" -- this is kind of a DTD macro >
<!ELEMENT input - O EMPTY>
<!ATTLIST input
name ID #REQUIRED
type (boolean|text|date|integer|float) #REQUIRED
width NUMBER "20"
value CDATA ""
ok (yes|no) "yes"
enabled (yes|no) "yes"
help %URL; #IMPLIED
>
<!-- The following defines the <select> tag for selection menus -->
<!ENTITY SELECT - - (CHOICE)*>
<!ATTLIST select
name ID #REQUIRED
type (radio|single|multiple) #REQUIRED
value PCDATA ""
ok (yes|no) "yes"
enabled (yes|no) "yes"
help %URL; #IMPLIED
>
<!-- The following defines the <choice> tag which is
used to specify choices for the <select> tag -->
<!ENTITY CHOICE - O (%text; | CHOICE)*>
<!ATTLIST choice
value PCDATA "" #REQUIRED
enabled (yes|no) "yes"
>