[whatwg] Incremental rendering of forms
Ian Hickson
ian at hixie.ch
Fri Nov 12 02:37:08 PST 2004
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list