奇怪的表格布局：已修复； “错误”在 WebKit 上
我正在根据自己的需要构建网格组件，其中包含可排序的列、行等。现有的组件要么不适合我的需求，要么太重。我刚刚开始调整大小的列，突然 WebKit 出现了无法解释的异常情况。虽然 table-layout:fixed; 在所有其他浏览器（甚至 IE）上都能完美运行 Safari/Chrome 让我很头疼。
这是我到目前为止所写的： TSort Embriyo
As您可以看到它创建了两张表 - 一张用于标题，一张用于正文以及它们周围的一些包装。然后它尝试使用table-layout:fixed，因为它更适合动态网格概念。对于table-layout:fixed来说，表格的宽度至关重要，此外我的所有单元格（td/th）都有overflow:hidden， white-space:nowrap 和 text-overflow:ellipsis 更好地模仿网格外观。
现在“错误” - 两个表格的构造方式相同，单元格和表格的宽度由相同的函数计算和设置。这个“错误”是无法解释的，因为我使用的方法对于顶部表格可以按预期工作，但对于底部表格则失败。基本上它的行为就好像我没有分配给它宽度一样。但你可以在 Web Inspector 中看到它肯定有宽度......所以......嗯？
我尝试了一切，我交换了功能，我删除了顶部表格，我尝试按照构建顶部表格的方式构建底部表格。但它一直失败。但是，当我直接将生成的表代码复制/粘贴到页面中时，它开始工作。所以我的猜测是它具有表格的动态特性。但为什么它在最上面的桌子上起作用呢？
通过创建具有预先分配宽度的表格元素，我能够摆脱这个“错误”。但这并不能解释这种奇怪的行为，不是吗？
I'm building grid component for my own needs with sortable columns, rows, etc. Existing ones either were not suiting my needs or were too heavy. I just started on resizable columns when realy unexpectedly WebKit has hit my with unexplainable anomaly. While table-layout:fixed; worked perfectly on all other browsers (even IE) Safari/Chrome gave me a headache.
Here is what I wrote so far: TSort Embriyo
As you can see it creates two tables - one for headers and one for body and some wrappers around them. Then it tries to make use of table-layout:fixed, since it better fits dynamical grid concept. For table-layout:fixed it is crucial for table to have a width, in addition to that all my cells (td/th) have overflow:hidden, white-space:nowrap and text-overflow:ellipsis to mimic grid appearance better.
Now the "bug" - both tables are constructed the same way, width of the cells and of the table is calculated and set by the same function. The "bug" is unexplainable because approach I use works as expected for top table but fails for bottom one. Basically it acts as if I had no width assigned to it. But you can see in Web Inspector that it definitely has the width... So... huh?
I tried everything, I swapped functions, I removed top table, I tried to built bottom table the way I build top table. But it keeps failing. However when I copy/paste generated table code into the page directly it starts to work. So my guess here is that it has something with dynamical nature of the table. But why it works on the top table then?
I was able to kinda get rid of this "bug" by creating table element with pre-assigned width. But it doesn't explain the weird behavior, does it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我找到了解决办法 - 仍然不确定到底发生了什么。
将：
移至
construct函数的底部（当然，将其从populate中删除）。您可能已经注意到，在我的之前的测试中，我添加了一个“数据”选项。我发现使用该数据从
_init调用populate效果很好 - 除非我使用setTimeout来延迟调用 - 就像 ajax get 那样 - 并且然后它也扭曲了桌子。所以它与时间相关——也许 WebKit 正在做一些有趣的事情来优化渲染。编辑
好的，我有一个理论；）
当创建表并在同一函数中添加所有行时，CSS 将在函数调用结束时应用 - 此时
table-layout:fixed项仅适用于表格具有宽度的情况。如果创建了表格，并且对其应用了CSS（即因为控制已通过ajax或
setTimeout返回到浏览器），当它没有宽度时，则固定布局具有没有效果。随后添加项目甚至设置宽度不会导致CSS被重新评估。I found a fix - still not sure exactly what's going on.
Move:
to the bottom of your
constructfunction (and of course remove it frompopulate).You might have noticed that in my previous test I added a 'data' option. I found that calling
populatefrom_initwith that data worked fine - unless I usedsetTimeoutto delay the call - like the ajax get does - and then it too distorted the table. So it's timing related - perhaps WebKit is doing something interesting to optimise rendering.EDIT
Ok, I have a theory ;)
When the table is created and rows are added all within the same function, css is applied at the end of the function call - and at that point the
table-layout:fixeditem will only apply if the table has a width.If the table is created, and the css is applied to it (i.e. because control has returned to the browser via e.g. ajax or
setTimeout), when it doesn't have a width, then the fixed layout has no effect. Subsequently adding items and even setting the width does not cause the css to be re-evaluated.