html元素的数量是否有限制，浏览器可以毫无问题地显示？
基本上我有一张巨大的桌子，随着用户向下滚动（自动预加载后续行），桌子变得更大。在某些时候，浏览器变得呆滞，当我点击或尝试滚动时，它会开始挂起一会儿，变得越迟缓，它的行数越多。我想知道页面可以容纳的元素数量是否有限制？或者，也许这只是我的JavaScript泄漏的地方（尽管我只有一个事件处理程序，附加到表的tbody - 和一个脚本，分析冒泡的mousedown事件）。html元素的数量是否有限制，浏览器可以毫无问题地显示？
更新：延迟加载行的千后变得明显。滚动的速度本身是相当可忍受的，但是例如突出显示点击行（在tbody上的单个事件处理程序的帮助下）是痛苦的（它需要至少2-3秒，并且延迟随着行数增长）。我观察到所有浏览器的延迟。这不仅是我，而且几乎每个人都访问了该页面，所以我认为它在一定程度上影响了每个平台。
更新：我想出了简单的例子在这里：http://client.infinity-8.me/table.php?num=1000（你可以把你想NUM任何数字），基本上呈现一个表NUM行和具有连接到一个单一的事件处理程序父表。我应该从中得出结论，实际上，由于子元素数量的原因，没有明显的性能下降。所以它可能是其他地方的泄漏:(
我不认为这是标准所定义的限制。在每个浏览器实现中可能存在硬编码的限制，但我可以想象这个限制可能会有数十亿个元素。另一个限制是可寻址内存的数量。
要解决您的问题：除了向下滚动时自动加载元素，您还可以自动卸载从屏幕上滚动的元素。那么即使滚动很多，你的程序仍然会很快。
您可能还想考虑一个替代接口，如分页。
我想卸载是选择（至少它会与我没有大的重写）。但我想知道到底发生了什么，将来可能会出现这种情况，这可能是其他问题的主题，我想知道这个问题是否对单个页面内的元素数量有任何限制。能够近似估计可能的边界。 – jayarjo 2010-07-04 12:47:11
我不认为有限制 但是，HTML文件越长，您的计算机将需要的资源越多，但表必须非常大被使用然后...
该限值确实由用户代理和客户机确定的。HTML，以相同的方式如XML，是数据的树格式。因此，以上的元素，进一步通过树客户端浏览器必须搜索才能呈现页面
我遇到了在div中添加超过100个表格的问题（作为旧的解决方法，IE6不能动态创建表格元素）
什么是问题与IE6不能动态地创建表格元素？我知道有两个问题：1，如果你使用'.appendChild（）'创建，你需要确保你有/添加'tbody'，如果你想添加'TR'行。第二个是你不能使用innerHTML，例如'TableElem.innerHTML ='
IE 6不允许使用document.createElement（“table”）。我认为这也是有一个tbody元素的问题。这是相当一段时间以前（我们不喝9岁的牛奶：P）。 – Russell 2010-07-05 23:32:26
如果你在每个表行上都有JS，那么旧的计算机将无法处理它。对于HTML本身，你不应该太担心。
你应该担心的事实是正常的人，不喜欢大的表这就是分页是为制作。使用分页将其分开以提高可用性或其他问题。
认为没有页面，但一个大的页面，你想读它的书的？即使你的眼睛（在我们的情况下，PC）可以处理它。
您使用的是什么浏览器？有些浏览器可以比其他浏览器更好地处理事情 - 例如，如果您使用的是IE浏览器，如果浏览器缓慢，我不会感到惊讶 - 它不会处理JavaScript事件以及基于Webkit的浏览器。
另一件事显然是你的电脑（RAM和CPU）。但说实话，大多数电脑应该没有问题，除非我们说10000+行...甚至然后...
你能发表一些代码吗？
鉴于存在大量浏览器和渲染引擎，并且所有浏览器和渲染引擎都具有不同的性能特征，并且考虑到这些引擎在性能方面稳步提高，并且计算机硬件始终变得更快：否，没有固定的上限什么浏览器可以处理。但是，特定版本的浏览器在特定硬件上存在目前的上限。
如果你没有定义更多你的硬件和浏览器是否很难帮助你。另外，如果你没有发布代码，没有人可以提出有关Javascript可能的性能的建议。即使它只是一个事件处理程序，如果它无限循环或者如果它调用每个元素，它可能会显着减慢渲染过程。
不知道内存或CPU的使用情况，它预先加载后文件的实际大小是多少？
如果你的表格真的很大，你可能会迫使你的用户下载兆字节的数据 - 我发现有些机器在2-4MB数据后往往会挂起。
它动态加载数据，通常它并不意味着是有限制的（因为我没有意识到任何限制，我想如果有任何限制，他们将超过数百或数十亿）。现在，在1或2千行后，挂起变得明显。 – jayarjo 2010-07-04 12:33:27
你应该看的另一件事是表格大小。如果您的桌面使用table-width:auto;样式，则浏览器必须测量表格中的每个单元以调整其大小。这可以变得非常缓慢。
取而代之的是，使用table-width:fixed来选择一个固定宽度或至少使用表格样式。
取决于。例如，IE在加载所有内容之前不会开始渲染表格。所以如果你有一个5000行的表，它需要加载所有5000行数据，然后再渲染它，因为其他浏览器一旦有部分数据就开始渲染，并随着表的增长调整一点（如果需要的话）。
一般来说渲染速度会随着节点数量的减少而增加节点的复杂度......避免嵌套的表格，如果可能的话尽量将大型表格分成几块......每100行（如果可能的话）
我相信IE，就像所有其他浏览器一样，如果您在html中指定了列宽，下载过程中会呈现表格。如果未指定宽度，则浏览器必须下载整个表格才能计算宽度。 – PauliL 2010-07-04 13:58:42
不正确。你可以通过创建一个表（比如20行），指定任意宽度来在行为中看到IE的行为，并且在表的'td'标签的随机位置用'alert'（'X行' ）;'。在表格的单个部分**呈现之前，您将在IE中看到警报（所有这些警报）。如果您在Firefox，Chrome，Safari或Opera中加载此页面，则会在表格呈现时同时收到警报。 – scunliffe 2010-07-05 02:27:57
世界上真的没有理由在单个页面上发布整个大型数据集。如果要求为用户提供所有的数据，那么你应该将它导出到一个文件，该文件可以通过比浏览器更好的软件读取。
相反，我建议你制作一个AJAX驱动的页面，让用户看到一部分数据，如果他们需要查看更多信息，那么只需下载数据集的那部分并替换当前数据集这一页。这是分页。谷歌搜索就是一个很好的例子。
如果有任何限制，它取决于浏览器。但是问题你没有限制，因为浏览器仍然显示页面。
大表总是浏览器的问题。渲染一张大桌子需要很多时间。 因此，通常是好主意，将大表分成较小的表。
此外，您可能想要指定列宽度。没有这一点，浏览器必须先下载整个表格，然后才能计算每列的宽度并呈现表格。如果您在HTML代码中指定宽度，则浏览器可以在页面仍在下载时显示该页面。 （注意：指定整个表格的宽度是不够的，需要指定每列的宽度。）
如果使用Javascript将单行添加到大表中，浏览器很可能必须呈现整个表再次。这就是它变得如此缓慢的原因。如果你有更小的表格，只需要再次渲染一个小表格。更好的是，如果你一次加载一个子表而不是一行。
但最有效的方法是将数据分成多个页面。用户也可能更喜欢这一点。这就是为什么Google在每个页面上只显示如此多的结果的原因。
为完整答案发布您的代码/网址（这是所有猜测没有） – galambalazs 2010-07-04 12:33:53
好吧，我不能发布链接到原始页面，因为它不公开。我会想出一些示例页面。 – jayarjo 2010-07-04 12:45:39
我会**不同意**在IE **中没有明显的性能下降**。如果将它设置为1，然后重置为2000，那么在表开始渲染之前有2-3秒的延迟（因为如我在下面的答案中所述，IE在等待渲染之前等待加载整个表） – scunliffe 2010-07-05 12:26:43