Here are some of them condensed:
Actually, we implement multiple pages to get around the problem you
describe. (The back end is a simple Perl script; each subsequent page
that the user chooses has INPUT TYPE=HIDDEN tags to preserve "state.")
So the first page would have a list of cake/soda/ice cream. Click
done.
The second page says whatever is appropriate based on the prior choice.
And so on. It's not as elegant but it's supportable on any platform.
(Mind you, I'd like nested SELECTs as well.)
Kevin Ruddy <smiles@nmc.ed.ray.com>
Can you say "kludge?" (Definitely not his fault :-) ) This is an awkward
solution to an unaddressed problem. Kevin shouldn't have to do this, and his
customers shouldn't be subjected to it.
We faced the same kind of problem. Our solution was only two levels,
but you could extend it to arbitrarily many (and it gets clunker to
use for each one).
Each level shows up as a <select> in the form. You send out the form
with a hidden field saying what the currently selected first level is,
and the second level <select> having the appropriate list for that
field. When it comes back, if the first level hasn't changed, you
select the option chosen by the second level. If the first level has
changed, you give them back a new form, with the new first level in
the hidden field, and the option list in the second level being the
appropriate one for the new first level.
Making an n-level selection requires N transactions - one at each
level. For two levels on the local network, it's works ok. For three
on a transatlantic link, it'd probably sucks.
Personally, I'd like nested options as well (at least one browser no
longer throws up when it runs into them, thanx to my trying them out).
However, I also want a presentation that works on pretty arbitrary
output devices.
Mike Meyer <mwm@contessa.phone.net>
Try doing this with with an automotive parts book and your programmer would
probably quit.
And again, the customer should not have to worry about these things.
As someone writing forms for a commercial vendor I am deeply frustrated at the
lack of the
form abilities. If the web is to provide capabilities for vendors then the
whole form category needs some rethinking. Web use is taking off like a rocket
and yet the ability of vendors is still stuck in text based, point and click
links, and the most simple of fill out forms.
If you want vendors on the Web then you need to provide them with at least the
capabilities that the
simplest PC GUIs already provide.
Which brings me to the best suggestion I got:
I think it would behoove someone (preferably someone with a lot of
experience with HTML forms, as well as other GUI-building tools like CD
ROM authoring tools or Motif/X) to take a look at the current <FORM>
mechanism, take a look at the HTML 3.0 proposal (particularly file
upload, "scribble", and such - admittedly it doesn't add much) and then
step back and design a more comprehensive set of improvements and new
functions to <FORM>, and present that as a proposal. <FORM> is one of
the most undernourished parts of the HTML spec.
Ideally <FORM> could be revamped so instead of just text interaction
arbitrary media types could be plugged in... chew on that for a bit.
Brian Behlendorf <brian@organic.com>
I invite the html working group to respond to these comments and concerns.
Matt MacDonald "The opinions expressed are strictly my own and do not
Intel necessarily reflect those of Intel Corp. or its
management"
FES Customer Support group
mmacdona@pcocd2.intel.com