[whatwg] Index attribute in formdata
Olav Junker Kjær
olav at olav.dk
Mon Aug 9 09:38:18 PDT 2004
I would like to get rid of the "index" attribute on fields in xml
formdata. I think it binds the server side processing too tightly to the
UI, by relying on the document order of controls.
If I understand correctly, the role of the index is for identifying
controls in the case where controls cannot be identified only by name
(and perhaps value). E.g. when several text field in the same form has
the same name.
I think it is a reasonable trade-off, to require that fields (apart from
check boxes and radio buttons) should be uniquely named (in the form
scope), and that values should be unique for check boxes and radio
buttons with the same name, and for options in a select.
The pay-off would be that form processing is separated from the layout
of the form. The order of the controls can be changed, a radio group can
be changed into a select, a checkbox group can be changed into a select
multiple (and vice-versa) without modifying the server processing. Also,
we could have different UI's to the same processing script, or
differently designed forms could be prefilled from the same UI-neutral
data source.
Duplicate names shouldn't be banned, but in the case of xml formdata
submission, replace=data, or prefilling via the "data" attribute on
forms, behavior should be undefined when controls names are not unique.
(Or it could be defined that if several controls share the same name,
only the first (in document order) would be filled. It would not be very
useful to have duplicate names then, but it wouldn't be an error either.)
Its not a big deal to add the index when xml-encoding form data, it's
more the other way around, when fetching formdata from the server, that
I think "index" shouldn't be required. But I like the symmetry between
the two formats.
Have I missed an obvious use-case for "index"?
Olav Junker Kjær
More information about the whatwg
mailing list