在HTML中,表格不应该用于布局,这似乎是普遍的观点。

Why?

我从来没有(老实说,很少)看到过支持这一点的有力论据。通常的答案是:

It's good to separate content from layoutBut this is a fallacious argument; Cliche Thinking. I guess it's true that using the table element for layout has little to do with tabular data. So what? Does my boss care? Do my users care?Perhaps me or my fellow developers who have to maintain a web page care... Is a table less maintainable? I think using a table is easier than using divs and CSS.By the way... why is using a div or a span good separation of content from layout and a table not? Getting a good layout with only divs often requires a lot of nested divs. Readability of the codeI think it's the other way around. Most people understand HTML, few understand CSS. It's better for SEO not to use tablesWhy? Can anybody show some evidence that it is? Or a statement from Google that tables are discouraged from an SEO perspective? Tables are slower.An extra tbody element has to be inserted. This is peanuts for modern web browsers. Show me some benchmarks where the use of a table significantly slows down a page. A layout overhaul is easier without tables, see css Zen Garden.Most web sites that need an upgrade need new content (HTML) as well. Scenarios where a new version of a web site only needs a new CSS file are not very likely. Zen Garden is a nice web site, but a bit theoretical. Not to mention its misuse of CSS.

我对使用divs + CSS而不是表的良好参数非常感兴趣。


对于为了简单或临时的东西而拼凑在一起的HTML,表很有用。如果你正在构建一个大型网站,你应该使用div和CSS,因为随着时间的推移,随着网站的变化,它将更容易维护。


根据508法规(对于视障屏幕阅读器),表格应该只用于保存数据,而不是用于布局,因为它会导致屏幕阅读器崩溃。至少别人是这么告诉我的。

如果您为每个div分配名称,您也可以使用CSS将它们一起蒙皮。只是让他们坐成你想要的样子有点麻烦。


无论如何,这并不是一个明确的论点,但是对于CSS,你可以使用相同的标记并根据介质改变布局,这是一个很好的优势。例如,对于打印页面,您可以安静地抑制导航,而不必创建打印机友好的页面。


我想使用表格元素进行布局确实与表格数据没有什么关系。那又怎样?我的老板在乎吗?我的用户关心吗?

谷歌和其他自动化系统确实关心这些问题,而且它们在许多情况下同样重要。语义代码对于非智能系统来说更容易解析和处理。


看这个重复的问题。

你忘记的一项是可访问性。例如,如果你需要使用屏幕阅读器,基于表格的布局就不能很好地转换。如果您使用政府,则可能需要支持可访问的浏览器,如屏幕阅读器。

我也认为你低估了你在问题中提到的一些事情的影响。例如,如果您既是设计人员又是程序员,您可能没有充分了解它如何将表示和内容分开。但一旦你进入一个商店,他们是两个不同的角色,优势就开始变得清晰起来。

如果你知道你在做什么并且有好的工具,CSS在布局方面确实比表格有显著的优势。虽然每一件物品本身都不能证明放弃餐桌是合理的,但总的来说还是值得的。


我曾经处理过一个包含6层嵌套表的网站,这个网站是由一些应用程序生成的,并且生成了无效的HTML,事实上,我花了3个小时的时间来纠正它,因为一个小的改变。

这当然是边缘情况,但是基于表的设计是不可维护的。如果你使用css,你分离了样式,所以在修复HTML时,你不必担心破坏。

同样,用JavaScript试试这个方法。将单个表单元格从一个位置移动到另一个表中的另一个位置。执行起来相当复杂,div/span只需要复制粘贴即可。

“我的老板在乎吗?”

如果我是你的老板。你会在乎的。,)如果你珍视你的生命。


我想补充的是,基于div的布局更容易维护、发展和重构。只是在CSS中做了一些改变来重新排序元素,这就完成了。根据我的经验,重新设计使用表的布局是一场噩梦(如果有嵌套的表,则会更糟)。

从语义的角度来看,代码也有意义。


内容和布局之间的分离也使它更容易为您的网站生成打印机友好的布局或不同的皮肤(样式),而不必创建不同的html文件。有些浏览器(如Firefox)甚至支持从视图菜单中选择样式表。

而且我确实认为保持无表格布局更容易。你不需要担心行span, colspan等等。您只需创建一些容器div并将内容放置在需要的位置。也就是说,我认为它也更有可读性(<div id="sidebar"> vs <tr><td>…</td><td>…<td>sidebar</td></tr>)。

这只是一个你必须学会的小“技巧”(一旦你掌握了这个技巧,我认为它会更容易,更有意义)。


另外,别忘了,表格在移动浏览器上的渲染效果并不好。当然,iPhone拥有强大的浏览器,但并不是每个人都有iPhone。对于现代浏览器来说,表呈现可能是花生,但对于移动浏览器来说,它却是一堆西瓜。

我个人发现很多人使用了太多的<div>标记,但如果适当,它可以非常干净且易于阅读。你提到人们阅读CSS比阅读表格更困难;就“代码”而言,这可能是真的;但是在读取内容方面(查看>源代码),用样式表理解结构要比用表容易得多。


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

参见:过度使用ViewState


看起来你只是习惯了桌子,仅此而已。 将布局放在表格中会限制你的布局。用CSS你可以移动位,看看http://csszengarden.com/ 不,布局通常不需要很多嵌套的div。

没有表格的布局和适当的语义HTML更干净,因此更容易阅读。 为什么不理解CSS的人要尝试阅读它呢?如果有人认为自己是web开发人员,那么对CSS的良好掌握是必须的。

SEO的好处来自于将最重要的内容放在页面上方的能力 拥有更好的内容与标记比率。

http://www.hotdesign.com/seybold/


显而易见的答案:参见CSS Zen Garden。如果你告诉我你可以很容易地用基于表格的布局做同样的事情(记住- HTML没有改变),那么无论如何都要使用表格来布局。

另外两个重要的事情是可访问性和搜索引擎优化。

两者都关心信息以何种顺序呈现。如果基于表格的布局将导航放在页面上第二个嵌套表格的第2行的第3个单元格中,则无法轻松地将导航显示在页面顶部。

