Question

I have a table which uses a large number of form fields (the HTML variety – i.e. without runat=server). When a postback occurs, these populate the Requests.Form object, and they appear to be inserted in the same order as they’re defined in the page HTML.

Is this behaviour documented and consistent across browsers? I’d like to be able to access the elements by index, which would provide a simple way to find the fields, given that they may be inserted or deleted on the client side.

Edit:

Each row in the table has a hidden field which contains the row ID. This field is named according to the order it was displayed at render time. e.g. the first row has a field like <input type="hidden" name="row0" value="RowID_555252" />, and so on.

Of course the row numbers will be wrong as soon as a row is inserted or deleted in the middle of the table, so the only solution I can think of is to use Javascript to update the row numbers of the entire table whenever the rows move about. The backend would then retreive rows in order by scanning Request.Form for row0, row1, etc until the element is NULL.

Answer 1

Is this behaviour documented …

Yes it is.

The overall algorithm is here: http://dev.w3.org/html5/spec/constraints.html#concept-form-submit and this defines that it uses a form data set built using the algorithm at http://dev.w3.org/html5/spec/constraints.html#constructing-the-form-data-set.

While that algorithm is quite complicated, in essence it says that the form elements will be put into the form data set in node order. That’s not quite the same thing as what they were in the page HTML, for instance, the elements can be moved by JavaScript.

There are further algorithms to turn the form data set into query strings or HTTP content but these too preserve the node order.

There are known to be web pages that depend on this order. (The HTML5 parser has a strange quirk where input elements of most types, placed inside tables but not inside table cells are ejected from the table through a process known as foster parenting, but input elements of type “hidden” are not ejected in this way. This happens because that’s the only way to preserve the legacy submit ordering behaviour of browsers.)

…and consistent across browsers?

The whole algorithm of what gets submitted is definitely not consistent – for example, the submissions resulting from clicking on an input element of type “image” are known to vary significantly.

I believe that the order of the submitted elements may well be consistent across browser implementations. However, I would not rely on it being so, and encourage you to find a more robust solution.