Rich Miller
Rich Miller

Reputation: 810

Is there a maximum number of input controls that can be used on an HTML form?

I have an ambitious requirement for an asp.net 2.0 web page that contains a table (gridview), and each row in the grid contains 6 select (dropdown) controls for data entry. The number of rows that will be displayed is dependent upon the user's search parameters, which are specified in another area of the page. Unfortunately, with the default (and even basic) search parameters specified, the grid could contain several hundred rows. I've noticed that the browser, in this case IE8, starts behaving rather erratically once I reach a large number of rows -- no documented evidence for the number of rows where this begins to be a problem. For example, trying to view the source of the page results in a message from IE stating that there was a problem with the page that forced the browser to reload it, and I never get the source. Obviously the page loads and renders rather slowly also.

I know that my solution is probably going to involve paging the gridview such that it only displays 20 or so rows per page, and I'll have to write code to handle the saving of changes in the dropdown values when the user changes pages. I can probably turn off viewstate on the gridview also. However, the question I really want to pose is this -- has anyone seen a documented rule indicating the maximum number of input controls that an HTML browser form is supposed to be able to contain? I could not find anything on the Internet after doing a search, and I suspect the answer may be whatever the browser can handle based on the machine configuration it is running on. Any rules of thumb you use?

Thanks for any suggestions.

Rich

Upvotes: 1

Views: 2344

Answers (2)

John Rudy
John Rudy

Reputation: 37850

Is there a better design available? What's the usage scenario?

For example, presented with a requirement such as that (which I not-so-lovingly call "Excel on the web"), would it be viable to present a largely read-only dataset, then use jQuery to change a single row to edit controls when clicked? Perhaps even, using some server-side paging, simulating "infinite scroll" while still only loading 20 rows at a time? You can keep the displayed (and DOM-stored) data smaller this way, as well as reduce the number of edit controls in the browser, and on top of all that still provide most (if not all) of the desired functionality.

Generally speaking, tons of input controls visible at once is a usability nightmare, and visually very distracting and difficult to line up/deal with. You're almost undoubtedly better off with a solution like what I've described above. Yes, it's going to be a ton of client-side script, but it'll be way easier on the browser, the users, and ultimately even you.

Upvotes: 1

djdd87
djdd87

Reputation: 68466

It'll pretty much be down to the memory of the client machine. As far as I'm aware there's no actual limit on the number of controls. At the end of the day, it's the browser engine that renders whatever the code dictates. There's no if statement in there saying:

if (this.InputControls.Count > N) then GoBang();

The erratic behaviour you're probably experience with a large number of controls is probably the control rendering itself caused by a hit on the CPU and memory of your machine. You can probably see a difference if you deploy the project and run the site on a few differently specced machines.

But then, do you really need such a massive quantity of controls? The fact you've said you think you should use paging suggests you know you're doing wrong. Do it properly and implement paging or you'll have issues to fix later and whinging clients ;).

Upvotes: 1

Related Questions