The range control above will cover sliders, but a "knob" control doesn't
necessarily have continuous steps. For example, the range may be 10 to 100,
but the steps are by 10, not 1, as the control above suggests. We can take
care of that by adding "STEP=number" to the syntax above. Also, some ranges
and steps won't be integers or even numbers ("A", "B", "C"...); does
"range" have to work with just integers?
>Multiline text fields: e.g.<INPUT NAME="f2" TYPE=text COLUMNS=32 ROWS=4>
>
> I am not convinced this needs a distinct name from TYPE=text, since
> the presence of the ROWS attribute is clear enough!
>
>Password fields: e.g. <INPUT NAME="f3" TYPE=password>
>
> Like TYPE=text but not echoed to the screen.
Just as an interface point. We already have the problem of "focus" in
XMosaic, where depending on configuration, if the user doesn't have the
pointer over a field, their keystrokes don't go into the field. I forsee
many X people thinking they're typing in their password, only to find out
they entered nothing. This is not a problem for the Mac or Windows or
character based displays since those interfaces have no concept of focus.
>Image fields: e.g. <INPUT NAME="f4" TYPE=image SRC="map.gif" ALIGN=middle>
>
> These allow users to click on an image/icon within the form. The
> x and y coords of the event are included with the other fields
> only when the image is clicked. Compound names are used to specify
> the coords as parameters to the field, e.g. f4.x=12&f4.y=17
> This paves the way to more complex objects with multiple parameters.
So the coordinates will be integers with "0,0" at the bottom left of the
image/icon? What happened to mapping all coordinates to 0-1?
>Option lists:
>
> These are already supported via TYPE=checkbox and TYPE=radio
> which support multi and single selection lists respectively.
>
>These field types force the author to list each option as part of
>an HTML list. The browser can't do anything clever like drop-down
>scrollable combo-boxes. I felt this was quite reasonable as it fits
>well with paper forms and simple text-only terminals. Everyone will
>find them easy to use!
Will people be able to embed the INPUT lists and other INPUT elements
within tables or any other multi-column or compact setup? Though we have
many of the elements of traditional forms, HTML+ forms don't currently
allow for a compact display, so a single page converted paper form often
takes two or three pages. I believe this is an important issue since the
user of various forms might spend quite a bit of time scrolling (or jumping
via hypertext) back and forth between FORM elements in order to see various
INPUT elements.
>I am worried about using % followed by the hexadecimal code as a means
>of escaping significant characters in attribute values. It seems to
>closely linked to using 7 or 8 bit US ASCII. What should we use instead?
I don't suppose anyone wants to make explicit support for 16-bit
characters, maybe UNICODE? UNICODE is biased towards European languages
(according to my Japanese friends) but I don't think we have enough people
on this list (if any) versed in Hebrew, Arabic, Kanji, etc. to give us
direction. OS vendors are quickly adopting UNICODE as their standard (some
products already use UNICODE internally for everything), we at least need
to think about it, if we want HTML+ to be truly international.
ka