所以你的答案是可维护性,可访问性和SEO。

不要偷懒。即使事情有点难学,也要用正确的方式去做。


CSS布局通常在可访问性方面要好得多,前提是内容以自然的顺序出现,并且没有样式表也有意义。不仅仅是屏幕阅读器难以适应基于表格的布局:它们也使移动浏览器更难正确呈现页面。

此外,使用基于div的布局,你可以很容易地用打印样式表做一些很酷的事情,比如从打印页面中排除页眉、页脚和导航——我认为这是不可能的,或者至少很难用基于表格的布局做到这一点。

If you're doubting that separation of content from layout is easier with divs than with tables, take a look at the div-based HTML at CSS Zen Garden, see how changing the stylesheets can drastically change the layout, and think about whether you could achieve the same variety of layouts if the HTML was table based... If you're doing a table-based layout, you're unlikely to be using CSS to control all the spacing and padding in the cells (if you were, you'd almost certainly find it easier to use floating divs etc. in the first place). Without using CSS to control all that, and because of the fact that tables specify the left-to-right and top-to bottom order of things in the HTML, tables tend to mean that your layout becomes very much fixed in the HTML.

实际上,我认为完全改变一个基于div和css的设计而不改变div是非常困难的。然而,使用基于div和css的布局,就更容易调整不同块之间的间距以及它们的相对大小。


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

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

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

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

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

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


我没有对DIVs有利的论据。

我会说:如果事实属实,那就接受吧。

值得注意的是,要找到一种好的DIV+CSS方法来在两列或三列中呈现内容,并且在所有浏览器上都是一致的,并且看起来仍然是我想要的方式,即使不是不可能,也是很困难的。

在我的大多数布局中,这让平衡感向表格倾斜了一点,尽管我对使用它们感到内疚(不知道为什么,人们只是说它不好,所以我试着听他们的),最后,务实的观点是,对我来说,使用表格更容易、更快。我不是按小时计酬的,所以桌子对我来说比较便宜。


下面是我的程序员在一个类似的帖子中给出的答案

语义101

首先看一下这段代码,想想哪里出了问题……

class car {
    int wheels = 4;
    string engine;
}

car mybike = new car();
mybike.wheels = 2;
mybike.engine = null;

当然,问题在于自行车不是汽车。car类对于bike实例是不合适的类。代码没有错误,但是语义不正确。这对程序员的形象很不利。

语义102

现在将此应用于文档标记。如果您的文档需要显示表格数据,那么适当的标记将是<table>。但是,如果将导航放在表中,则滥用了<table>元素的预期用途。在第二种情况下,您没有表示表格数据—您(mis)使用<table>元素来实现表示目标。

结论

游客会注意到吗?不。你的老板在乎吗?也许吧。作为程序员,我们有时会偷工减料吗?当然。但是我们应该吗?不。如果使用语义标记,谁会受益?你,还有你的职业声誉。现在去做正确的事吧。


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

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

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


508符合性-屏幕阅读器能够理解你的标记。 等待呈现——直到</table>元素结束,表格才会在浏览器中呈现。


div和CSS的定位允许一个更灵活的设计,导致更容易修改和模板的网页。

也就是说,如果你对灵活性不感兴趣,那么使用一个表而不是一些由CSS变形成表的div绝对是更容易和更快的。我倾向于在设计时使用表格,只是为了更快地让它看起来正确。


围绕语义标记的整个思想是标记和表示的分离,其中包括布局。

Div并没有取代表,它们在将内容分离为相关内容块(,)方面有自己的用途。当您不具备这些技能并且依赖于表格时,您通常必须将内容分离到单元格中以获得所需的布局,但是在使用语义标记时,您不需要触摸标记来实现表示。在生成标记而不是静态页面时,这一点非常重要。

开发人员需要停止提供暗示布局的标记,以便我们这些拥有显示内容技能的人能够继续工作,并且开发人员不必在表示需要更改时返回他们的代码进行更改。


使用表格布局的工具可能会因为创建布局所需的大量代码而变得异常沉重。SAP的Netweaver Portal默认使用TABLE来布局页面。

在我目前的工作中,生产SAP门户有一个主页,它的HTML超过60K,有7个表那么深,在页面中有3次。再加上Javascript,误用了16个iframe,其中有类似的表格问题,CSS过重等,页面重量超过5MB。

花点时间降低页面重量,这样你就可以利用带宽与用户进行互动,这是值得的。


布局的灵活性 想象一下,您正在创建一个带有大量缩略图的页面。 div: 如果你把每个缩略图放在DIV中,向左浮动,可能一行有10个缩略图。让窗口变窄,BAM -它是一行6个,或者2个,或者其他合适的。 表: 你必须明确地说一行中有多少单元格。如果窗口太窄,用户必须水平滚动。

可维护性 和上面的情况一样。现在要向第三行添加三个缩略图。 div: 把它们加进去。布局会自动调整。 表: 将新单元格粘贴到第三行。哦!现在那里的商品太多了。从那一行切一些,放在第四行。现在那里的商品太多了。从那一行切一些……(等) (当然,如果您使用服务器端脚本生成行和单元格,这可能不是问题。)


我曾经了解到,一个表是立即加载的,换句话说,当连接很慢的时候,表所在的空间保持空白,直到整个表被加载,另一方面,一个div加载从上到下的速度与数据到达的速度一样快,不管它是否已经完成。


如果你在这方面支持表格角度,找一个有表格的网站,然后给自己买一个屏幕阅读器——关掉屏幕阅读器,关掉你的显示器。

然后尝试一个不错的语义正确的div布局网站。

你会发现其中的不同。

如果表格中的数据是表格而不是为了布局页面,那么表格并不是邪恶的。


有必要弄清楚CSS和div,以便在页面布局中,中央内容列在侧栏之前加载和呈现。但是,如果你正在努力使用浮动div来垂直对齐一个logo和一些赞助文本,那就使用这个表格,继续生活吧。禅宗花园宗教并没有带来多少价值。

