W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2004

[whatwg] Declarative Control of Form Controls vs. One Input -> Many Forms

From: fantasai <fantasai.lists@inkedblade.net>
Date: Sat, 11 Sep 2004 00:55:48 -0400
Message-ID: <41428554.1060406@inkedblade.net>
Ian Hickson wrote:
  >
  > One option would be to make the "form" attribute into a space-separated
  > list, and say that elements belong to all the forms that are given in the
  > list. This would require some pretty big changes to the DOM, but it would
  > work pretty well I think.
>
> Another option would be to provide a declarative way of saying "this 
> hidden input control's value should just be taken from that control over 
> there when you submit", which is easier to define but feels like more of a 
> kludge and is a bit harder to use. However, it does allow us to do things 
> like this, maybe:
> 
>    <label>x = <input type="number" id="theta"></label>
>    <form action="sin.php">
>     <input type="hidden" control="theta"
>            min="-180" max="180" required="required">
>     <input type="submit" value="sin(x)">
>    </form>
>    <form action="cos.php">
>     <input type="hidden" control="theta"
>            min="0" max="360" required="required">
>     <input type="submit" value="cos(x)">
>    </form>
> 
> ...which could be interesting. Basically, when you validate a 
> type="hidden" control, you take the control that its control="" attribute 
> points to, and use its type and value with the constraints defined on the 
> type="hidden" control to find the validity of the hidden control, and if 
> you need to complain to the user, you do so using the original (not 
> hidden) control. There are problems, though, like what happens if the two 
> controls have mutually exclusive constraints, and how do you derive the UI 
> since there might be multiple conflicting constraints (as in the example 
> above, in fact).

This sounds like it could lead to some interesting stuff.

One problem that I've run into and had to resort to scripting for is, for
example

     (*) Edit File: <textarea>
     ( ) Upload File: <fileinput>
     ( ) Enter URL: <textinput>

When one radio is selected, the inputs for the other two should be disabled.
Also, clicking in a disabled input should swap the radio button to enable
that fieldset.

For simple forms, you could handle this by having a separate form for each
one, which is what the W3C validator does and it works very well:

    http://validator.w3.org/

However, if there's a lot of metadata I've entered before / after this main
input set, I wouldn't want to duplicate all of that for each input method.
Using different submit buttons (one for each form) would only make sense if
the submit buttons were closely associated with the upload fieldset, but in
an extended interface, I'd want the submit at the bottom, not in the middle,
of the form.

> I'm preferring the "multiple form" idea here, but really a better idea 
> all round would be best.

~fantasai

-- 
http://fantasai.inkedblade.net/contact
Received on Friday, 10 September 2004 21:55:48 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:20 UTC