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

On Sat, 11 Sep 2004, fantasai wrote:
>
> 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.

Note that that is what I did in the end, and it didn't require that many 
changes to the DOM (unless I missed some, which is quite possible...).


> > 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. [...]
> 
> 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.

With the multiple forms thing, you could have the metadata in all three 
forms, and then have the above three cases as three forms.

But that doesn't scale. Without JavaScript, we have no way of saying "this 
element is required only if that one is checked", which is something 
XForms does trivially since it can use a separation of UI and data model.

I don't really have a good non-JS solution. Note that the JS solution is 
pretty simple, though, so maybe this is not a big issue.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 16 November 2004 16:58:56 UTC