views:

939

answers:

8

I've recently been developing an application using tables with a large number (hundreds) of rows. The rows contain tabular data and each row contains two drop down lists as well as link which displays hidden table rows directly below it.

I am currently experiencing lengthy delays when attempting to select a value from the drop down, and when displaying the hidden table rows.

Is the table the source of my problem here?

Thanks in advance.

  • Shawn
+5  A: 

The problem is more than likely the rendering of the controls (100 select boxes) rather than the table layout. How many items are there in the drop down list? Does it perform the same way in all browsers on different operating systems?

Sorry to be so vague but generally tables aren't slow to render, but are looked down upon because of their lack of accessibility (although of course much of the idealism is the fact screen readers don't like them).

Chris S
I second the 'rednering of controls' as the problem. Maybe the hundreds of rows should be reconsidered? An alternative being AJAX based 'load as needed' rows? Just a thought, less scrolling = happy user.
Jakub
+5  A: 

From what I gather, HTML tables can be appear to be slow to render if widths are not explicitly stated. If they aren't, the browser has to finish loading the contents of the cells before it can calculate the correct widths.

MSDN has some information here on their "Building High Performance HTML Pages" article that may help; they suggest the following (regarding tables specifically):

  • Set the table-layout CSS attribute to fixed on the table.
  • Explicitly define col objects for each column.
  • Set the WIDTH attribute on each col.
Donut
+1  A: 

I've not noticed any slowdowns when displaying static tables with a few thousand entries, but adding effects like sorting or dynamic zebra-striping can quickly bog down even a modern browser on a fast computer. Make sure you're not running any JavaScript iterations across the entire table.

John Millikin
A: 

If you know how wide each column should be, try specifying table-layout: fixed in the CSS for the table and see if that makes any difference (it should stop the browser trying to re-render the whole table just because you've toggled visibility on a few rows.)

searlea
A: 

Whatever you come up with, test the approach in a couple of browsers on a couple of platforms, with some slower machines. I once had an app that was speedy everywhere except in Safari for Macintosh. It turned out to be something about the way it rendered the dropdowns. There's just no substitute for experimentation. Uhm, I meant testing.

slothbear
A: 

IE does not handle very large DOMs manipulations well at all.

If you have two selects in each of the rows and a link, and let's assume each select has 5 options that's (((5options + 1select) * 2) + 1 link + 3tds + 1tr) at least 17 DOM items per row. Plus, if I'm not mistaken, ie treats each text item as it's own DOM node. So add another 10 DOM nodes for the drop down text and 1 for the link, that's 28 DOM items per row.

Chad
+2  A: 

I can state from experience that it's almost certainly the dropdown lists that are causing the slowness. Tables with hundreds of rows can render almost instantaneously if they only contain text, but add a dropdown list to each row with just a few dozen options, and now even 50 rows will take a noticeable amount of time.

Try to design around the need for dropdowns in the table rows - if this is a form (and why else would you have dropdowns?), have the user select the row they wish to edit, and then put the editable controls only in that row, either via AJAX if you're into that sort of thing, or a more traditional "detail view" approach.

Martha
A: 

I agree with the others that it's not only your table that is causing the slow loading but the population of the dropdown list as well.

If it helps you can try paginating your table. You can use JavaScript frameworks such as jQuery or extjs for pagination and AJAX.

bob_santos