将内容与表示分开的思想是对应用程序进行分区,以便不同类型的工作影响不同的代码块。这实际上是关于变更管理的。但是编码标准只能以表面的方式检查代码的当前状态。

应用程序的更改日志依赖于编码标准来“将内容与表示分开”,它将显示跨垂直竖井的并行更改模式。如果对“内容”的更改总是伴随着对“表示”的更改,那么分区的成功程度如何?

如果您真的想高效地划分代码,请使用Subversion并检查更改日志。然后使用最简单的编码技术——divs、表、JavaScript、include、函数、对象、延续等等——来构建应用程序,以便以简单和舒适的方式进行更改。


一张桌子来布置也不错。但大多数情况下,仅靠一张表是无法得到所需的布局的。很快你就有了2到3个嵌套表。这变得非常麻烦。

It IS a LOT harder to read. That's not up to opinion. There's just more nested tags with no identifying marks on them. Separating content from presentation is a good thing because it allows you to focus on what you're doing. Mixing the two leads to bloated pages that are hard to read. CSS for styles allows your browser to cache the files and subsequent requests are much faster. This is HUGE. Tables lock you into a design. Sure, not everyone needs the flexibility of CSS Zen Garden, but I've never worked on a site where I didn't need to change the design a little bit here and there. It's much easier with CSS. Tables are hard to style. You don't have very much flexibility with them (i.e. you still need to add HTML attributes to fully control a table's styles)

我大概有4年没有用表格来处理非表格数据了。我没有回头。

我真的很想建议你阅读Andy Budd的《CSS Mastery》。棒极了。

图片在ecx.images-amazon.com http://ecx.images-amazon.com/images/I/41TH5NFKPEL._SL500_BO2,204,203,200_PIsitb-dp-500-arrow,TopRight,45,-64_OU01_AA240_SH20_.jpg


对我来说,一个巨大的问题是,表,特别是嵌套表,需要更长的时间来呈现比一个正确布局的css实现。(你可以让css一样慢)。

所有浏览器呈现css的速度都更快,因为每个div都是一个单独的元素,所以用户在阅读时可以加载屏幕。(对于庞大的数据集等)。我在那个实例中使用了css而不是表格,甚至没有处理布局。

嵌套的表(单元格中的表等)直到找到最后一个“/table”才会呈现到浏览器窗口。更糟糕的是,定义不清的表有时甚至无法呈现!或者当它发生的时候,事情就会不正常。(没有正确地与“TD”等共进)

我在大多数情况下使用表格,但当涉及到大数据和希望为最终用户快速呈现屏幕时,我尽最大努力利用CSS所提供的东西。


我想这事已经过去了。如果你看看行业的发展方向,你会发现CSS和开放标准是这场讨论的赢家。这反过来意味着对于大多数html工作,除了表单,设计师将使用div而不是表格。我很难做到这一点,因为我不是CSS专家,但事实就是这样。


我相信这是一个与普遍问题有关的问题。HTML诞生时,没有人能预见到它的广泛应用。另一项在自身成功的重压下几乎崩溃的技术。当HTML页面用vi在绿色文本终端上编写时,向页面访问者显示数据所需要的只是一个TABLE,而且大多数数据都是以表格形式显示的。

我们都知道事物是如何进化的。相对来说,table最近已经过时了,但是有很多理由更喜欢基于div和CSS的布局(可访问性不是最后一个)。当然我不能写一个CSS来拯救我的生命:-),我认为图形设计专家应该总是在手边。

也就是说……即使在现代网站中,也有许多数据应该在表格中显示。


当您需要确保元素在布局中保持特定的物理关系时,请使用表格。对于数据,表格通常是最适合使用的布局元素,因为您不希望列以超出预期的方式包装,从而混淆了关联。

也有人可能会说,必须保持特定关系的非数据元素也应该呈现在表中。

灵活的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.


我将一个接一个地看你的论点,并试着指出其中的错误。

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

It's not fallacious at all because HTML was designed intentionally. Misuse of an element might not be completely out of question (after all, new idioms have developed in other languages, as well) but possible negative implications have to be counterbalanced. Additionally, even if there were no arguments against misusing the <table> element today, there might be tomorrow because of the way browser vendors apply special treatment to the element. After all, they know that “<table> elements are for tabular data only” and might use this fact to improve the rendering engine, in the process subtly changing how <table>s behave, and thus breaking cases where it was previously misused.

那又怎样?我的老板在乎吗?我的用户关心吗?

视情况而定。你的老板是尖头发吗?那他可能不在乎。如果她有能力,那么她就会在乎,因为用户会在乎。

也许我或我的开发伙伴谁必须维护一个网页关心…表是否更难维护?我认为使用表格比使用div和css更容易。

大多数专业的web开发人员似乎反对你[需要引用]。事实上,表的可维护性较差,这是显而易见的。使用表格进行布局意味着更改公司布局实际上意味着更改每个页面。这可能会非常昂贵。另一方面,明智地将语义上有意义的HTML与CSS结合使用可能会将此类更改限制在CSS和所使用的图片上。

顺便说一下……为什么使用div或span可以很好地将内容与布局分开,而不是表格?只有div的良好布局通常需要大量嵌套的div。

深度嵌套<div>是反模式,就像表布局一样。优秀的网页设计师不需要太多这样的东西。另一方面,即使是这样深嵌套的div也没有很多表布局的问题。事实上,它们甚至可以通过逻辑地将内容划分为多个部分来构成语义结构。

代码的可读性 我觉得正好相反。大多数人懂html,很少人懂css。这是简单的。

“大多数人”不重要。专业人士。对于专业人士来说,表格布局比HTML + CSS带来更多的问题。这就像是说我不应该使用GVim或Emacs,因为记事本对大多数人来说更简单。或者我不应该使用LaTeX,因为MS Word对大多数人来说更简单。

SEO最好不要使用表格

我不知道这是不是真的,也不会把它作为一个论点,但它是合乎逻辑的。搜索引擎搜索相关数据。虽然表格数据当然可能是相关的,但它很少是用户搜索的内容。用户搜索页面标题或类似突出位置中使用的术语。因此,将表格内容排除在过滤之外,从而大幅减少处理时间(和成本!)是合乎逻辑的。

