[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