[whatwg] Incremental rendering of forms

[Ian Hickson]

On Thu, 26 Aug 2004, Jim Ley wrote:
>>>> I have had repeated requests for this from Web authors, and received 
>>>> numerous notes praising the idea since publishing a draft with it in.
>> 
>>   * Not changing the content model of HTML element like <table> is quite
>>     important since there are many legacy parsing issues involved
> 
> What?  could you describe an actual use case situation here, that makes 
> this relevant?  (ie a table that semantically is more than one form, and 
> this isn't even a use case, it's a constraint brought about from other 
> use cases perhaps - but which ones?)

Other people have already mentioned this on this list. It is common to 
want to have tables where each row is a separate form.


>>   * 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.)
> 
> Could you explain more what you mean here - what does "prefilling
> fields" and "from two different files" mean.

   http://www.whatwg.org/specs/web-forms/current-work/#seeding


>>   * Having subforms, where you have, e.g., one form covering most of the
>>     page, and then little forms within it.
> 
> could you again explain more about this in terms of a use case, it
> seems like you've gone from the feature to justify it.   Use cases
> involve uses, not functionality.

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.

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.


>>   * Being able to predefine the form submission URIs at the top of the
>>     page and then using them without having to think about what form an
>>     element is in.
> 
> I'm getting even more confused now...  how does having forms not a
> member of their containing form element allow you to "not think about
> form an element is in" it seems to me that it makes it absolutely
> explicit that you know what form an element is in - since you have to
> add it to the element.  I'm obviously mis-understanding.

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.


> Can I ask again for some use cases - those that made you decide "right 
> the solution to that is having form elements in different forms" - 
> rather than ones that you seem to have made up given the premise that 
> such things exist.  Or at the very least expand these so I can 
> understand them.

If what I included in this e-mail is not enough for you, then I don't know 
what else to say, sorry.

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