表比较慢。 必须插入一个额外的tbody元素。这对于现代网络浏览器来说是微不足道的。

额外的元素与表变慢无关。另一方面,表的布局算法要困难得多,浏览器通常必须等待整个表加载后才能开始布局内容。此外,缓存布局将不起作用(CSS可以很容易地缓存)。所有这些都在前面提到过。

向我展示一些使用表会显著降低页面速度的基准测试。

不幸的是,我没有任何基准测试数据。我自己也会感兴趣,因为这个论点确实缺乏一定的科学严谨性。

大多数需要升级的网站也需要新的内容(html)。一个新版本的网站只需要一个新的css文件的场景是不太可能的。

Not at all. I've worked on several cases where changing the design was simplified by a separation of content and design. It's often still necessary to change some HTML code but the changes will always be much more confined. Additionally, design changes must on occasion be made dynamically. Consider template engines such as the one used by the WordPress blogging system. Table layouts would literally kill this system. I've worked on a similar case for a commercial software. Being able to change the design without changing the HTML code was one of the business requirements.

Another thing. Table layout makes automated parsing of websites (screen scraping) much harder. This might sound trivial because, after all, who does it? I was surprised myself. Screen scraping can help a lot if the service in question doesn't offer a WebService alternative to access its data. I'm working in bioinformatics where this is a sad reality. Modern web techniques and WebServices have not reached most developers and often, screen scraping is the only way to automate the process of getting data. No wonder that many biologists still perform such tasks manually. For thousands of data sets.


作为纯布局使用的表格确实会带来一些可访问性问题(我听说过)。但我理解这里被问到的问题,你正在通过使用表格来确保页面上某些东西的正确对齐来破坏网络。

我以前听到有人说,FORM标签和输入实际上是数据,应该允许它们进入表。

使用一个表来确保一些元素正确排列会导致代码大量增加,这种说法往往包含了单个DIV如何满足所有需求的示例。他们不总是包括10行CSS和特殊的浏览器技巧,他们必须为IE5、IE5.5、IE6、IE7……

我认为这仍然是关于在你的设计中使用平衡。表格在工具箱里,记住它们是干什么用的……


我尽量避免使用TABLEs,但是当我们设计复杂的表单,混合了多种控件类型和不同的标题位置,并对分组进行了非常严格的控制时,使用DIVs是不可靠的,甚至几乎是不可能的。

现在,我不会说这些表单不能重新设计以更好地适应基于DIV的布局,但是对于其中的一些表单,我们的客户坚决不改变以前版本(用经典ASP编写的)的现有布局,因为它与用户熟悉的纸质表单相似。

因为表单的表示是动态的(其中某些部分的显示是基于案例的状态或用户的权限),所以我们使用一组堆叠的div,每个div包含一个由逻辑分组的表单元素组成的TABLE。TABLE的每一列都被分类,这样CSS就可以控制它们。这样,我们就可以关闭表单的不同部分,而不会出现在div中不是表来换行的问题。


根据过去的经验,我必须选择DIV。即使在OOP中,主要目的也是减少对象之间的耦合,因此这个概念可以应用于DIVS和表。表用于保存数据,而不是围绕页面排列数据。DIV是专门设计用于在页面周围排列项目的,因此设计应该使用DIV,表应该用于存储数据。

此外,编辑由表格组成的网站是非常困难的(在我看来)


This isn't really about whether 'divs are better than tables for layout'. Someone who understands CSS can duplicate any design using 'layout tables' pretty straightforwardly. The real win is using HTML elements for what they are there for. The reason you would not use tables for non-tablular data is the same reason you don't store integers as character strings - technology works much more easily when you use it for the purpose for which it is desgined. If it was ever necessary to use tables for layout (because of browser shortcomings in the early 1990s) it certainly isn't now.


当然,这篇文章有点小题大做,争论似乎很简单,很容易反驳。

网页是Web开发人员的领域,如果他们说div和CSS比表格更好,那对我来说已经足够好了。

如果布局是由服务器应用程序生成的表实现的,那么新的布局意味着对应用程序的更改,应用程序的重新构建和重新部署,而不仅仅是对css文件的更改。

另外,可访问性。用于布局的表格会使网站无法访问,所以不要使用它们。这是显而易见的,更不用说违法了。


我认为没有人会在意一个网站是如何设计/实现的,当它运行得很好并且运行得很快的时候。

我在HTML标记中同时使用“table”和“div”/“span”标记。

让我给你一些我为什么选择跳水的理由:

for a table you have to write at least 3 tags (table, tr, td, thead, tbody), for a nice design, sometimes you have a lot of nested tables I like to have components on the page. I don't know how to explain exactly but will try. Suppose you need a logo and this have to be placed, just a small piece of it, over the next page content. Using tables you have to cut 2 images and put this into 2 different TDs. Using DIVs you can have a simple CSS to arange it as you want. Which solution do you like best? when more then 3 nested tables for doing something I am thinking to redesign it using DIVs

但是我仍然在使用表格:

表格数据 扩展自我的内容 快速解决方案(原型),因为DIVs盒子模型在每个浏览器上是不同的,因为许多生成器使用表格等


使用DIV,您可以轻松地进行切换。例如,你可以这样做:

Menu | Content

Content | Menu

Menu
----
Content

在CSS中更改它很容易,而在HTML中则不然。你也可以提供几种风格(右手,左手,专为小屏幕)。

在CSS中,您还可以将菜单隐藏在用于打印的特殊样式表中。

另一个好处是,你的内容在代码中总是按照相同的顺序(菜单在前,内容在后),即使在视觉上它是以其他方式呈现的。


一般来说,表并不比CSS更容易或更易于维护。然而,在一些特定的布局问题中,表确实是最简单和最灵活的解决方案。

在表示标记和CSS支持相同类型的设计的情况下,CSS显然是更可取的,没有人会认为字体标记比在CSS中指定排版更好,因为CSS提供了与字体标记相同的功能,但以一种更干净的方式。

