为什么使用 DIV 或 span 标签“更好”？比使用表格布局？
可能的重复：
为什么不在 HTML 中使用表格进行布局？
为什么使用使用 div 定义所有内容（容器、标题、内容等）的标记比使用表格更好？我知道当你使用表格构建页面时：看起来很难看，嵌套时看起来更丑，因为废话量更大 - 页面加载时间稍长，代码可读性较差。
但。使用表格是如此简单，并且可以节省大量时间来完成看似简单的事情，但需要注意的是，要使其在所有浏览器上工作。
我要问的是，一个有点复杂的布局（或者任何通常仅用 div 和 css 不容易完成的布局）是否可以通过混合表格和 css 以及一些包装所需元素的 div 来最好地解决（处理嵌套），这样您就可以快速开发您的应用程序，而不用担心它在不受支持的浏览器上看起来像垃圾？
*！编辑！ * 我也完全同意，是的，表格是用于表格数据的，就语义而言，我觉得我应该使用什么都不做的标签，然后命名它们并设计它们的样式，但对于我来说，我发誓很多次快速地快速构建一些东西，使用表格 BEATS 试图完美地设计它以在所有浏览器上工作。
Possible Duplicate:
Why not use tables for layout in HTML?
Why is using markup with divs defining everything (container, header, content, etc) BETTER than using tables? I understand that when you build your page using tables it: look ugly as hell, look even UGLIER when nested, because of the higher volume of bullshit - slightly higher page load time, and less readable code.
BUT. Using tables is so easy and saves SO much time in trying to accomplish what would seem to be an easy thing, but with the caveat of making it work across all browsers.
What I'm asking is, wouldn't a somewhat complex layout (or any layout that wouldn't normally be easy to accomplish with just divs and css) be best solved with a mix of tables and css with some divs wrapping needed elements (to deal with the nestedness) so you can rapidly develop your application and NOT worry about it looking like crap on unsupported browsers ?
* !EDIT! * I also agree completely that yes, tables are for tabular data, and just on semantics I feel I should be using do-nothing tags, then naming them and styling them, but for ME, I swear so many times to quickly just build something fast, using tables BEATS trying to style it perfectly to work on ALL browsers.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我认为这主要与语义有关。
是为了表示表格数据而构建的，使用它来布局元素违反了这一点。而且，99.9% 的情况下，任何可以用完成的事情都可以用 CSS 轻松完成。在其他情况下，这并没有那么容易，而且就像你说的，它使标记变得丑陋且难以遵循。它还违反了网络开发的内容、行为和表示的分离。
It's mostly about the semantics, I think. A
<table>is built to represent tabular data, and using it to lay out elements violates that. Also, anything that can be done with<table>can be done just as easily or easier with CSS 99.9% of the time. It's not that much easier in the other cases, and like you say, it makes markup ugly and hard to follow. It also violates the separation of content, behaviour, and presentation fundamental to web development.我能给出的最佳答案是，浏览器在完全处理页面之前不知道表格列的宽度，这可能会导致页面明显加载的明显延迟。通过使用 div，内容将立即显示，如果另一个元素强制其调整大小，它也会显示，但显示的内容不会出现延迟。所以这是更好的用户体验。
Best answer I can give is that a browser does not know how wide a table column has to be until it completely processes the page, which can result in a marked delay in the page visibly loading. By using a div the content will display immediately and if another element forces it to resize, it will, but there is no lag in things being displayed. So it's a better user experience.
当需要时使用表格。当数据需要整齐、干净且按特定顺序重复时。您不应该仅仅为了避免使用表格。
Use tables when the need arises for them. When data needs to be neat, clean, and in a specific order that repeats. You should not avoid tables just for the sake of it.
使用 DIV 和 SPAN 来布局页面并使用 TAB 来表示表格数据（如数据表、用户列表等），这只是正确的 HTML 语义...此外，DIV 还可以在放置和样式方面提供更大的灵活性
Its just correct HTML semantics to use DIVs and SPANs for laying out a page and using TABs to represent tabular data, as in datasheets, user lists etc... Plus DIVs allow more flexibility with placement and styling
有些优点是使用表格无法实现的。考虑一下缩略图 - 您可以在一行中显示尽可能多的缩略图，如果没有更多空间，其他缩略图将断到下一行（即时）。
另请参阅：
http://www.csszengarden.com/ ->并在“选择设计”侧栏中选择不同的设计
或者菜单/导航栏的更好方法：
http://css.maxdesign.com.au/listamatic/
There are some advantages that you can't achieve using tables. Think about thumbnails - you can show as many as possible in one row, if there's no more space the others will break to the next line (on the fly).
See also:
http://www.csszengarden.com/ -> and choose a different design in the "choose a design" sidebar
Or a better approach for menus/navigation bars:
http://css.maxdesign.com.au/listamatic/
一个很好的理由是关注点分离。 HTML是用来表达信息的。 CSS 用于处理表示，而 JavaScript 则用于处理行为。通过分离这些关注点，内容可以更好地解释为标记所说的 - 即表格表达表格数据，而 div 和 span 表达内容块和文本范围。
如果您想要一些更好的理由：
因为屏幕阅读器可以理解您
内容更好。否则，你的整个
页面可以被解释为表格
数据。你会让它更容易访问
通过使用 div 和 span。
One good reason is separation of concerns. HTML is for expressing information. CSS is for dealing with presentation and JavaScript is for behaviour. By seperating these concerns the content can be better interpreted as a the markup says - namely that a table is expressing tabular data, where as divs and spans are expressing a block of content and a span of text.
If you want some more good reasons:
as a screen reader can understand you
content better. Otherwise, your whole
page could be interpreted as tabular
data. You'll make it more accessible
by using divs and spans.
人们讨厌表格，因为它会降低 SEO（搜索引擎优化）。
大多数情况下，这是一个语义问题。表格旨在显示表格数据 - 需要以表格格式布局的数据。将它用于其他任何事情就像使用 Excel 来格式化您的小册子 - 有时它可能会起作用，但实际上，请使用 Word。
较新的 HTML5 元素以及一些较旧的 HTML4 元素在语义上更适合这种情况 - 内容的划分需要 div，章节需要章节，文章需要文章，导航需要 nav。
表格旁边的其他元素也确实提供了更大的灵活性，并且如果使用得当，甚至可以比表格更容易。
最终，还是要看实用性。如果本质上是表格数据，请使用表格。但如果是列或导航 - 使用 li 或浮动 div 或部分。
编辑：
顺便说一句，比较两种相同情况所需的 HTML：
http://jsfiddle.net/gbXFG/3/ 与 http://jsfiddle.net/uJ2LG/
People hate tables because it decreases SEO (Search Engine Optimization).
Mostly, it's an issue of semantics. A table is meant to display tabular data - data that needs to be laid out in a tabular format. Using it for anything else is like using Excel to format your Brochure - there might be the odd time it works, but really, use Word.
Newer HTML5 elements, as well as some of the older HTML4 elements are just better semantically suited to the occasion - a division of content calls for a div, a section for a section, an article for an article, navigation for nav.
Other elements beside tables also do allow for greater flexibility and can be even easier than tables when rightly used.
Ultimately, it comes down to practicability. If it's somewhat tabular dataish in nature, use a table. But if it's columns, or navigation - use li or floated divs or sections.
EDIT:
Compare the HTML required for two identical situations, btw:
http://jsfiddle.net/gbXFG/3/ vs. http://jsfiddle.net/uJ2LG/