Re: Cougar: ideas for <A>,<INPUT>

galactus@stack.urc.tue.nl (Arnoud "Galactus" Engelfriet) wrote:
|>In article <9607291251.ZM2693@gaia.ckm.ucsf.edu>,
|"Marc Salomon" <marc@ckm.ucsf.edu> wrote:
|> Suggestions for <INPUT>:
|>
|> FOR      - IDREF pointing to the form to which this <INPUT> belongs.  Allows
|> for
|>            placement of <INPUT> elements outside of <FORM>...</FORM>
|container.
|
|Why would you want to do that? Is this an attempt to work around the
|nested form problems? If so, nice idea. I'm not sure how well it would
|work, though.

In the case where one had a set of buttons that might be placed regularly
throughout a long document, it would be nice to have the repeating buttons
reference the original form.  If one builds application interfaces from
entity-like pieces placed by non-technical folks, you can never be sure exactly
where in the grand structure the particular piece will be placed by the
template designer, and this kind of linkage would be useful.  I've run up
against limitations like this over the past few years and had to resort to
contortions and unreasonable constraints on my page designers to get the effect
We'd wanted.

I've also been thinking about the notion of nested forms and form submission
inheritance.  It would be nice for contained forms to (not) inherit the
submissions of container, contained or peer-level forms, perhaps through a
request encoded in multipart of some sort, but I've not had the time to think
it though the potential chasms I'd encountered early on.  Any takers?

Nested forms, form submission inheritance and DEPENDS that you mention might
work interestingly together.  But I believe that there would need to be some
more complex dependency logic involved in DEPENDS than checking the selection
of a checkbox or radio button...you'd need to account for selected OPTIONS etc.
 It'd also be nice to enable whole nested forms based on a selection in a peer
or superior form.  This would sure be nicer than the inline </\SCRIPT/\> mess.

In looking at identifiers for referencing elements, there is CLASS, mainly used
for style, and ID which is SGML doc-wide unique identified.  There probably
should be a generic, non-style specific classing mechanism (ROLE?) that could
express structural relationships between elements (mostly, but not only FORMs
and their contents).

Scripting can do wonders for the document-level GUI, but the beauty of forms is
that they've put portable elegant GUI design in the hands of mere mortals.
 This is a Good Thing and should be extended, regardless of the (de)evolution
of scripting.

-marc

--

Received on Tuesday, 30 July 1996 14:52:04 UTC