[whatwg] Incremental rendering of forms

[Olav Junker Kjær]

Ian Hickson wrote:
> One example of this kind of case is a form which accepts an address, where 
> the post code can be filled in separately, and where there is a small form 
> for this purpose which can do postcode number lookup.
> 
> Similar things for, e.g., looking up product part numbers while filling up 
> a bigger form.

This is a nice use case, and something that WF2 should indeed try to 
make possible in a natural way.

If I understand correctly, you are thinking of something like this:

Enter address:  [_________]
Enter postcode: [____] [Lookup]
[Send]

When you click "lookup", the address is sent to a postcode-lookup-server 
which finds one or more possible postcodes, which (without a page 
reload) is filled into (or presented as a datalist for) the postcode 
field. When you click "send", address and postcode are submitted to a 
server, which is different than the postcode-lookup-server.

There is several issues here. First is obviously makes sense to think of 
this as two different forms, since they submit different data to 
different servers and the results is handled differently.
A complication is that the address field is really part of both forms. 
If we want the postcode returned from the lookup-server to fill into the 
postcode field, this could be done by replace=data, but (if I understand 
the spec correctly) only if the postcode field is part of the *same* form.
OTOH it will not work either if we have just a single form and different 
action-URI's on the buttons, since the validation constraints are 
different - postcode is required for one server and not the other.

So it seems there is a problem if we want to handle this use case 
cleanly (i.e. without custom scripting), but I don't see the 
form-attribute as an obvious solution.

> I meant not think about the structure. Many authors have told me they 
> don't like having to think about whether the element they are adding to 
> their large document is a child of the <form> element or whether they have 
> to move the <form> element up a few divs (or tables) to make it include 
> the element they just added.

True, since in 95% of cases, there is only one form on the page. But by 
using the for-attribute, you still have to remember the id of the form, 
so this is not easier that just always having a single form-element 
contain the whole contents of body, which is what many authors (and some 
authoring tools!) do.

 > It can also be seen on big sites which may have a form for the whole
 > page, and then small forms in sidebars and the like for, e.g., search
 > forms.

This sounds like a layout problem, though. It's not a problem to have a 
main form and then some other forms in sidebars. You only need the 
form-attribute when you have form fields that is structurally interleaved.

 > Prefilling fields that are not contiguous from two different files
 > (as in:
 >        English [ ............ ]
 >        Norwegian [ ...........]
 >        English [ ............ ]
 >        Norwegian [ ...........]
 >     ...where the English fields are one form, and the Norwegian fields
 >     are another.)

I'm not sure I understand this example, do you want to prefill related 
fields with data from different sources?

Anyway, it's not because I'm opposed to the form-attribute in principle, 
  it's just that I have a strange feeling that the requests for this 
feature is  hiding some other not fully understood requirement.

Olav Junker Kjær