In the 500.000 rows example the scrollbar fails to properly reach the bottom of the table in Firefox 37 and several elements at the tail end position wrongly due to rounding error. In Internet Explorer 11, content rendering is cut-off halfway down the list.
Browser engines impose hard limits on the maximum size of DOM elements, on a Win7/x64 system these are:
Webkit/Blink
Gecko
Trident
134,217,726 px
10,737,418 px
17,895,697 px
Said demo reports a height of 1.78932e+7px on the computed style of the top spacer element in Firefox, which confirms that you are exceeding that limit.
Cutting the spacer elements up into separate
elements may fix Firefox, but will probably not fix IE.
Sadly, the current implementation would have to be redone from scratch to fix this: you cannot use real table markup as that is apparantly always drawn in unison into the same layer, which would still grow to be too tall.
The only way to get this to work is to use an absolutely positioned surface that is super-imposed on top but outside of the element(s) used to stretch the viewport's contents to the desired height.
I believe that with real data in production no one reach the browsers limitations, correct me if I'm wrong.
500.000 rows is not necessarily that big a set in certain BI applications. Sure you usually slice and rollup on data; but some users are still stupid enough to insist on pricking data somewhere inside the whole, raw, fully expanded thing. (Lord knows why, but they do.) And then your application breaks.
(Note also that if you support on-demand loading of 'pages' of data as they become necessary, such a UI needn't be stupid slow on the initial uptake of data either.)
I do agree that in practice, it should be safe for most applications. But maybe, you want to add some precautionary logic to ensure you don't end up thrashing an app. Or at the least you want to document the limitation. (And adjust the demo so it doesn't actually break on two-third of the browser spectrum. A broken demo is kind of a bad calling card...)
I want to keep this plugin tiny so I won't implement hacks to bypass browsers restrictions. If someone would need to handle millions of rows they could use more featured plugins, like slickgrid. Although it was good idea to add note about browsers limitations, just added that, thank you. And let's leave 500,000 rows in tutorial as it is, people need to see real plugin's behaviour they deal with.
In the 500.000 rows example the scrollbar fails to properly reach the bottom of the table in Firefox 37 and several elements at the tail end position wrongly due to rounding error. In Internet Explorer 11, content rendering is cut-off halfway down the list.
Browser engines impose hard limits on the maximum size of DOM elements, on a Win7/x64 system these are:
Said demo reports a height of
1.78932e+7pxon the computed style of the top spacer element in Firefox, which confirms that you are exceeding that limit.Cutting the spacer elements up into separate
The only way to get this to work is to use an absolutely positioned surface that is super-imposed on top but outside of the element(s) used to stretch the viewport's contents to the desired height.
Good research, thanks.
500.000 rows was done for demonstration purposes. In fact I do not think anyone need to display so much data, it is really too much.
I believe that with real data in production no one reach the browsers limitations, correct me if I'm wrong.
500.000 rows is not necessarily that big a set in certain BI applications. Sure you usually slice and rollup on data; but some users are still stupid enough to insist on pricking data somewhere inside the whole, raw, fully expanded thing. (Lord knows why, but they do.) And then your application breaks.
(Note also that if you support on-demand loading of 'pages' of data as they become necessary, such a UI needn't be stupid slow on the initial uptake of data either.)
I do agree that in practice, it should be safe for most applications. But maybe, you want to add some precautionary logic to ensure you don't end up thrashing an app. Or at the least you want to document the limitation. (And adjust the demo so it doesn't actually break on two-third of the browser spectrum. A broken demo is kind of a bad calling card...)
I want to keep this plugin tiny so I won't implement hacks to bypass browsers restrictions. If someone would need to handle millions of rows they could use more featured plugins, like slickgrid. Although it was good idea to add note about browsers limitations, just added that, thank you. And let's leave 500,000 rows in tutorial as it is, people need to see real plugin's behaviour they deal with.