[whatwg] Incremental rendering of forms

On Sun, 29 Aug 2004, Jim Ley wrote:
> On Sun, 29 Aug 2004 17:41:20 +0000 (UTC), Ian Hickson <ian at hixie.ch> wrote:
> > On Thu, 26 Aug 2004, Jim Ley wrote:
> > > 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.
> 
> They all sound like a single form to me, what's the situation where
> they are multiple forms in seperate rows?

Whether it is a single form or multiple forms is largely an implementation 
detail. That's rather my point.

For example, in a product catalogue you could have one form per row with a 
button at the end of the row for updating just that row. Or orering just 
that product.


> > 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...?
> 
> The problem is not the form updating mechanism, it is the form elements 
> not being a member of their container.

Well, with the current Web Forms draft form controls can be members of 
multiple forms (this was needed to do things such as submitting one half 
of a form to one script to prefill some controls, and then submitting that 
half of the form along with the rest to another scriptwhen the form is 
filled in). So you wouldn't be able to always have the control be inside 
its form(s) anyway.


> > Yes, WHATWG provides several ways of solving this issue.
> 
> Why?  What's the reason for providing more things to implement than is 
> necessary, especially as one method (as we can see from your other post 
> with the example) is far and away superior to the other. Especially as 
> the other also is not backwards compatible with any existing UA.

While the existing UAs will not submit the forms according to WF2 
semantics, it is quite possible to author forms that use these features in 
backwards-compatible ways, by having WF2 UAs submit to one script and 
legacy UAs submit to another, with the legacy UAs getting the entire page 
replaced and the new UAs getting just the new data sent and filled into 
the existing form.


> > > 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?
> 
> bare form elements not in their forms container, form elements not in 
> any form container etc.

Such constructs work fine now, although they cannot be submitted. However, 
it is quite possible to use the WF2 features in question in compatible 
ways, which is what matters.

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

Received on Friday, 12 November 2004 02:37:08 UTC