The issue with tables, however, is basically that the table-layout model in CSS is not supported in Microsoft Internet Explorer. Tables and CSS are therefore not equivalent in power. The missing part is the grid-like behavior of tables, where the edges of cells align both vertically and horizontally, while cells still expand to contain their content. This behavior is not easy to achieve in pure CSS without hardcoding some dimensions, which makes the design rigid and brittle (as long as we have to support Internet Explorer - in other browsers this is easliy achieved by using display:table-cell).

因此,这并不是一个表或CSS更可取的问题,而是一个认识到使用表可以使布局更灵活的具体情况的问题。

不使用表的最重要原因是可访问性。Web内容可访问性指南http://www.w3.org/TR/WCAG10/建议不要使用表格进行布局。如果您担心可访问性(在某些情况下,您可能有法律义务这样做),即使表更简单,也应该使用CSS。请注意,您总是可以用CSS创建与表相同的布局,这可能只是需要更多的工作。


下面是来自最近项目的一段html:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
    <title>{DYNAMIC(TITLE)}</title>
    <meta http-equiv="content-type" content="text/html;charset=utf-8" />
    <meta http-equiv="Content-Style-Type" content="text/css" />
    <link rel="stylesheet" type="text/css" href="./styles/base.css" />
</head>
<body>
    <div id="header">
        <h1><!-- Page title --></h1>
        <ol id="navigation">
            <!-- Navigation items -->
        </ol>
        <div class="clearfix"></div>
    </div>
    <div id="sidebar">
        <!-- Sidebar content -->
    </div>
    <!-- Page content -->
    <p id="footer"><!-- Footer content --></p>
</body>
</html>

这是与基于表格的布局相同的代码。

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
    <title>{DYNAMIC(TITLE)}</title>
    <meta http-equiv="content-type" content="text/html;charset=utf-8" />
    <meta http-equiv="Content-Style-Type" content="text/css" />
    <link rel="stylesheet" type="text/css" href="./styles/base.css" />
</head>
<body>
    <table cellspacing="0">
        <tr>
            <td><!-- Page Title --></td>
            <td>
                <table>
                    <tr>
                        <td>Navitem</td>
                        <td>Navitem</td>
                    </tr>
                </table>
            </td>
        </tr>
    </table>

    <table>
        <tr>
            <td><!-- Page content --></td>
            <td><!-- Sidebar content --></td>
        </tr>
        <tr>
            <td colspan="2">Footer</td>
        </tr>
    </table>
</body>
</html>

我在基于表格的布局中看到的唯一干净的地方是我对缩进的过度热情。我确信内容部分将有另外两个嵌入式表。

另一件需要考虑的事情是:文件大小。我发现基于表格的布局通常是CSS布局的两倍大。在我们的高速宽带上,这不是一个大问题,但在那些拨号调制解调器上。


WYSIWYG!!! I can't for the life of me get our designers to stop using nested DIVS and styled by elementID css in templates that are supposed to be used by clients in CMS projects. That's the whole point of a WYSIWYG online editor. You are controlling both the content and the layout at the same time! There is no separation at all in the first place in this scenario. Positioned and styled Divs in some external stylesheet are anathema to the whole idea of WYSIWYG editing. Tables can be seen, rows inserted, cells combined and so on. Good luck trying this with divs in a way that doesn't frustrate users.


超级简单的回答:用表格设计可维护的网站是很困难的,而用标准的方法来做是很简单的。

网站不是一个表格,它是相互交互的组件的集合。把它描述成一个表是没有意义的。


一个例子:你想要居中 一个页面的主要内容区域,但在 为了把浮体装在里面, 它需要浮动。没有 CSS中的float: center。

这并不是在居中元素中“包含浮点数”的唯一方法。所以,这根本不是一个好的论点!

在某种程度上,“divs vs table”是一个错误的前提。

把一页快速地分成三列?说实话,表格更简单。但是没有专业人士将它们用于布局,因为它们将页面元素的位置锁定在页面中。

真正的争论是“由CSS完成的定位(最好是在远程文件中)”,而不是“在页面中由HTML完成的定位”。相对于后者,每个人都能看到前者的好处吗?

Size -- if your page layout is in the HTML, in the pages, it can't be cached, and it has to be repeated on every page. You will save enormous amounts of bandwidth if your layout is in a cached CSS file, not in the page. Multiple developers can work on the same page at the same time -- I work on the HTML, other guy works on the CSS. No repository needed, no problems with over-writing, file locking etc. Making changes is easier -- there will be problems with layout in different browsers, but you only have to fix one file, the CSS file, to sort them out. Accessibility, as mentioned a lot previously. Tables assume a two-dimensional layout works for everyone. That's not how some users view your content and it's not how Google views your content.

考虑一下:

[ picture ] [ picture ] [ picture ]
[ caption ] [ caption ] [ caption ]

表示包含6个单元格的表中的两行。能看到二维表格布局的人会在每张图片下看到标题。但是使用语音合成,或者PDA,以及搜索引擎蜘蛛,那是

picture picture picture caption caption caption

有了表格,这种关系就明显消失了。

div和CSS是否更适合在HTML页面上简单地布局矩形以在最短的时间内实现给定的设计?不,他们可能不是。但我不是在快速布局矩形来实现给定的设计。我想的是更大的前景。


当我使用CSS设计我的布局时,我通常给每个主要部分都有自己的根(主体级别)div,并使用相对/绝对定位将其置于适当的位置。这比表更灵活一些,因为我不局限于可以用行和列表示的排列。

此外,如果我决定我想要重新安排布局(说我想要导航栏现在在右边),我可以简单地去改变一个地方(CSS文件)的元素位置,HTML不需要改变。如果我对表执行此操作,我将不得不进入并找到信息,并进行大量属性修改和复制粘贴以获得相同的效果。

事实上,使用CSS,我甚至可以让我的用户选择他们想要的布局如何工作。只要内容区域的一般大小不改变,我完全可以使用一些PHP脚本来根据用户的偏好输出CSS,并允许他们根据自己的喜好重新排列站点。同样,对于表也是可以的,但是维护起来要困难得多。

