CSS/DIV - it's just jobs for the design boys, isn't it. The hundreds of hours I've spent debugging DIV/CSS issues, searching the Internet to get some part of markup working with an obscure browser - it drives me mad. You make one little change and the whole layout goes horrendously wrong - where on eath is the logic in that. Spending hours moving something 3 pixels this way then something else 2 pixels the other to get them all to line up. This just seems plain wrong to me somehow. Just because you're a purist and something is "not the right thing to do" doesn't mean you should make use of it to the nth degree and under all circumstances, especially if it makes your life 1000 times easier.

So I've finally decided, purely on commercial grounds, although I keep use to minimum, if I anticipate 20 hours work to get a DIV placed correctly, I'll stick in a table. It's wrong, it upsets the purists, but in most cases it costs less time and is cheaper to manage. I can then concentrate on getting the application working as the customer wants, rather than pleasing the purists. They do pay the bills after all and my argument to a manager enforcing the use of CSS/DIV - I would merely point out the customers pay his salary as well!

所有这些CSS/DIV争论出现的唯一原因是因为CSS的缺点，首先是因为浏览器之间不兼容，如果它们相互兼容，世界上一半的网页设计师将失业。

When you design a windows form you don't try moving controls around after you have laid them out so I kind of think it's strange to me why you would you want to do this with a web form. I simply can't understand this logic. Get the layout right to start with and what's the problem. I think it's because designers like to flirt with creativity, whilst application developers are more concerned with actually getting the application working, creating business objects, implementing business rules, working out how bits of customer data relates to each other, ensuring the thing meets the customers requirements - you know - like the real world stuff.

不要误解我的意思，这两种观点都是正确的，但是请不要因为开发人员选择了一种更简单、更合乎逻辑的方式来设计表单而批评他们。我们常常有比正确使用表而不是div的语义更重要的事情要担心。

在这个讨论的基础上，我将一些现有的tds和trs转换为div。花了45分钟把它弄得乱七八糟想把所有东西都排列整齐然后我就放弃了。td在10秒后回来-工作-立即-在所有浏览器上，没有更多的事情要做。请试着让我明白——你有什么理由让我用其他方式做这件事!

In the past, screen readers and other accessibility software had a difficult time handling tables in an efficient fashion. To some extent, this became handled in screen readers by the reader switching between a "table" mode and a "layout" mode based on what it saw inside the table. This was often wrong, and so the users had to manually switch the mode when navigating through tables. In any case, the large, often highly nested tables were, and to a large extent, are still very difficult to navigate through using a screen reader.

The same is true when divs or other block-level elements are used to recreate tables and are highly nested. The purpose of divs is to be used as a fomating and layout element, and as such, are intended used to hold similar information, and lay it out on the screen for visual users. When a screen reader encounters a page, it often ignores any layout information, both CSS based, as well as html attribute based(This isn't true for all screen readers, but for the most popular ones, like JAWS, Windows Eyes, and Orca for Linux it is).

为此，表格式数据，也就是逻辑上有意义的在二维或多维维度中排序的数据，具有某种标题，最好放在表中，并使用div来管理页面上内容的布局。(另一种思考“表格数据”的方式是尝试以图表形式绘制它……如果你不能，它可能不是最好的表示在一个表中)

Finally, with a table-based layout, in order to achieve a fine-grained control of the position of elements on the page, highly nested tables are often used. This has two effects: 1.) Increased code size for each page - Since navigation and common structure is often done with the tables, the same code is sent over the network for each request, whereas a div/css based layout pulls the css file over once, and then uses less wordy divs. 2.) Highly nested tables take much longer for the client's browser to render, leading to slightly slower load times.

在这两种情况下，“最后一英里”带宽的增加，以及更快的个人电脑缓解了这些因素，但它们仍然是许多网站存在的问题。

With all of this in mind, as others have said, tables are easier, because they are more grid-oriented, allowing for less thought. If the site in question is not expected to be around long, or will not be maintained, it might make sense to do what is easiest, because it might be the most cost effective. However, if the anticipated userbase might include a substantial portion of handicapped individuals, or if the site will be maintained by others for a long time, spending the time up front to do things in a concise, accessible way may payoff more in the end.

不幸的是，CSS Zen Garden不能再作为一个好的HTML/CSS设计的例子。实际上，他们最近的所有设计都使用图形作为部分标题。这些图形文件是在CSS中指定的。

因此，一个网站的目的是展示将设计排除在内容之外的优势，现在却经常犯将内容纳入设计的不可言说的罪。(如果HTML文件中的节标题要更改，则显示的节标题不会更改)。

这只能说明，即使是那些提倡严格的DIV和CSS宗教的人，也不能遵循他们自己的规则。你可以用它来指导你如何严格遵守它们。

I have found that even with the best planning divs come up short in several respects. For instance. there is no way with divs to have a bottom bar that always sits at the bottom of the browser, even when the rest of the content does not go to the bottom of the browser. Also, you cannot elegantly do anything better than three columns, and you cannot have columns that grow and shrink according the the width of their content. In the end, we try to use divs first. However, we will not limit our html designs based on some religious content vs layout ideal.

为了回应“表格更慢”的论点——你考虑的是渲染时间，这是一个错误的度量。通常情况下，开发人员会编写一个巨大的表格来完成页面的整个布局——这大大增加了要下载的页面的大小。不管你喜不喜欢，仍然有大量的拨号用户。

参见:过度使用ViewState

将内容与布局分开是很好的 但这是一个错误的论点;陈词滥调的思考

这是一个错误的论点，因为HTML表格是布局!内容是表中的数据，表示是表本身。这就是为什么从HTML中分离CSS有时会非常困难。您不是将内容与表示分开，而是将表示与表示分开!一堆嵌套的div和一个表没有什么不同——它只是一组不同的标签。

把HTML和CSS分开的另一个问题是，它们需要彼此的密切了解——你真的不能把它们完全分开。无论您做什么，HTML中的标记布局都与CSS文件紧密耦合。

我认为表与div的区别取决于应用程序的需要。

在我们在工作中开发的应用程序中，我们需要一个页面布局，其中各个块将动态地调整自己的大小以适应其内容。我花了几天时间试图让它与CSS和div跨浏览器工作，这是一个完全的噩梦。我们换了桌子，一切都很顺利。

然而，我们的产品有一个非常封闭的受众(我们销售的是带有web界面的硬件)，可访问性问题不是我们关心的问题。我不知道为什么屏幕阅读器不能很好地处理表格，但我猜如果这是开发人员必须处理的方式。