This was a design decision, as the alternative is even more confusing
(normal Motif focus tracking and traversal). As it is, you *always*
just put the pointer where you want to type and then you type. This
can be overridden at the system or user level using X resources (see
src/xresources.h for the gory details).
> I forsee many X people thinking they're typing in their password,
> only to find out they entered nothing.
Nope, you get asterisks instead of characters -- it's completely
obvious what's happening.
> >Option lists:
> >
> > These are already supported via TYPE=checkbox and TYPE=radio
> > which support multi and single selection lists respectively.
No, they're different -- they support explicit specification of toggle
buttons with either one or n of many behavior, with other intermixed
elements, including text.
> >These field types force the author to list each option as part of
> >an HTML list.
Yup. I don't see how that's a problem.
> >The browser can't do anything clever like drop-down scrollable
> >combo-boxes.
What? What's a "drop-down scrollable combo-box", and how would option
menus and lists prohibit their use?
> >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!
Everyone will find what easy to use?
I'm confused...
> >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?
The reason we're doing it in the first place is to adhere cleanly to
the URL schema, which is used as a "level 0" submission method.
The reason we'll do it for at least one "real" (HTTP/1.0) submission
method -- sending an application/x-www-form-simple body via a POST
message to the server, or something very similar -- is because it is
very close to the URL method, but provides the advantage of shipping
the data as a real message rather than slapped in a URL.
Future submission methods can use better encoding methods if they
want, and I expect they will.
In any case, it really shouldn't matter (except for reasons of
efficiency), since it's just back-end plumbing -- users never need to
see it.
> 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.
NOOOOOOOOOOOOOOOOOOOOOOOOOOO! Not a character set debate! Not here!
I'm still having nightmares from the 822 list debates...
Marc