最后,CSS提供了一个表永远无法提供的主要好处:基于显示设备重新格式化内容的能力。CSS允许我在打印机上使用与显示器上完全不同的样式集(包括位置、格式等)。这也可以扩展到其他媒体,一个很好的例子是Opera Show,它允许一个设计巧妙(非常标准)的CSS增强页面被视为幻灯片显示。

因此,最终,灵活性和管理才是真正的赢家。一般来说,CSS允许你对布局做更多的事情。基于表的布局在技术上没有什么不标准的,但为什么要限制自己呢?


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.


我不得不用这两种方式来做网站,再加上第三种,可怕的“混合”布局,包括表格、div和样式:div /CSS轻松胜出。

为了匹配一个表格单元格的代码权重,您必须立即嵌套三个深度的div。这种效果会随着嵌套表的增加而扩大。

我也更喜欢做一个布局变化,而不是一个变化,在我的网站的每一页。

我可以完全控制divs/css的各个方面。表格以一种可怕的方式把它搞得一团糟,尤其是在IE浏览器中,我从来没有选择不支持这个浏览器。

我维护或重新设计一个div /css网站的时间只是表格的一小部分。

最后,我可以用CSS和几乎任何脚本语言创新多种可切换的布局。这对我来说是不可能的。

在你做决定的时候,祝你的投资回报率好运。


在维护内容的同时进行网站维护和设计检修(这一直都在发生,尤其是在电子商务中):

内容和设计通过表格混合在一起=更新内容和设计。

内容与设计分离=更新设计和少量内容。

如果我有自己的方式,我会将内容保存在PHP中,生成XML,转换为XSLT中的标记,并使用CSS和Javascript进行交互设计。对于Java方面的东西,JSP到JSTL来生成标记。


这并不一定是一场战争。和谐是可能的。

使用一个表的整体布局和div在其中。

<table> 
    <tr><td colspan="3"><div>Top content</div></td></tr>
    <tr> 
        <td><div>Left navigation</div></td> 
        <td><div>Main content</div></td> 
        <td><div>Right navigation</div></td> 
    </tr>
    <tr><td colspan="3"><div>Bottom content</div></td></tr>
</table>

看,没有嵌套表。

我读过很多关于如何用divs实现这一点的文章,但从来没有发现任何事情,每次都没有问题。

一旦你有了整体结构,Divs是很棒的,但坦率地说,流体页眉/页脚和三个流体列是Divs的一大痛苦。Divs不是为流动性而设计的,所以为什么要使用它们呢?

注意,这种方法将在链接文本中提供100%的CSS遵从性


1:是的,你的用户很关心。如果他们使用屏幕阅读器,它就会丢失。如果我使用任何其他试图从页面中提取信息的工具,遇到不用于表示表格数据的表是一种误导。

div或span用于分隔内容是可以接受的,因为这正是那些元素的含义。当我,一个搜索引擎,一个屏幕阅读器或其他任何东西,遇到一个表格元素,我们期望这意味着“以下是表格数据,表示在一个表中”。当我们遇到div时,我们期望“这是一个用于将内容划分为单独部分或区域的元素。

2 .可读性:错误。如果所有的表示代码都是css,我可以阅读html,我将理解页面的内容。或者我可以阅读css和理解的表示。如果html中的所有内容都是混杂在一起的,那么在我甚至可以看到什么是内容,什么不是内容之前,我必须在脑海中剔除所有与表示相关的部分。 此外,我害怕遇到一个不懂css的web开发人员,所以我真的不认为这是一个问题。

3:表比较慢:是的,它们比较慢。原因很简单:在呈现表之前,必须对表进行完整的解析,包括其内容。可以在遇到div时呈现它,甚至在它的内容被解析之前。这意味着div会在页面加载完成之前显示出来。

还有一个好处是,表格更加脆弱,在不同的浏览器中呈现的效果并不总是一样的,不同的字体和字体大小以及所有其他可能导致布局变化的因素。表格是一种很好的方法,可以确保你的网站在某些浏览器中会偏离一两个像素,当用户改变字体大小或以任何其他方式改变设置时,它不会很好地缩放。

Of course #1 is the big one. A lot of tools and applications depend on the semantic meaning of a webpage. The usual example is screen-readers for visually impaired users. If you're a web developer, you'll find that many large companies who may otherwise hire you to work on a site, require that the site is accessible even in this case. Which means you have to think about the semantic meaning of your html. With the semantic web, or more relevantly, microformats, rss readers and other tools, your page content is no longer viewed exclusively through a browser.


我很抱歉我的英语不好,但还有一个原因:

我在一些政府机构工作,不使用TABLE的首要原因是残疾人。他们使用机器“翻译”网页。

问题是这个“翻译机器”不能阅读网站,如果它是由TABLE。为什么?因为TABLE是用于数据的。

事实上,如果你使用TABLES,你必须为每个cell指定一些信息,让残疾人知道他们在TABLE中的位置。想象一下,你有一个大表格,必须放大才能看到屏幕上的一个单元格:你必须知道你在哪一行/col。

因此,使用DIV,并且禁用可以简单地阅读文本,并且不会得到一些关于行/cols的奇怪信息,当它们不需要在那里时。

我也更喜欢TABLE来制作快速简单的模板,但我现在习惯了CSS…它很强大,但你真的必须知道你在做什么……:)


几年前,我研究了屏幕阅读器和表格的问题,得出了与大多数开发者想法相矛盾的信息:

http://www.webaim.org/techniques/tables/

你可能会听到一些易访问性倡导者说布局表是一个坏主意,应该使用CSS布局技术。他们说的有道理,但是,老实说,在可访问性方面,使用表格进行布局并不是最糟糕的事情。只要桌子在设计时考虑到可访问性,各种残疾的人都可以轻松地使用桌子。”


数据:使用表格。布局:使用样式。使用非常精简的浏览器(即没有样式,只有普通标记的Links 2或Lynx)可以最快地呈现表。


事实上,这是一个激烈争论的问题,这证明了W3C未能预见到将尝试的布局设计的多样性。使用divs+css进行语义友好的布局是一个很好的概念,但实现的细节有很大的缺陷,实际上限制了创作的自由。

