Re Improvements on HTML
Dave_Raggett <dsr@hplb.hpl.hp.com>
From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-id: <9304071126.AA25551@manuel.hpl.hp.com>
Subject: Re Improvements on HTML
To: www-talk@nxoc01.cern.ch
Date: Wed, 7 Apr 93 12:26:40 BST
Cc: timbl@www3.cern.ch
Mailer: Elm [revision: 66.36.1.1]
In <9304061648.AA02068@www3.cern.ch> Tim says
> There have been a lot of improvements proposed for HTML.
> - Various forms of includion of graphics
> - Tables
> - Forms
> I think we should get some concrete proposals for an HTML2 out
> onto this list. This would bring us closer to a DTD for the
> new thing, which would allow everyone to go out and
> implement it.
Glad to hear you say it!
> The new format should of course be a superset of HTML. The first
> thing it should include is indefinite nesting of constructs
> which is not allowed in HTML.
Some guidelines would be useful here, e.g. can you nest OL or UL in the
DT glossary text in a DL list, or what about OL within UL within a DL list?
What level of nesting should browsers aim to show effectively?
For formal presentation as an elective Internet standard we should aim to
be as precise as possible, e.g. via accurate DTD's and a range of examples.
I there enclose a DTD fragment with my proposal for forms.
> To kick off the discussion, I propose for the forms part the
> following
> FIELDS
> ======
> <FIELD NAME="f1" FIELDTYPE=TEXT MAXLEN=40> </FIELD>
Tim, er did you receive my message with a detailed suggestion for forms?
My practical experience with building hypertext/forms based interfaces
for sales staff etc. has shown the value of:
o to be able to freely embed fields in other
textural or graphical backgrounds
o the need for fields with constrained types
e.g. dates, booleans, integer ranges, free text, ...
o the need to initialise fields with default values
o the ability to highlight fields as being in error
o the ability to disable the field to prevent further change
o the need for one-from-many AND many-from-many menus
o giving authors control over the realisation of such menus
e.g. radio buttons, drop down, and permanently visible lists
Fields showing derived values, (e.g. a total figure in an expenses claim),
and arbitrary constraints between different fields can be handled by the
server. In this way you avoid can the need for a scripting language.
If the user sets a field to an incorrect value, the ability to highlight
the field makes it practical to draw the user's attention to that field
with the implication that its value should be changed. An accompanying
error message can be given as part of the surrounding text.
Similarly, it is often the case that given certain settings of fields, that
other fields cannot be changed. To make this obvious you should change the
appearence of these fields. In my browser, I show fields with a darker colour
when they accept input and the lighter window background colour when they are
read-only. Clicking the mouse over a read-only field has no effect.
As an author I want control over how a selection menu appears. When there are
few choices, radio buttons or lists work well. When there are lots of
selection fields it is strongly desirable to be able to use drop-down
selections, which appear in the body of the form as a button and a box
showing the currently selected value(s) for that field. Clicking on the
button causes the list of possible choices to appear, with the current
selection highlighted in some way.
Essentially we need two tags, one for input fields and one for selections.
These should be able to be placed freely with other HTML tags, so that you
could embed fields in a preformatted text if you need tight control over
the appearence. You could also put input and (dropdown) selection fields in
glossary lists.
Input Fields:
============
These fields have the following attributes:
o field name - used to identify the field's value to the server
o field type - boolean, text, date, uri, integer, float
o field width (optional) giving maximum length of field value
o field status (optional) ok (the default), in error, read-only
o initial value (optional)
Selection Fields:
================
These fields have the following attributes:
o field name - used to identify the field's value to the server
o field type - one-from-many or many-from-many
o field appearence (optional) radio, list, drop-down
o field status (optional) ok (the default), in error, read-only
The field appearence is a hint to the browser of how the author intends the
field to be displayed. For a drop-down field it would also be desirable to
be able to suggest the maximum size for displaying current selections,
particularly with many-from-many fields.
The set of possible choices can be specified as Tim points out with the
<LI> tag without the need for a new tag.
Here is my suggested DTD for the <input> and <select> tags. I prefer
these names as they seem more verb-like and appropriate than <field>
and <radio>.
<!-- INPUT tag
o The field name and type are required.
o The width, status and value attributes are optional.
o Boolean fields have values "yes" or "no"
o Date fields have values matching:
"19th January 1992"
"19 Jan 92"
"19 Jan 92"
"19/1/92" with '/' or '-' as separators
"1/19/92"
o URL fields have values corresponding to existing standards
for universal resource locators
o values should be enclosed on "quotes"
-->
<!ELEMENT INPUT - O EMPTY>
<!ATTLIST INPUT
name ID #REQUIRED
type (boolean|text|date|url|integer|float) #REQUIRED
width NUMBER "20"
status (ok|error|frozen) "ok"
value CDATA ""
>
<!-- SELECT tag
o The field name and type are required.
o The showas, width, status and value attributes are optional
o selected values are indicated with the LI tag
-->
<!ENTITY SELECT - - (LI)*>
<!ATTLIST SELECT
name ID #REQUIRED
type (single|multiple) #REQUIRED
showas (radio|list|dropdown) "radio"
width NUMBER "20"
status (ok|error|frozen) "ok"
>
<!-- LI tag
When the LI tag appears inside a <SELECT> ... </SELECT>
the text following the LI tag is treated as a possible choice
(up to the next LI tag or the terminating end-select tag).
The LI tag is extended to indicate whether this alternatative
has been selected or not, e.g.
<LI SELECTED> versus <LI>
Strictly speaking I am not sure if this is valid SGML, you should
probably always give an attribute value as in <li selected=yes>
but this seems excessive ...
-->
<!ELEMENT LI - O EMPTY>
<!ATTLIST LI
selected (yes|no) "no">