似乎普遍认为表不应该用于HTML中的布局.
为什么?
我从来没有(或很少诚实地)看到这方面的好论据.通常的答案是:
将内容与布局分开是件好事
但这是一个错误的论点; 陈词滥调.我想使用表格元素进行布局与表格数据几乎没有关系.所以呢?我的老板在乎吗?我的用户在乎吗?
也许我或我的开发人员必须维护一个网页关注......一个表不易维护吗?我认为使用表比使用div和CSS 更容易.
顺便说一下...为什么使用div或span将内容与布局和表格分开?只使用div来获得一个好的布局通常需要很多嵌套的div.
代码的可读性
我认为这是另一种方式.大多数人都懂HTML,很少有人理解CSS.
SEO最好不要使用表格
为什么?任何人都可以证明它是有证据的吗?或谷歌发表的声明表示,从SEO的角度来看,表格是不受欢迎的?
表格较慢.
必须插入额外的tbody元素.这是现代网络浏览器的花生.向我展示一些基准,其中使用表会显着减慢页面的速度.
如果没有桌子,布局检修会更容易,请参阅css Zen Garden.
大多数需要升级的网站也需要新内容(HTML).新版本的网站只需要新的CSS文件的情况不太可能发生.Zen Garden是一个不错的网站,但有点理论上.更不用说它滥用 CSS了.
我真的对使用divs + CSS而不是表格的好参数感兴趣.
我将一个接一个地查看你的论点并尝试在其中显示错误.
将内容与布局分开是件好事但这是一个错误的论点; 陈词滥调.
这根本不是谬误,因为HTML是故意设计的.滥用一个元素可能不是完全不可能的(毕竟,新的习语也用其他语言发展)但可能的负面影响必须得到平衡.此外,即使没有反对滥用该 所以呢?我的老板在乎吗?我的用户在乎吗? 要看.你老板尖头发吗?然后他可能不在乎.如果她有能力,那么她会关心,因为用户会. 也许我或我的开发人员必须维护一个网页关注......一个表不易维护吗?我认为使用表比使用div和css更容易. 顺便说一下...为什么使用div或span将内容与布局和表格分开?只使用div来获得一个好的布局通常需要很多嵌套的div. 深度嵌套的 代码的可读性我认为这是另一种方式.大多数人都懂html,很少了解css.它更简单. "大多数人"并不重要.专业人士很重要.对于专业人士而言,表格布局比HTML + CSS创造了更多问题.这就像说我不应该使用GVim或Emacs,因为记事本对大多数人来说更简单.或者我不应该使用LaTeX,因为MS Word对大多数人来说更简单. SEO最好不要使用表格 我不知道这是否属实,不会将其作为论据,但这是合乎逻辑的.搜索引擎搜索相关数据.虽然表格数据当然是相关的,但很少用户搜索.用户搜索页面标题中使用的术语或类似的显着位置.因此,将表格内容从过滤中排除并因此大大减少处理时间(和成本!)是合乎逻辑的. 表格较慢.必须插入额外的tbody元素.这是现代网络浏览器的花生. 额外的元素与表格较慢无关.另一方面,表的布局算法要困难得多,浏览器通常必须等待整个表加载才能开始布局内容.此外,布局的缓存将不起作用(CSS可以很容易地缓存).之前已经提到过这一切. 向我展示一些基准,其中使用表会显着减慢页面的速度. 不幸的是,我没有任何基准数据.我自己会对此感兴趣,因为这个论点缺乏某种科学严谨性是正确的. 大多数需要升级的网站也需要新内容(html).新版本的网站只需要新的css文件的情况不太可能发生. 一点也不.我曾经研究过几种情况,通过内容和设计的分离简化了设计.通常仍然需要更改一些HTML代码,但更改将始终更加局限.此外,有时必须动态地进行设计更改.考虑模板引擎,例如WordPress博客系统使用的模板引擎.表格布局实际上会杀死这个系统.我曾为类似的商业软件案件工作过.能够在不更改HTML代码的情况下更改设计是业务需求之一. 另一件事.表格布局使得自动解析网站(屏幕抓取)变得更加困难.这可能听起来微不足道,因为毕竟谁做到了?我很惊讶自己.如果有问题的服务不提供访问其数据的WebService替代方法,则屏幕抓取可以提供很多帮助.我在生物信息学领域工作,这是一个悲惨的现实.现代Web技术和Web服务尚未覆盖大多数开发人员,而且屏幕抓取通常是自动化获取数据过程的唯一方法.难怪许多生物学家仍然手动执行这些任务.对于数以千计的数据集. 这是我的程序员从一个simliar线程的回答 语义101 首先来看看这段代码,然后想一想这里有什么问题...... 当然,问题在于自行车不是汽车.汽车类对于自行车实例来说是不合适的类.代码没有错误,但在语义上是不正确的.它反映了程序员的糟糕表现. 语义102 现在将此应用于文档标记.如果您的文档需要提供表格数据,那么适当的标记就是 结论 访客会注意到吗?不,你老板在乎吗?也许.我们有时会像程序员一样偷工减料吗?当然.但是我们应该吗?不会.如果您使用语义标记,谁会受益?你 - 以及你的专业声誉.现在去做正确的事. 明显的答案:见CSS Zen Garden.如果你告诉我你可以轻松地使用基于表格的布局(请记住 - HTML没有改变),那么一定要使用表格进行布局. 另外两个重要的事情是可访问性和SEO. 两者都关心信息的呈现顺序.如果基于表格的布局将其放在页面上第二个嵌套表格的第二行的第三个单元格中,则无法在页面顶部轻松显示导航. 所以你的答案是可维护性,可访问性和SEO. 不要偷懒.即使他们有点难以学习,也要做正确的事情. 看到这个重复的问题. 您忘记的一个项目是可访问性.例如,如果您需要使用屏幕阅读器,则基于表格的布局也不会转换.如果你为政府工作,可能需要支持屏幕阅读器等可访问的浏览器. 我也认为你低估了你在问题中提到的一些事情的影响.例如,如果您既是设计师又是程序员,那么您可能无法完全理解它将表示与内容分开的程度.但是一旦你进入一个他们是两个不同角色的商店,优势就会变得更加清晰. 如果你知道自己在做什么并拥有好的工具,那么CSS确实比布局表有明显的优势.虽然每个项目本身可能不合理放弃表格,但总的来说它是值得的. 不幸的是,CSS Zen Garden不能再被用作良好的HTML/CSS设计的例子.实际上,他们最近的所有设计都使用图形进行剖面标题.这些图形文件在CSS中指定. 因此,一个网站的目的是显示保持设计内容的优势,现在定期提交将内容设计到设计中的可行性.(如果要更改HTML文件中的节标题,则不显示节标题). 这只表明即使那些主张严格的DIV和CSS宗教,也不能遵循自己的规则.您可以将其作为指导,了解您如何密切关注它们. 无论如何,这不是明确的论点,但使用CSS,您可以采用相同的标记并根据介质更改布局,这是一个很好的优势.例如,对于打印页面,您可以安静地禁止导航,而无需创建适合打印的页面. 一张布局表不会那么糟糕.但是大多数时候你只能用一张桌子就无法获得所需的布局.很快你就会有2或3个嵌套表.这变得非常麻烦.
阅读起来比较困难.这不符合意见.只有更多的嵌套标签,它们上没有识别标记. 将内容与演示文稿分开是一件好事,因为它可以让您专注于您正在做的事情.混合两个导致难以阅读的膨胀页面. 样式的CSS允许您的浏览器缓存文件,后续请求更快.这太棒了. 桌子锁定你的设计.当然,并不是每个人都需要CSS Zen Garden的灵活性,但我从未在一个我不需要在这里和那里稍微改变设计的网站上工作过.使用CSS更容易. 桌子很难打造.你没有太多的灵活性(即你仍然需要添加HTML属性来完全控制表的样式)
我可能在4年内没有使用表格来表示非表格数据.我没有回头. 我真的很想建议安迪·巴德阅读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 将内容与布局分开是件好事 这是一个谬误的论点,因为HTML表格是布局!内容是表中的数据,表示是表本身.这就是为什么有时从CSS中分离CSS非常困难的原因.你不是将内容与演示文稿分开,而是将演示文稿与演示文稿分开!一堆嵌套的div与表没有什么不同 - 它只是一组不同的标签. 将HTML与CSS分离的另一个问题是,他们需要彼此密切了解 - 你真的无法将它们完全分开.无论你做什么,HTML中的标签布局都与CSS文件紧密结合. 我认为table vs divs可以归结为你的应用程序的需求. 在我们开发的应用程序中,我们需要一个页面布局,其中的部分将动态调整其内容的大小.我花了几天时间尝试使用CSS和DIV进行跨浏览器工作,这是一个彻头彻尾的噩梦.我们切换到桌子,这一切都很有效. 但是,我们的产品拥有非常封闭的受众(我们销售带有Web界面的硬件),并且我们不关心可访问性问题.我不知道为什么屏幕阅读器不能很好地处理表格,但我想如果这是它的方式那么开发人员必须处理它. CSS/DIV - 它只是设计男孩的工作,不是吗.我花了数百小时调试DIV/CSS问题,在互联网上搜索标记的一部分与一个不起眼的浏览器一起工作 - 这让我很生气.你做了一点改变,整个布局出现了可怕的错误 - 在那里,eath就是其中的逻辑.花费数小时以这种方式移动3像素,然后用另外两个像素移动它们以使它们全部排成一行.这对我来说似乎完全没错.仅仅因为你是一个纯粹主义者并且某些事情"不是正确的事情"并不意味着你应该在所有情况下使用它,特别是如果它让你的生活更轻松1000倍. 所以我最终决定,纯粹基于商业原因,虽然我保持最低限度使用,如果我预计20小时工作以正确放置DIV,我会坚持在桌子上.这是错误的,它使纯粹主义者感到不安,但在大多数情况下,它花费的时间更少,管理成本也更低.然后我可以集中精力让应用程序按照客户的需要运行,而不是让纯粹主义者满意.他们确实支付了账单以及我对执行CSS/DIV使用的经理的论证 - 我只是指出客户支付他的薪水! 所有这些CSS/DIV参数发生的唯一原因是由于CSS的缺点,并且因为浏览器彼此不兼容,如果是这样,世界上一半的网页设计师将失去工作. 当你设计一个Windows窗体时,你不要试图在放置它们之后移动控件,所以我觉得我很奇怪你为什么要用web表单来做这个.我根本无法理解这种逻辑.获得正确的布局以及问题所在.我认为这是因为设计人员喜欢调情创意,而应用程序开发人员则更关心的是实际使应用程序正常工作,创建业务对象,实现业务规则,确定客户数据的相互关系,确保客户满足客户需求要求 - 你知道 - 就像现实世界的东西. 不要误会我的意思,这两个论点都是有效的,但请不要批评开发人员选择更简单,更合理的方法来设计表单.我们经常要担心比在div上使用表格的正确语义更重要的事情. 举个例子 - 基于这个讨论,我将一些现有的tds和trs转换为div.45分钟搞乱它试图让一切都排在一起,我放弃了.TD在10秒后回来 - 直接在所有浏览器上工作,没有其他事可做.请尽量让我理解 - 你有什么理由可以让我以任何其他方式去做! 布局应该很容易.有关如何在CSS中实现带有页眉和页脚的动态三列布局的文章的事实表明它是一个糟糕的布局系统.当然你可以让它工作,但在网上有数百篇关于如何做的文章.对于与表格类似的布局,几乎没有这样的文章,因为它显然是显而易见的.无论你对表和CSS表示什么,这一事实都解开了:CSS中基本的三列布局通常被称为"圣杯". 如果这不能让你说"WTF"那么你真的需要现在放下kool-aid. 我喜欢CSS.它提供了令人惊叹的造型选项和一些很酷的定位工具,但作为布局引擎,它是有缺陷的.需要某种类型的动态网格定位系统.一种直接的方法,可以在不知道尺寸的情况下在多个轴上对齐方框.如果你把它称为 更大的问题是,由于不承认缺少功能,CSS狂热者已经从可能的所有内容中恢复了CSS.如果CSS提供了像世界上基本上所有其他布局引擎一样体面的多轴网格定位,我会非常乐意停止使用表格.(你确实意识到除了W3C之外,所有人都已经用多种语言多次解决了这个问题,对吗?没有其他人否认这样的功能是有用的.) 叹.足够的发泄.来吧,把头伸回沙里. 根据508合规性(对于视觉上受到影响的屏幕阅读器),表格应仅用于保存数据而不用于布局,因为它会导致屏幕阅读器发生故障.或者我被告知了. 如果为每个div指定名称,也可以使用CSS将它们全部整理在一起.按照你需要的方式来坐他们只是一种痛苦. 这是最近一个项目的html部分: 这是与基于表格的布局相同的代码. 我在基于表格的布局中看到的唯一清洁是我对我的缩进过度热心的事实.我确信内容部分还有两个嵌入式表. 另一件需要考虑的事情:文件大小.我发现基于表格的布局通常是CSS对应的两倍.在我们的高速宽带上,这不是一个大问题,但它是在拨号调制解调器的人. 我想补充一点,基于div的布局更容易保持,进化和重构.只需对CSS进行一些更改即可重新排序元素并完成.根据我的经验,重新设计使用表的布局是一场噩梦(如果有嵌套表,则更多). 从语义的角度来看,您的代码也具有意义. CSS布局通常对于可访问性要好得多,只要内容以自然顺序出现并且没有样式表就有意义.而且,屏幕阅读器不仅仅是基于表格的布局:它们也使移动浏览器更难以正确呈现页面. 此外,使用基于div的布局,您可以非常轻松地使用打印样式表来执行很酷的操作,例如从打印页面中排除页眉,页脚和导航 - 我认为使用打印页面执行此操作是不可能的,或者至少要困难得多.基于表格的布局. 如果你怀疑使用div而不是使用表格来分离内容与布局的分离,请查看CSS Zen Garden中基于div的HTML ,看看如何更改样式表可以彻底改变布局,并考虑是否可以如果HTML是基于表格的,那么实现相同的布局......如果你正在进行基于表格的布局,你不可能使用CSS来控制单元格中的所有间距和填充(如果你是,那么你几乎可以肯定,首先使用浮动div等更容易.不使用CSS来控制所有这些,并且由于表格指定HTML中从左到右和从上到下的顺序,表格往往意味着您的布局在HTML中变得非常固定. 实际上我认为在不改变div的情况下完全改变基于div和CSS的设计的布局是非常困难的.但是,使用基于div和CSS的布局,可以更轻松地调整各种块之间的间距以及它们的相对大小. DIV中没有任何论据对我有利. 我会说:如果鞋子适合,请穿上它. 值得注意的是,如果不是不可能找到一个好的DIV + CSS方法来渲染内容在两列或三列中,这在所有浏览器中都是一致的,并且仍然看起来像我想要的那样. 在我的大多数布局中,这给平衡提供了一点平衡,尽管我感到内疚使用它们(dunny为什么,人们只是说它很糟糕所以我试着听它们),最后,实用主义观点是它只是我更容易和更快地使用TABLE.我没有按小时付款,所以桌子对我来说更便宜. 事实上这是一个激烈争论的问题,这证明了W3C未能预测将要尝试的布局设计的多样性.使用divs + css进行语义友好的布局是一个很好的概念,但实现的细节是如此有缺陷,以至于它们实际上限制了创作自由. 我试图将我们公司的一个站点从桌子切换到divs,这让我很头疼,因为我完全放弃了我已经投入的工作时间并回到了桌子上.试图与我的divs搏斗以获得对垂直对齐的控制已经诅咒我的主要心理问题,只要这场辩论肆虐,我将永远不会动摇. 人们必须经常提出复杂而丑陋的变通方法以实现简单的设计目标(例如垂直对齐)这一事实强烈地表明规则不够灵活.如果规格足够,那么为什么高调的网站(如SO)发现有必要使用表和其他解决方法来修改规则? 我想使用表格元素进行布局与表格数据几乎没有关系.所以呢?我的老板在乎吗?我的用户在乎吗? 谷歌和其他自动化系统确实关心,在许多情况下它们同样重要.对于非智能系统来说,语义代码更容易解析和处理. 由于必须使用涉及由某些应用程序生成的6层嵌套表的网站,并且已经生成了无效的HTML,实际上是一个3小时的工作来纠正它以打破一个小的改变. 这当然是边缘情况,但基于表格的设计是不可维护的.如果你使用css,你将样式分开,所以在修复HTML时你不必担心破坏. 另外,请尝试使用JavaScript.将单个表格单元格从一个位置移动到另一个表格中的另一个位置.执行相当复杂的div/span只能复制粘贴. "老板在乎吗" 如果我是你的老板.你会在乎的.;)如果你重视自己的生活. 布局灵活性 可维护性 我认为这艘船已经航行了.如果你看一下行业的发展方向,你会发现CSS和开放标准是该讨论的赢家.这反过来意味着大多数html工作,除了表单,设计师将使用div而不是表.我很难,因为我不是CSS大师,但就是这样. 此外,请不要忘记,表格在移动浏览器上不能很好地呈现.当然,iPhone有一个kick-ass浏览器,但每个人都没有iPhone.表格渲染可以是现代浏览器的花生,但它是移动浏览器的一堆西瓜. 我个人发现许多人使用过多的 看起来你只是习惯于表,就是这样.将布局放在表格中会限制您只使用该布局.使用CSS你可以移动位,看看http://csszengarden.com/
不,布局通常不需要很多嵌套的div. 由于没有用于布局和正确语义的表格,因此HTML更加清晰,因此更易于阅读.为什么不能理解CSS的人会尝试阅读它?如果有人认为自己是web开发者,那么掌握CSS是必须的. SEO的好处来自于能够将最重要的内容放在页面上方并具有更好的内容到标记比率. http://www.hotdesign.com/seybold/
508合规性 - 屏幕阅读器能够理解您的标记. 等待渲染 - 表格不会在浏览器中呈现,直到它到达 围绕语义标记的整个想法是标记和表示的分离,包括布局. Div不是替换表,它们在将内容分成相关内容块(,)时有自己的用途.当您没有技能并且依赖于表格时,您通常必须将内容分离到单元格以获得所需的布局,但在使用语义标记时,您不需要触摸标记来实现演示.在生成标记而不是静态页面时,这非常重要. 开发人员需要停止提供暗示布局的标记,以便我们这些具有呈现内容技能的人可以继续我们的工作,并且开发人员不必回到他们的代码来在演示需求发生变化时进行更改.元素的论据,也可能有明天,因为浏览器供应商对该元素应用特殊处理的方式.毕竟,他们知道"
元素仅用于表格数据",并且可能会使用这个事实来改进渲染引擎,在此过程中巧妙地改变
行为方式,从而打破以前被滥用的情况.
大多数专业网站开发人员似乎反对你[ 引证需要 ].这表是实际上少维护的应该是显而易见的.使用表格进行布局意味着更改公司布局实际上意味着更改每一页.这可能非常昂贵.另一方面,明智地使用与CSS结合的语义上有意义的HTML 可能会将这些更改限制在CSS和所使用的图片中.
"改变公司布局实际上意味着改变每一页" - 人们是否仍然在每一页上复制公司布局?使用.net中的母版页或用户控件解决这个问题很容易,包括php或经典asp中的文件等等......任何复制公司布局的人都值得一试!;-)
获取屏幕阅读器并让它读取带有表格布局的页面.就这些.
对不起,这真的是"天上掉馅饼"的一厢情愿.用户关心?没有.除了少数被误导的修正主义者之外,没有人关心.HTML(包括表格)比"语义与布局"这一相对较新的概念要早得多.哦,请来源"大多数专业网站开发者反对你".
上面的错字:语义从*开始暗示*.HTML中的始终仅用于表格数据,从不用于布局(在早期,无论如何都无法更改表格,因此无法将其用作布局锚点).事实上,HTML的早期草稿根本没有布局概念,HTML从来不是用于布局,而是用于构造文本.更重要的是:HTML的第一个提议反复警告不要滥用标签来影响布局,并注意使用逻辑优于物理标记.
@Sergio:请不要编辑相关信息.这个*是*我在那里使用的一个无源的可疑声明,我想说清楚.你的编辑在我的嘴里声称我无法备份,如果事实证明这是假的,实际上让我变成了骗子.
"搜索引擎搜索相关数据.虽然表格数据当然是相关的,但用户搜索的内容很少." 除非每个人和他们的狗使用表格来构建布局,搜索引擎应该(并且确实)相应地处理表格的内容,否则它们将不相关.不过,我同意你的其他帖子.
克莱图斯:想到这一点,"多数"的事情很可能是错的.关于其他人,我热烈地不同意你的意见.一开始就隐含了语义学,尽管它们的真正优势随着时间的推移变得更加清晰和重要.在这方面,是的,标准*被修改了.所以呢?为什么会被误导?用户关心吗?也许不是今天,但他们肯定在拨号时,当friggin'网站只是不加载bc'时,浏览器在开始显示之前等待整个表.辩论是否已过时?不,因为内容和布局之间的分离更加清晰......
@Kaizoku在电子邮件中使用了表格,因为(遗憾地/无论好坏)大多数电子邮件客户端都不允许使用完整的css规范,因此可以看到"更容易"将电子邮件作为表格进行处理.(我知道这是邪恶的)
2> Carl Camera..:class car {
int wheels = 4;
string engine;
}
car mybike = new car();
mybike.wheels = 2;
mybike.engine = null;
.但是,如果将导航放入表中,则会误用
元素的预期用途.在第二种情况下,您没有呈现表格数据 - 您(错误地)使用该
元素来实现表达目标.
很好的比喻,很好的结论.为什么任何人都必须被一个老板和/或用户强迫做正确的事情?难道没有人为自己的工作感到自豪吗?
对不起,那里没有水.你不会将汽车用于mybike,因为你会定义一个"自行车"类.您无法为""定义其他内容,因为它不仅仅是一个简单的语义标记 - 它还告诉浏览器如何呈现其内容.
我认为这是一个相当傲慢的帖子,它没有解释任何事情,只是在没有回答问题的情况下再次重复相同的说法.我不明白为什么会有这么多的赞成?
@tharkun&Richard:为什么"语义错误"是主观的,不解释什么?
我同意tharkum.这种反应是相当主观的,并没有真正回答提出的问题.虽然我同意DIV应该用于页面布局,但我无法想象任何网页设计师会因为基于表格的布局而感到困惑.
@bno是的,你必须接受我的前提,即工具滥用对工匠的影响很小,不能接受我的结论,即正确的工具使用对工匠有积极的反映.如果没有,那么使用ul进行缩进或使用blockquote进行边距也不会打扰你.
"我无法想象任何网页设计师会因基于表格的布局而感到困惑"没有Firebug我永远不会理解嵌套的表格布局.
究竟.你会使用自行车课程.这就是重点.你应该使用合适的东西.你不会将汽车类用于mybike只是因为它的Render()方法很好地格式化了.你可以让自行车类呈现你想要的样子.
我担心这是我希望避免的那种谬误."你 - 以及你的职业声誉.现在去做正确的事." 这是在乞求这个问题.(它假设专业态度使用CSS,而这是要证明的事情.)
到目前为止,我已经多次通过嵌套表格布局,理查德E的评论让我的大脑受到了伤害.
当我完全没有理由时,我认为将我的结论作为谬误推理来攻击是不公平的 - 这是一个结论.我的理由在前面的段落中:"你滥用表元素来实现一个表达目标" - 使用表元素来实现它从未想要的东西.
我认为重点还在于系统中需要松散耦合.使用表而不是DIVs + CSS来定义布局等同于紧耦合系统.更多关于松散耦合的信息:http://en.wikipedia.org/wiki/Loose_coupling
@Carl Camera:该句子没有显示使用表格元素表示目标的负面后果.要说"它对程序员反映不佳"并质疑"专业"的态度,这个问题的答案是"乞讨".
3> erlando..:
Zen Garden中经常使用的技巧是用图像替换文本,并在CSS中定义它,从而使其在HTML中不可见.非常非常错误.
如果仔细查看某些设计,某些标题中的文本与HTML中的文本不同.那是因为HTML变得不可见,而是插入了图像.(例如:http://csszengarden.com/?cssfile =/12/212.css&page = 0,"路径?到?成就?")
对不起,绝对没有证据证明div布局更适合SEO.此外,谷歌自己已经声明HTML验证对他们来说并不重要 - 一个略有不同的问题,但一个针对表,因为他们很少验证.
对不起,但那不对.文本仍然在HTML中 - 这是CSSZG设计的要求之一.HTML必须保持不变.
4> Joel Coehoor..:
我真的很喜欢这个答案.使用具有语义意义的标签不仅仅是传统问题,它允许那些模糊的非浏览器(屏幕阅读器,屏幕抓取器,各种解析器)正确地对页面上的各种对象进行分类.
我希望有人会提到这一点.可访问性应该是首要任务!
5> James Curran..:
@Ambrose:因为friggin'网站的重点是展示内容和风格的分离.内容和风格应该由不同的人妥善处理,他们都不应该"记住"其他人改变了什么.
你的意思是他们正在做` Some Text h1>`然后在他们的css中:`h1 {background-image('foo.jpg'); text-indent:-3000px}`?这是*正确*的方式,因为你在无样式的html中保留了最大的语义信息.或许我误解了你.
凯伦是对的,你错了,詹姆斯.你的榜样是一个稻草人.忘记在更改语义HTML时更改图像将是愚蠢的.所以将你的笔记本电脑留在公共汽车上.你想说什么?
@James:内容和风格并不总是由不同的人处理.内容风格化后,必须进行协作.如何` h1>`比`
Something h1>`更难以维护?在任何一个例子中,something.png都需要更新.但第二个例子更容易获得.
S&N先生:这会让事情变得更糟.您必须以正确的方式动态生成新图像.所以现在你已经将样式从CSS转移到业务层代码.
在我的例子中有一个干净的休息:CSS简单地说明内容的风格是使用图像.但是,无论是否使用CSS,图像*的*内容都必须由图形专业人员更改.这个例子反对使用图形标题而不是CSS的情况.
@Josh:我不同意.CSS的重点是在两者之间保持干净.
6> 小智..:
7> Ben Scheirma..:
8> 17 of 26..:
但这是一个错误的论点; 陈词滥调
仅仅因为或
屏幕阅读器处理表确定..这是表格不处理屏幕阅读器的问题.基于表格的布局易于以不可访问的方式呈现信息.想想右侧导航的样子.这将是相当遥远的页面.
9> 小智..:
知道什么使网站范围的变更易于管理?**MVC**和**模板系统**
10> 小智..:或
元素的末尾.
11> Rob..:
12> Ross..:
Navitem
Navitem
Footer
但是css文件只需要下载一次,因为每个页面请求都会重新发送整个表结构.
@Draemon:也许你想举个例子?
速度并不是受大文件影响的唯一因素:许多公司为带宽付费.如果你可以通过编码很好地将客户的带宽费用削减一半,这是一个很大的优势.
你选择了一个非常适合div + css的设计,并证明它在基于表格的设计中更加冗长?那么:创建一个非常适合基于表格的布局的设计同样容易,并展示你必须跳过来在CSS中复制它的箍.
是的,但不要忘记,虽然HTML可能是无CSS布局的两倍大,但使用DIV + CSS布局将导致(至少)CSS文件的额外HTTP请求,以及文件本身.
13> Guido..:
14> MB...:
15> Radu094..:
16> DLH..:
17> ceejayoz..:
-1:如果您使用表格进行布局,Google绝对不会在意.
18> Kent Fredric..:
19> Nathan Long..:
想象一下,您正在创建一个包含大量缩略图的页面.
DIV:
如果你将每个缩略图放在DIV中,向左浮动,可能其中10个适合一行.使窗口变窄,BAM - 它连续6个,或2个,或者多个适合.
表:
您必须明确说明一行中有多少个单元格.如果窗口太窄,则用户必须水平滚动.
与上述情况相同.现在,您要向第三行添加三个缩略图.
DIV:
添加它们.布局将自动调整.
表:
将新单元格粘贴到第三行.哎呀!现在那里的物品太多了.从该行中切出一些并将它们放在第四行.现在那里的物品太多了.从该行中删除一些...(等)
(当然,如果您使用服务器端脚本生成行和单元格,这可能不会成为问题.)
)
20> 小智..:
21> Swati..:
22> Rimantas..:
23> Rick Glos..:
24> Steve Perks..:
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有