- From: Olav Junker Kjær <olav@olav.dk>
- Date: Sat, 15 Jan 2005 22:00:02 +0100
Ian Hickson wrote: > On Thu, 9 Dec 2004, [ISO-8859-1] Olav Junker Kj?r wrote: >>Well, I still haven't seen any convincing use case for the >>form-attribute (but maybe its just because its blindingly obvious?). > > There's a demo on the WHATWG site that uses it: > http://whatwg.org/demos/multiform-01/ > > Another example is given in the spec, namely having one form per row in a > table. I suspect that I'm beating a dead horse or something here, but for what its worth, I dont find these two use cases entirely convincing. If you want to edit tabular data, you would either want a single row to be editable at a time, in which case you need only one form, or you would want all rows to be editable at the same time, in which case you still only need one form, since you want to be able to submit all the changes. Having one form per row requires a separate submit button per row, but then, when submitting one row, changes in any other row would be lost. This doesn't seem like good UI to me. Maybe the desire for this feature is really a concern about bandwidth when editing and submitting large amounts of tabular data? But thats a different problem (if it is a problem at all). The other use case is quite realistic though, and shows a genuine need for a more flexible form model. However the solution of letting a field be part of several forms at the same time does not really solve the problem. If there are no validation constraints, it's much easier to just have a different action attribute on the "lookup" buttons. But if there are validation constraints on the fields, neither solution works. For example, the product-code field would typically be required with respect to the main form, but optional with respect to the lookup form, but the reverse might be the case with the product-name field. So I dont think the form-attribute is completely justified by these two use cases. regards Olav Junker Kj?r
Received on Saturday, 15 January 2005 13:00:02 UTC