I agree.
> and yet the ability of vendors is still stuck in text based, point and click
> links, and the most simple of fill out forms.
> ...
> 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
You have missed the most important reference. ANSI already has a Forms
Interface Management Standard ("FIMS") which was implemented almost fully
in DECforms and I think other products by now.
It's model of the form includes field- and form-wide value constraints,
mechansims for checking other types of integrity, and it covers a very
broad range of multiple-choice selection mechanisms. Even if its model
of the form is a little too 'intelligent' for HTML, it's specification
should be one of the first things investigated... work already done for
us by a very thorough committee...!
> 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.
I agree. But to nourish it, we should first figure out the logical limits
of its growth...then figure out what to add first.
> Ideally <FORM> could be revamped so instead of just text interaction
> arbitrary media types could be plugged in... chew on that for a bit.
Not sure how far FIMS went in this but the standard is recent ('91 I think)
so there is at least a mechanism for it proposed.
-- Craig Hubley Business that runs on knowledge Craig Hubley & Associates needs software that runs on the net craig@passport.ca 416-778-6136 416-778-1965 FAX Seventy Eaton Avenue, Toronto, Ontario, Canada M4J 2Z5