[whatwg] Incremental rendering of forms

[Ian Hickson]

On Thu, 26 Aug 2004, Jim Ley wrote:
> > > 
> > > 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.
> 
> Could you please describe a situation where this is using a table 
> semantically correctly, rather than this being a feature due to the poor 
> state of CSS in many UA's.

Of course. Spreadsheets, fill-in receipts, expense forms, invoices, 
product catalogues, inventory forms, etc.


> > > 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
> 
> Right so the requirement here is because of a poor design of the 
> seeding, why don't we fix that instead, seen as the proposal here 
> violates the backwards compatibility requirement, I think it would make 
> much more sense to fix the other new feature.  Especially as that one is 
> easy to fix (provide a mechanism in the seed XML document to specify 
> which form the elements should go in, and have it bound either outside 
> the form, or bound in both with selectors to choose which.)

Are you proposing that the <formdata> element be changed to a 
<documentdata> element with <formdata> children which have IDs to specify 
which form the data should apply to? Or...?

I didn't completely understand you proposal. Could you explain it?


> > 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.
> 
> Which is something that hasn't yet provided us with a problem, and it's 
> made much easier with the submit buttons being able to target different 
> resources.

Yes, WHATWG provides several ways of solving this issue.


> Seen as these things will not degrade in IE6 (let alone other UA's) in 
> any case, I don't really see how this meets the WHAT-WG principles.

Which specific mechanism do you think does not degrade in a useful manner?


> > 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.
> 
> So to simplify the authoring life of some really not to aware users, 
> you're going to allow them to create documents that don't work in all 
> legacy UA's?  I'm sorry I think that is completely ridiculous use case.

Your opinion is noted.


> > If what I included in this e-mail is not enough for you, then I don't 
> > know what else to say, sorry.
> 
> how about just digging out the original discussion of the use case, and 
> post those.

This feature was added to Web Forms 2 months before WHATWG archives 
begin, unfortunately, so the original discussions were not archived. (That 
is one reason why we started WHATWG.) You might be able to find some of 
the discussion on www-archive, if you're lucky.

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