似乎普遍认为表不应该用于HTML中的布局.
为什么？
我从来没有(或很少诚实地)看到这方面的好论据.通常的答案是:
将内容与布局分开是件好事
但这是一个错误的论点; 陈词滥调.我想使用表格元素进行布局与表格数据几乎没有关系.所以呢？我的老板在乎吗？我的用户在乎吗？
也许我或我的开发人员必须维护一个网页关注......一个表不易维护吗？我认为使用表比使用div和CSS 更容易.
顺便说一下...为什么使用div或span将内容与布局和表格分开？只使用div来获得一个好的布局通常需要很多嵌套的div.
代码的可读性
我认为这是另一种方式.大多数人都懂HTML,很少有人理解CSS.
SEO最好不要使用表格
为什么？任何人都可以证明它是有证据的吗？或谷歌发表的声明表示,从SEO的角度来看,表格是不受欢迎的？
表格较慢.
必须插入额外的tbody元素.这是现代网络浏览器的花生.向我展示一些基准,其中使用表会显着减慢页面的速度.
如果没有桌子,布局检修会更容易,请参阅css Zen Garden.
大多数需要升级的网站也需要新内容(HTML).新版本的网站只需要新的CSS文件的情况不太可能发生.Zen Garden是一个不错的网站,但有点理论上.更不用说它滥用 CSS了.
我真的对使用divs + CSS而不是表格的好参数感兴趣.
Kon*_*lph 496
我将一个接一个地查看你的论点并尝试在其中显示错误.
将内容与布局分开是件好事但这是一个错误的论点; 陈词滥调.
这根本不是谬误,因为HTML是故意设计的.滥用一个元素可能不是完全不可能的(毕竟,新的习语也用其他语言发展)但可能的负面影响必须得到平衡.此外,即使没有反对滥用该<table>元素的论据,也可能有明天,因为浏览器供应商对该元素应用特殊处理的方式.毕竟,他们知道" <table>元素仅用于表格数据",并且可能会使用这个事实来改进渲染引擎,在此过程中巧妙地改变<table>行为方式,从而打破以前被滥用的情况.
所以呢？我的老板在乎吗？我的用户在乎吗？
要看.你老板尖头发吗？然后他可能不在乎.如果她有能力,那么她会关心,因为用户会.
也许我或我的开发人员必须维护一个网页关注......一个表不易维护吗？我认为使用表比使用div和css更容易.
大多数专业网站开发人员似乎反对你[ 引证需要 ].这表是实际上少维护的应该是显而易见的.使用表格进行布局意味着更改公司布局实际上意味着更改每一页.这可能非常昂贵.另一方面,明智地使用与CSS结合的语义上有意义的HTML 可能会将这些更改限制在CSS和所使用的图片中.
顺便说一下...为什么使用div或span将内容与布局和表格分开？只使用div来获得一个好的布局通常需要很多嵌套的div.
深度嵌套的<div>s是一种反模式,就像表格布局一样.优秀的网页设计师不需要很多.另一方面,即使是这种深层嵌套的div也没有很多表格布局的问题.事实上,他们甚至可以通过逻辑划分部分内容来促进语义结构.
代码的可读性我认为这是另一种方式.大多数人都懂html,很少了解css.它更简单.
"大多数人"并不重要.专业人士很重要.对于专业人士而言,表格布局比HTML + CSS创造了更多问题.这就像说我不应该使用GVim或Emacs,因为记事本对大多数人来说更简单.或者我不应该使用LaTeX,因为MS Word对大多数人来说更简单.
SEO最好不要使用表格
我不知道这是否属实,不会将其作为论据,但这是合乎逻辑的.搜索引擎搜索相关数据.虽然表格数据当然是相关的,但很少用户搜索.用户搜索页面标题中使用的术语或类似的显着位置.因此,将表格内容从过滤中排除并因此大大减少处理时间(和成本!)是合乎逻辑的.
表格较慢.必须插入额外的tbody元素.这是现代网络浏览器的花生.
额外的元素与表格较慢无关.另一方面,表的布局算法要困难得多,浏览器通常必须等待整个表加载才能开始布局内容.此外,布局的缓存将不起作用(CSS可以很容易地缓存).之前已经提到过这一切.
向我展示一些基准,其中使用表会显着减慢页面的速度.
不幸的是,我没有任何基准数据.我自己会对此感兴趣,因为这个论点缺乏某种科学严谨性是正确的.
大多数需要升级的网站也需要新内容(html).新版本的网站只需要新的css文件的情况不太可能发生.
一点也不.我曾经研究过几种情况,通过内容和设计的分离简化了设计.通常仍然需要更改一些HTML代码,但更改将始终更加局限.此外,有时必须动态地进行设计更改.考虑模板引擎,例如WordPress博客系统使用的模板引擎.表格布局实际上会杀死这个系统.我曾为类似的商业软件案件工作过.能够在不更改HTML代码的情况下更改设计是业务需求之一.
另一件事.表格布局使得自动解析网站(屏幕抓取)变得更加困难.这可能听起来微不足道,因为毕竟谁做到了？我很惊讶自己.如果有问题的服务不提供访问其数据的WebService替代方法,则屏幕抓取可以提供很多帮助.我在生物信息学领域工作,这是一个悲惨的现实.现代Web技术和Web服务尚未覆盖大多数开发人员,而且屏幕抓取通常是自动化获取数据过程的唯一方法.难怪许多生物学家仍然手动执行这些任务.对于数以千计的数据集.
Car*_*era 290
这是我的程序员从一个simliar线程的回答
语义101
首先来看看这段代码,然后想一想这里有什么问题......
class car {
int wheels = 4;
string engine;
}
car mybike = new car();
mybike.wheels = 2;
mybike.engine = null;
当然,问题在于自行车不是汽车.汽车类对于自行车实例来说是不合适的类.代码没有错误,但在语义上是不正确的.它反映了程序员的糟糕表现.
语义102
现在将此应用于文档标记.如果您的文档需要提供表格数据,那么适当的标记就是<table>.但是,如果将导航放入表中,则会误用<table>元素的预期用途.在第二种情况下,您没有呈现表格数据 - 您(错误地)使用该<table>元素来实现表达目标.
结论
访客会注意到吗？不,你老板在乎吗？也许.我们有时会像程序员一样偷工减料吗？当然.但是我们应该吗？不会.如果您使用语义标记,谁会受益？你 - 以及你的专业声誉.现在去做正确的事.
erl*_*ndo 104
明显的答案:见CSS Zen Garden.如果你告诉我你可以轻松地使用基于表格的布局(请记住 - HTML没有改变),那么一定要使用表格进行布局.
另外两个重要的事情是可访问性和SEO.
两者都关心信息的呈现顺序.如果基于表格的布局将其放在页面上第二个嵌套表格的第二行的第三个单元格中,则无法在页面顶部轻松显示导航.
所以你的答案是可维护性,可访问性和SEO.
不要偷懒.即使他们有点难以学习,也要做正确的事情.
Joe*_*orn 91
您忘记的一个项目是可访问性.例如,如果您需要使用屏幕阅读器,则基于表格的布局也不会转换.如果你为政府工作,可能需要支持屏幕阅读器等可访问的浏览器.
我也认为你低估了你在问题中提到的一些事情的影响.例如,如果您既是设计师又是程序员,那么您可能无法完全理解它将表示与内容分开的程度.但是一旦你进入一个他们是两个不同角色的商店,优势就会变得更加清晰.
如果你知道自己在做什么并拥有好的工具,那么CSS确实比布局表有明显的优势.虽然每个项目本身可能不合理放弃表格,但总的来说它是值得的.
Jam*_*ran 54
不幸的是,CSS Zen Garden不能再被用作良好的HTML/CSS设计的例子.实际上,他们最近的所有设计都使用图形进行剖面标题.这些图形文件在CSS中指定.
因此,一个网站的目的是显示保持设计内容的优势,现在定期提交将内容设计到设计中的可行性.(如果要更改HTML文件中的节标题,则不显示节标题).
这只表明即使那些主张严格的DIV和CSS宗教,也不能遵循自己的规则.您可以将其作为指导,了解您如何密切关注它们.
Ben*_*man 45
一张布局表不会那么糟糕.但是大多数时候你只能用一张桌子就无法获得所需的布局.很快你就会有2或3个嵌套表.这变得非常麻烦.
阅读起来比较困难.这不符合意见.只有更多的嵌套标签,它们上没有识别标记.
将内容与演示文稿分开是一件好事,因为它可以让您专注于您正在做的事情.混合两个导致难以阅读的膨胀页面.
样式的CSS允许您的浏览器缓存文件,后续请求更快.这太棒了.
桌子锁定你的设计.当然,并不是每个人都需要CSS Zen Garden的灵活性,但我从未在一个我不需要在这里和那里稍微改变设计的网站上工作过.使用CSS更容易.
桌子很难打造.你没有太多的灵活性(即你仍然需要添加HTML属性来完全控制表的样式)
我可能在4年内没有使用表格来表示非表格数据.我没有回头.
我真的很想建议安迪·巴德阅读CSS Mastery.这是梦幻般的.
17 *_* 26 36
将内容与布局分开是件好事
但这是一个错误的论点; 陈词滥调
这是一个谬误的论点,因为HTML表格是布局!内容是表中的数据,表示是表本身.这就是为什么有时从CSS中分离CSS非常困难的原因.你不是将内容与演示文稿分开,而是将演示文稿与演示文稿分开!一堆嵌套的div与表没有什么不同 - 它只是一组不同的标签.
将HTML与CSS分离的另一个问题是,他们需要彼此密切了解 - 你真的无法将它们完全分开.无论你做什么,HTML中的标签布局都与CSS文件紧密结合.
我认为table vs divs可以归结为你的应用程序的需求.
在我们开发的应用程序中,我们需要一个页面布局,其中的部分将动态调整其内容的大小.我花了几天时间尝试使用CSS和DIV进行跨浏览器工作,这是一个彻头彻尾的噩梦.我们切换到桌子,这一切都很有效.
但是,我们的产品拥有非常封闭的受众(我们销售带有Web界面的硬件),并且我们不关心可访问性问题.我不知道为什么屏幕阅读器不能很好地处理表格,但我想如果这是它的方式那么开发人员必须处理它.
小智 23
CSS/DIV - 它只是设计男孩的工作,不是吗.我花了数百小时调试DIV/CSS问题,在互联网上搜索标记的一部分与一个不起眼的浏览器一起工作 - 这让我很生气.你做了一点改变,整个布局出现了可怕的错误 - 在那里,eath就是其中的逻辑.花费数小时以这种方式移动3像素,然后用另外两个像素移动它们以使它们全部排成一行.这对我来说似乎完全没错.仅仅因为你是一个纯粹主义者并且某些事情"不是正确的事情"并不意味着你应该在所有情况下使用它,特别是如果它让你的生活更轻松1000倍.
所以我最终决定,纯粹基于商业原因,虽然我保持最低限度使用,如果我预计20小时工作以正确放置DIV,我会坚持在桌子上.这是错误的,它使纯粹主义者感到不安,但在大多数情况下,它花费的时间更少,管理成本也更低.然后我可以集中精力让应用程序按照客户的需要运行,而不是让纯粹主义者满意.他们确实支付了账单以及我对执行CSS/DIV使用的经理的论证 - 我只是指出客户支付他的薪水!
所有这些CSS/DIV参数发生的唯一原因是由于CSS的缺点,并且因为浏览器彼此不兼容,如果是这样,世界上一半的网页设计师将失去工作.
当你设计一个Windows窗体时,你不要试图在放置它们之后移动控件,所以我觉得我很奇怪你为什么要用web表单来做这个.我根本无法理解这种逻辑.获得正确的布局以及问题所在.我认为这是因为设计人员喜欢调情创意,而应用程序开发人员则更关心的是实际使应用程序正常工作,创建业务对象,实现业务规则,确定客户数据的相互关系,确保客户满足客户需求要求 - 你知道 - 就像现实世界的东西.
不要误会我的意思,这两个论点都是有效的,但请不要批评开发人员选择更简单,更合理的方法来设计表单.我们经常要担心比在div上使用表格的正确语义更重要的事情.
举个例子 - 基于这个讨论,我将一些现有的tds和trs转换为div.45分钟搞乱它试图让一切都排在一起,我放弃了.TD在10秒后回来 - 直接在所有浏览器上工作,没有其他事可做.请尽量让我理解 - 你有什么理由可以让我以任何其他方式去做!
小智 21
布局应该很容易.有关如何在CSS中实现带有页眉和页脚的动态三列布局的文章的事实表明它是一个糟糕的布局系统.当然你可以让它工作,但在网上有数百篇关于如何做的文章.对于与表格类似的布局,几乎没有这样的文章,因为它显然是显而易见的.无论你对表和CSS表示什么,这一事实都解开了:CSS中基本的三列布局通常被称为"圣杯".
如果这不能让你说"WTF"那么你真的需要现在放下kool-aid.
我喜欢CSS.它提供了令人惊叹的造型选项和一些很酷的定位工具,但作为布局引擎,它是有缺陷的.需要某种类型的动态网格定位系统.一种直接的方法,可以在不知道尺寸的情况下在多个轴上对齐方框.如果你把它称为<table>或<gridlayout>或其他什么,我不会给出该死的,但这是CSS缺少的基本布局功能.
更大的问题是,由于不承认缺少功能,CSS狂热者已经从可能的所有内容中恢复了CSS.如果CSS提供了像世界上基本上所有其他布局引擎一样体面的多轴网格定位,我会非常乐意停止使用表格.(你确实意识到除了W3C之外,所有人都已经用多种语言多次解决了这个问题,对吗？没有其他人否认这样的功能是有用的.)
叹.足够的发泄.来吧,把头伸回沙里.
Rob*_*Rob 19
根据508合规性(对于视觉上受到影响的屏幕阅读器),表格应仅用于保存数据而不用于布局,因为它会导致屏幕阅读器发生故障.或者我被告知了.
如果为每个div指定名称,也可以使用CSS将它们全部整理在一起.按照你需要的方式来坐他们只是一种痛苦.
Ros*_*oss 18
这是最近一个项目的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对应的两倍.在我们的高速宽带上,这不是一个大问题,但它是在拨号调制解调器的人.
MB.*_*MB. 13
CSS布局通常对于可访问性要好得多,只要内容以自然顺序出现并且没有样式表就有意义.而且,屏幕阅读器不仅仅是基于表格的布局:它们也使移动浏览器更难以正确呈现页面.
此外,使用基于div的布局,您可以非常轻松地使用打印样式表来执行很酷的操作,例如从打印页面中排除页眉,页脚和导航 - 我认为使用打印页面执行此操作是不可能的,或者至少要困难得多.基于表格的布局.
如果你怀疑使用div而不是使用表格来分离内容与布局的分离,请查看CSS Zen Garden中基于div的HTML ,看看如何更改样式表可以彻底改变布局,并考虑是否可以如果HTML是基于表格的,那么实现相同的布局......如果你正在进行基于表格的布局,你不可能使用CSS来控制单元格中的所有间距和填充(如果你是,那么你几乎可以肯定,首先使用浮动div等更容易.不使用CSS来控制所有这些,并且由于表格指定HTML中从左到右和从上到下的顺序,表格往往意味着您的布局在HTML中变得非常固定.
实际上我认为在不改变div的情况下完全改变基于div和CSS的设计的布局是非常困难的.但是,使用基于div和CSS的布局,可以更轻松地调整各种块之间的间距以及它们的相对大小.
Rad*_*094 13
DIV中没有任何论据对我有利.
我会说:如果鞋子适合,请穿上它.
值得注意的是,如果不是不可能找到一个好的DIV + CSS方法来渲染内容在两列或三列中,这在所有浏览器中都是一致的,并且仍然看起来像我想要的那样.
在我的大多数布局中,这给平衡提供了一点平衡,尽管我感到内疚使用它们(dunny为什么,人们只是说它很糟糕所以我试着听它们),最后,实用主义观点是它只是我更容易和更快地使用TABLE.我没有按小时付款,所以桌子对我来说更便宜.
DLH*_*DLH 13
事实上这是一个激烈争论的问题,这证明了W3C未能预测将要尝试的布局设计的多样性.使用divs + css进行语义友好的布局是一个很好的概念,但实现的细节是如此有缺陷,以至于它们实际上限制了创作自由.
我试图将我们公司的一个站点从桌子切换到divs,这让我很头疼,因为我完全放弃了我已经投入的工作时间并回到了桌子上.试图与我的divs搏斗以获得对垂直对齐的控制已经诅咒我的主要心理问题,只要这场辩论肆虐,我将永远不会动摇.
人们必须经常提出复杂而丑陋的变通方法以实现简单的设计目标(例如垂直对齐)这一事实强烈地表明规则不够灵活.如果规格足够,那么为什么高调的网站(如SO)发现有必要使用表和其他解决方法来修改规则？
cee*_*yoz 12
我想使用表格元素进行布局与表格数据几乎没有关系.所以呢？我的老板在乎吗？我的用户在乎吗？
谷歌和其他自动化系统确实关心,在许多情况下它们同样重要.对于非智能系统来说,语义代码更容易解析和处理.
由于必须使用涉及由某些应用程序生成的6层嵌套表的网站,并且已经生成了无效的HTML,实际上是一个3小时的工作来纠正它以打破一个小的改变.
这当然是边缘情况,但基于表格的设计是不可维护的.如果你使用css,你将样式分开,所以在修复HTML时你不必担心破坏.
另外,请尝试使用JavaScript.将单个表格单元格从一个位置移动到另一个表格中的另一个位置.执行相当复杂的div/span只能复制粘贴.
"老板在乎吗"
如果我是你的老板.你会在乎的.;)如果你重视自己的生活.
布局灵活性
想象一下,您正在创建一个包含大量缩略图的页面.
DIV:
如果你将每个缩略图放在DIV中,向左浮动,可能其中10个适合一行.使窗口变窄,BAM - 它连续6个,或2个,或者多个适合.
表:
您必须明确说明一行中有多少个单元格.如果窗口太窄,则用户必须水平滚动.
可维护性
与上述情况相同.现在,您要向第三行添加三个缩略图.
DIV:
添加它们.布局将自动调整.
表:
将新单元格粘贴到第三行.哎呀!现在那里的物品太多了.从该行中切出一些并将它们放在第四行.现在那里的物品太多了.从该行中删除一些...(等)
(当然,如果您使用服务器端脚本生成行和单元格,这可能不会成为问题.)
小智 7
我认为这艘船已经航行了.如果你看一下行业的发展方向,你会发现CSS和开放标准是该讨论的赢家.这反过来意味着大多数html工作,除了表单,设计师将使用div而不是表.我很难,因为我不是CSS大师,但就是这样.
此外,请不要忘记,表格在移动浏览器上不能很好地呈现.当然,iPhone有一个kick-ass浏览器,但每个人都没有iPhone.表格渲染可以是现代浏览器的花生,但它是移动浏览器的一堆西瓜.
我个人发现许多人使用过多的<div>标签,但在适度的情况下,它可以非常干净且易于阅读.你提到人们阅读CSS比阅读表更难; 在'代码'方面可能是真的; 但是在阅读内容方面(视图>源代码),使用样式表比使用表格更容易理解结构.
看起来你只是习惯于表,就是这样.将布局放在表格中会限制您只使用该布局.使用CSS你可以移动位,看看http://csszengarden.com/ 不,布局通常不需要很多嵌套的div.
由于没有用于布局和正确语义的表格,因此HTML更加清晰,因此更易于阅读.为什么不能理解CSS的人会尝试阅读它？如果有人认为自己是web开发者,那么掌握CSS是必须的.
SEO的好处来自于能够将最重要的内容放在页面上方并具有更好的内容到标记比率.
http://www.hotdesign.com/seybold/
围绕语义标记的整个想法是标记和表示的分离,包括布局.
Div不是替换表,它们在将内容分成相关内容块(,)时有自己的用途.当您没有技能并且依赖于表格时,您通常必须将内容分离到单元格以获得所需的布局,但在使用语义标记时,您不需要触摸标记来实现演示.在生成标记而不是静态页面时,这非常重要.
开发人员需要停止提供暗示布局的标记,以便我们这些具有呈现内容技能的人可以继续我们的工作,并且开发人员不必回到他们的代码来在演示需求发生变化时进行更改.
| 归档时间： |
|
| 查看次数： |
449845 次 |
| 最近记录： |