我曾试图将我们公司的一个网站从餐桌切换到餐桌,这让我非常头疼,以至于我完全放弃了投入其中的工作时间,回到餐桌上。为了获得垂直对齐的控制,我试图与我的跳水手搏斗,这让我受到了重大的心理问题的诅咒,只要这场辩论继续下去,我就永远不会动摇。

人们必须经常想出复杂而丑陋的变通办法来实现简单的设计目标(比如垂直对齐),这一事实强烈地表明这些规则还不够灵活。如果规格已经足够了,那么为什么高调的网站(如SO)发现有必要使用表格和其他变通方法来改变规则呢?


Google gives very low priority to text content contained inside a table. I was giving some SEO advice to a local charity. In examining their website it was using tables to layout the site. Looking at each page, no matter what words - or combination of words - from their pages I used in the Google search box the pages would not come up in any of the top search pages. (However, by specifying the site in the search the page was returned.) One page was well copy written by normal standards to produce a good result in a search but still it didn't appear in any of the first pages of search results returned. (Note this text was within a table.) I then spotted a section of text on the pages which was in a div rather than a table. We put a few of the words from that div in the search engine. Result? It came in at No.2 in the search result.


Try to merge/split a 10/20 something deep colspan/rowspan. More than once I had to supress my instinct to start a fight with someone. [?!] Try to change source code order without changing visible order. [SEO, usability, ...] The very (really simple) page we're looking at is ~150K. I bet It can nearly be halved using proper CSS. [SEO (Yes, SEO, read latest Google specs etc), perfo, ...] Try to make an iterator template that can work in any width. The discussion of the matter in this table-based medium of SO can cause a singularity and destroy us all


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秒后回来-工作-立即-在所有浏览器上,没有更多的事情要做。请试着让我明白——你有什么理由让我用其他方式做这件事!


因为维护一个使用表格的网站是非常困难的,并且需要更长的编码时间。如果你害怕漂浮的潜水器,那就去上一门潜水课吧。它们并不难理解,而且它们的效率大约是前者的100倍,麻烦也少了100万倍(除非你不理解它们——但是,嘿,欢迎来到计算机的世界)。

任何考虑用表格做布局的人最好不要指望我来维护它。这是渲染网站最落后的方式。感谢上帝,我们现在有了更好的选择。我永远不会回去。

有些人可能没有意识到使用现代工具创建一个网站所带来的时间和精力的好处,这很可怕。


Layout should be easy. The fact that there are articles written on how to achieve a dynamic three column layout with header and footer in CSS shows that it is a poor layout system. Of course you can get it to work, but there are literally hundreds of articles online about how to do it. There are pretty much no such articles for a similar layout with tables because it's patently obvious. No matter what you say against tables and in favor of CSS, this one fact undoes it all: a basic three column layout in CSS is often called "The Holy Grail".

如果这不能让你说“WTF”,那么你现在真的需要放下酷爱饮料了。

我喜欢CSS。它提供了惊人的样式选项和一些很酷的定位工具,但作为一个布局引擎,它是有缺陷的。需要某种类型的动态网格定位系统。一个直接的方法来对齐多个轴上的盒子,而不知道他们的大小。我不在乎你叫它<table>或<gridlayout>或其他什么,但这是CSS中缺少的一个基本布局特性。

更大的问题是,由于不承认有缺失的特性,CSS狂热者一直在阻碍CSS的发展。如果CSS能像世界上其他布局引擎一样提供像样的多轴网格定位,我很乐意停止使用表格。(你应该意识到这个问题已经被除了W3C之外的所有人用多种语言解决过很多次了,对吧?没有人否认这样一个功能是有用的。)

叹息。足够的通风。去吧,把头埋进沙子里。


I still don't quite understand how divs / CSS make it easier to change a page design when you consider the amount of testing to ensure the changes work on all browsers, especially with all the hacks and so on. Its a hugely frustrating and tedious process which wastes large amounts of time and money. Thankfully the 508 legislation only applies to the USA (land of the free - yeah right) and so being as I am based in the UK, I can develop web sites in whatever style I choose. Contrary to popular (US) belief, legislation made in Washington doesn't apply to the rest of the world - thank goodness for that. It must have been a good day in the world of web design the day the legislation came into force. I think I'm becoming increasingly cynical as I get older with 25 years in the IT industry but I feel sure this kind of legislation is just to protect jobs. In reality anyone can knock together a reasonable web page with a couple of tables. It takes a lot more effort and knowledge to do this with DIVs / CSS. In my experience it can take hours and hours Googling to find solutions to quite simple problems and reading incomprehensible articles in forums full of idealistic zealots all argueing about the 'right' way to do things. You can't just dip your toe in the water and get things to work properly in every case. It also seems to me that the lack of a definitive guide to using DIVS / CSS "out of the box", that applies to all situations, working on browsers, and written using 'normal' language with no geek speak, also smells of a bit of protectionism. I'm an application developer and I would say it takes almost twice as long to figure out layout problems and test against all browsers than it does to create the basic application, design and implement business objects, and create the database back end. My time = money, both for me and my customers alike so I am sorry if I don't reject all the pro DIV / CSS arguments in favour of cutting costs and providing value for money for my customers. Maybe its just the way that developers minds work, but it seems to me far easier to change a complex table structure than it is to modify DIVs / CSS. Thankfully it now appears that a solution to these issues is now available - its called WPF.


Flex有一个标签,用于在垂直列中布局内容。说实话,我不认为他们在布局/内容方面做得很好,但至少他们已经解决了这个问题。

像许多对CSS感到沮丧的人一样,我也到处寻找一个简单的答案,当我以为我找到了它时,我感到兴奋,然后当我在Chrome中打开页面时,我的希望破灭了。我肯定没有足够的技能说这是不可能的,但我还没有看到任何人提供样本代码供同行评审,明确地证明它可以可靠地完成。

那么,这个岛的CSS方面有人能推荐一种布局垂直列的心态/方法吗?我尝试过在第二行和第三行绝对定位,但我最终与到处重叠的东西和浮动有类似的问题,如果页面缩小。

如果这个问题有答案,我会欣喜若狂地做正确的事情——只要告诉我一些像“嘿,你试过**流:垂直|水平”这样的事情,我就完全不烦你了。


DOM操作在基于表的布局中是很困难的。

使用语义div:

$('#myawesomediv').click(function(){
    // Do awesome stuff
});

表:

$('table tr td table tr td table tr td.......').click(function(){
    // Cry self to sleep at night
});

当然,第二个例子有点愚蠢,您总是可以将id或类应用到表或td元素上,但这将增加语义值,这是表的支持者强烈反对的。


我很惊讶地发现有些问题还没有涉及到,所以除了之前提出的所有非常有效的观点之外,以下是我的2点看法:

.1.CSS & SEO:

a) CSS used to have a very significant impact on SEO by allowing to position the content in the page wherever you want. A few years ago, Search Engines were giving a significant emphasis to "on-page" factors. Something at the top of the page was deemed more relevant to the page than something located at the bottom. "Top of the page" for a spider meant "at the beginning of the code". Using CSS, you could organize your keyword-rich content at the beginning of the code, and still position it wherever you liked in the page. This is still somewhat relevant, but on page factors are less and less important for page ranking.

b)当布局转移到CSS时,HTML页面更轻,因此对于搜索引擎蜘蛛加载更快。(蜘蛛不需要下载外部CSS文件)。快速加载页面是一个重要的排名考虑几个搜索引擎,包括谷歌

c) SEO工作通常需要测试和更改内容,这与基于CSS的布局更方便

。2。生成的内容:

用编程方式生成表要比等效的CSS布局容易得多。

foreach ($comment as $key=>$value)
{
   echo "<tr><td>$key</td><td>$value</td></tr>";
}

生成表很简单,也很安全。它是自包含的,可以很好地集成到任何模板中。用CSS做同样的事情要困难得多,而且可能根本没有任何好处:很难在飞行中编辑CSS样式表,并且内联添加样式与使用表没有什么不同(内容没有与布局分离)。

此外,在生成表时,内容(在变量中)已经与布局(在代码中)分离,使其易于修改。

这就是为什么一些设计非常好的网站(例如SO)仍然使用表格布局的原因之一。

当然,如果需要通过JavaScript对结果进行操作,那么div是值得的。

。3。快速转换测试

在找出适合特定受众的方法时,能够以各种方式更改布局以找出最佳结果是很有用的。基于CSS的布局使事情变得相当简单

。4。不同的问题有不同的解决方案

布局表通常被鄙视,因为“每个人都知道div和CSS”才是正确的方式。

然而,事实仍然是,表创建更快,更容易理解,比大多数CSS布局更健壮。(是的,CSS可以很健壮,但是在不同的浏览器和屏幕分辨率上快速浏览一下网络就会发现情况并非如此)

桌子有很多缺点,包括维护、缺乏灵活性……但是我们不要把孩子和洗澡水一起丢了。快速可靠的解决方案有很多专业用途。

前段时间,我不得不用表格重写了一个干净简单的CSS布局,因为相当一部分用户会使用对CSS支持非常差的旧版本IE

就我而言,我已经厌倦了“哦,不!”布局的表格!”

至于那些“它不是为了这个目的而设计的,因此你不应该这样使用它”的人群,这不是虚伪吗?你怎么看待所有的CSS技巧,你必须使用使该死的东西工作在大多数浏览器?他们是为了这个目的吗?


根据我对表的了解,如果嵌套了太多的表,在呈现页面时浏览器会有很大的开销。

1 -浏览器必须等待呈现最终视图,直到整个表被加载。

2 - The algorithm to render the table is expensive and is not in a single go. The browser, as and when, gets the contents, will try to render calculating the content width and height. So, if you are having nested tables, say, the browser has received the first row and the 1st cell is having large amount of content and width and height not defined, it will calculate the width and will render the first row, In the mean while it gets the 2nd row will cell#2 having loads of content! It will now calculate the width for 2nd row cells.. What about the first ? It will calculate widths recursively. That's bad at client side. (To site an example) As a programmer, you'll optimize stuffs such as time to fetch data, optimized data structures and etc. You optimize things to complete on server side, say in2 secs, but end user in getting the final view in 8 secs. What is wrong here ? 1. May be network is slow! What if network is fine ? What is network is delivering the contents in next 1 sec ? Where is this extra 5 secs getting consumed ? Thing to worry about-- The browser might be taking lot of time in estimating and rendering the tables!

如何优化表? 如果你使用表格,我建议,总是定义单元格的宽度。这并不能保证浏览器会盲目地只取这个宽度,但会对浏览器决定初始宽度有很大的帮助。

但是,最后,div是CSS可以被浏览器缓存的好方法;而表没有缓存!


通过仍然使用表格布局,我们错过了在div方面的创新。

许多人提出了解决方案,使创建布局的divs更容易。最流行的是网格架构。有基于此体系结构的动态布局生成器。查看: 1) 960。Gs和(http://grids.heroku.com/) 2)蓝图 最近也是如此。

在架构和表格布局工具方面,我还没有看到太多创新。

我想说,撇开所有的理论,实际上布局与CSS和div更快。相反,在这个方向上的创新使它变得更容易。


The issue of strictly separating presentation and content strikes me as roughly analogous to separating header files from implementation files in C++. It makes sense, but it can also be a pain. Witness Java and C# where classes are defined in a single source file. The authors of the newer languages noticed something that was causing programmers headaches and they got rid of it. That seems to be the gist of this discussion. One side is saying CSS is too difficult, the other side is saying one must become a CSS master.

对于简单的布局问题,为什么不改变表示必须完全独立的规则呢?一个新的标签(或者一些div标签的扩展)可以让我们直接在HTML中控制显示?毕竟,我们不是已经将表示泄露到HTML中了吗?看看h1, h2, h6。我们都知道这些控制表示。

阅读代码(HTML就是代码)的能力非常重要。专家们往往忽略了使编程环境尽可能为大众所接受的重要性。认为只有专业程序员才重要是非常短视的。