关于css:为什么不在HTML中使用表格进行布局?

Why not use tables for layout in HTML?

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

为什么?

我从来没有(或很少诚实地)看到过这方面的好论据。通常的答案是:

  • 把内容和布局分开是很好的,但这是一个错误的论点;陈词滥调的想法。我想使用table元素进行布局与表格数据几乎没有关系,这是真的。那又怎么样?我老板在乎吗?我的用户关心吗?也许我或我的开发人员同事必须维护网页维护…表的可维护性是否较低?我认为使用表格比使用div和css更容易。为什么使用DIV或SPAN可以很好地将内容与布局和表分开?只使用div获得一个好的布局通常需要很多嵌套的div。

  • 代码的可读性我认为这是另一种方式。大多数人懂HTML,很少人懂CSS。

  • SEO最好不要使用表格。为什么?有人能出示证据吗?或者谷歌的一句话,从搜索引擎优化的角度来看,表格是不鼓励的?

  • 表格速度较慢。必须插入额外的tbody元素。这对于现代网络浏览器来说是微不足道的。向我展示一些基准,在这些基准中,表的使用会显著降低页面的速度。

  • 如果没有表格,布局的修改会更容易,请参阅css zen garden。大多数需要升级的网站也需要新内容(html)。一个新版本的网站只需要一个新的CSS文件的情况不太可能发生。禅园是一个不错的网站,但有点理论化。更不用说它滥用了CSS。

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


我将逐一讨论你的论点,并试图指出其中的错误。好的。

It's good to separate content from layout
But this is a fallacious argument; Cliché Thinking.

Ok.

这完全不是错误的,因为HTML是故意设计的。对一个元素的误用可能不是完全不可能的(毕竟,在其他语言中也开发出了新的习语),但必须平衡可能的负面影响。此外,即使今天没有反对滥用

元素的论据,但由于浏览器供应商对元素应用特殊处理的方式,明天可能会出现。毕竟,他们知道"

元素仅用于表格数据",并可能利用这一事实来改进渲染引擎,在这个过程中微妙地改变

的行为方式,从而打破以前使用不当的情况。好的。

So what? Does my boss care? Do my users care?

Ok.

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

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.

Ok.

大多数专业的Web开发人员似乎都反对您的做法。事实上,表的可维护性较低应该是显而易见的。使用表格进行布局意味着更改公司布局实际上意味着更改每个页面。这可能很贵。另一方面,明智地将语义上有意义的HTML与CSS结合使用,可能会限制对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.

Ok.

深度嵌套的是反模式的,就像表布局一样。优秀的网页设计师不需要很多。另一方面,即使如此深的嵌套div也不存在许多表布局问题。事实上,它们甚至可以通过逻辑地将内容分为多个部分来促进语义结构。好的。

Readability of the code
I think it's the other way around. Most people understand html, little understand css. It's simpler.

Ok.

"大多数人"不重要。专业人士很重要。对于专业人员来说,表格布局比HTML+CSS产生更多的问题。这就像是说我不应该使用gvim或emacs,因为记事本对大多数人来说更简单。或者我不应该使用乳胶,因为MS Word对大多数人来说更简单。好的。< Buff行情>

SEO最好不要使用表格好的。< /块引用>

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

Tables are slower.
An extra tbody element has to be inserted. This is peanuts for modern web browsers.

Ok.

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

Show me some benchmarks where the use of a table significantly slows down a page.

Ok.

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

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.

Ok.

一点也不。我已经处理过几个案例,其中通过内容和设计的分离简化了更改设计。通常仍有必要更改一些HTML代码,但更改将始终受到更大的限制。此外,设计变更有时必须动态进行。考虑模板引擎,比如WordPress博客系统使用的模板引擎。表布局实际上会破坏这个系统。我为一个商业软件做过类似的案例。能够在不更改HTML代码的情况下更改设计是业务需求之一。好的。

另外一件事。表布局使得网站的自动解析(屏幕抓取)更加困难。这听起来可能微不足道,因为毕竟是谁干的?我自己也很惊讶。如果所讨论的服务没有提供访问其数据的WebService替代方案,那么屏幕抓取会有很大帮助。我在生物信息学工作,这是一个可悲的现实。现代Web技术和Web服务还没有达到大多数开发人员的要求,通常,屏幕抓取是实现数据获取过程自动化的唯一方法。难怪许多生物学家仍然手工完成这些任务。用于数千个数据集。好的。好啊。

总是只用于表格数据,而不用于布局(早在几年前,您无论如何都不能更改表的外观,从而阻止将其用作布局锚定)。事实上,HTML的早期草稿根本没有布局概念,而且HTML从来就不是用于布局,而是用于构造文本。更重要的是:HTML的第一个提议反复警告不要滥用标签来影响布局,并警告使用逻辑标记而不是物理标记。
  • 获取一个屏幕阅读器,让它读取一个带有表布局的页面。仅此而已。
  • "搜索引擎搜索相关数据。虽然表格数据当然是相关的,但很少有用户搜索的内容。"除了每个人和他们的狗使用表格来构建布局,搜索引擎应该(实际上)相应地处理表格的内容,否则它们就不相关了。不过,我同意你余下的职位。
  • @塞吉奥:请不要删掉相关信息。这是我在那里使用的一个毫无根据的可疑声明,我想说得很清楚。你的编辑在我嘴里说了一句我不能支持的话,实际上如果这是假的话,我就成了一个骗子。
  • 为什么在HTML电子邮件中使用表格而不是div?
  • @Kaizoku表格在电子邮件中使用是因为(遗憾的是,无论好坏)大多数电子邮件客户不允许使用完整的CSS规范,因此将电子邮件作为表格进行处理被视为"更容易"。(我知道这很邪恶)

  • 这是我的程序员从模拟线程得到的答案

    语义学101

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

    1
    2
    3
    4
    5
    6
    7
    8
    class car {
        int wheels = 4;
        string engine;
    }

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

    当然,问题是自行车不是汽车。car类对于bike实例来说是不合适的类。代码没有错误,但在语义上不正确。它对程序员的影响很差。

    语义学102

    现在将此应用于文档标记。如果您的文档需要显示表格数据,那么适当的标记应该是

    。但是,如果您将导航放到一个表中,那么您就误用了

    元素的预期用途。在第二种情况下,您没有呈现表格数据——您(mis)使用

    元素来实现表示目标。

    结论

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

    "定义其他内容,因为它不仅仅是一个简单的语义标记——它还告诉浏览器如何呈现其内容。
  • 确切地。你可以用自行车课代替。这就是重点。你应该使用合适的。您不会将car类用于mybike,只是因为它的render()方法很好地格式化了内容。你可以让Bike类呈现你想要的效果。
  • 我认为重点是松耦合在系统中是可取的。使用表格而不是divs+css来定义布局相当于一个紧密耦合的系统。关于松耦合的更多信息,请访问:en.wikipedia.org/wiki/loose_-coupling
  • 类比不错,结论也不错。为什么任何人都必须被老板和/或用户强迫去做正确的事情?难道没有人再为自己的工作感到骄傲了吗?
  • 我认为这是一个相当傲慢的帖子,它没有解释任何事情,只是重复同样的要求,而没有回答问题。我不明白为什么会有这么多的赞成票?????
  • 我同意索尔库姆的观点。这个回答相当主观,实际上并没有回答提出的问题。虽然我同意将div用于页面布局,但我无法想象任何Web设计器都会被基于表的布局混淆。
  • 如果没有Firebug,我无法理解嵌套的表布局,"我无法想象任何Web设计器会被基于表的布局混淆"。
  • 到目前为止,我已经经历了很多次嵌套表布局的痛苦,理查德E的评论让我的大脑受到了伤害。
  • @塔尔昆和理查德:为什么"语义错误"是主观的,不能解释任何东西?
  • 我也很惊讶,这个答案被评为如此高,因为它甚至没有回答这个问题。
  • 恐怕这是我希望避免的那种错误的推理。"你——还有你的职业声望。现在去做正确的事。"这是在问问题。(假设一个专业的态度是使用CSS,而这是需要证明的事情。)
  • 我认为当我的结论完全没有理由的时候,把它当作错误的推理来攻击是不公平的——它是一个结论。我的理由是在前面的段落中:"您滥用了table元素来实现一个表示性的目标"——将table元素用于它从未打算用于的用途。
  • @卡尔·卡莫:这句话并不能说明使用表元素表达目标的负面后果。为了说明它"对程序员的反映很差",并质疑"专业"的态度,这是这个答案中的"乞讨"部分。
  • @B不,是的,你必须接受我的前提,即工具使用不当会对工匠造成不良影响,从而接受我的结论,即正确的工具使用会对工匠产生积极影响。如果没有,那么使用ul作为缩进或blockquote作为侧边空白也不会困扰您。
  • @卡尔相机的最后一条评论:在使用CSS重置后,不能将ul用于缩进,也不能将blockquote用于侧边空白…呵呵。
  • 我完全同意这个类比,编写HTML5规范的人也必须同意。想想看,他们给了我们一些元素,比如章节、文章、旁白、组合、页眉、页脚、导航、数字、图片标题,所以我们不必使用DIV来表示所有内容。
  • 我理解一些与你的帖子类似的东西:如果是数据,你可以使用表格,但是如果是其他东西,你应该使用CSS

  • 显而易见的答案:参见CSS禅园。如果您告诉我您可以轻松地对基于表的布局进行同样的操作(记住,HTML不会改变),那么一定要使用表进行布局。

    另外两个重要的事情是可访问性和SEO。

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

    所以您的答案是可维护性、可访问性和SEO。

    不要懒惰。即使学习起来有点困难,也要以正确的方式做事。

    元素的样式。我可以很容易地用一个基于桌子的布局做同样的事情,就像在CSS禅宗花园。下面是一个例子:x.iaessr.com/~/experials/table_test


    看到这个重复的问题。

    有一件事你忘了,那就是无障碍性。例如,如果需要使用屏幕阅读器,则基于表的布局也不会进行翻译。如果你为政府工作,可能需要支持可访问的浏览器,比如屏幕阅读器。

    我还认为你低估了你在问题中提到的一些事情的影响。例如,如果您既是设计师又是程序员,您可能无法完全理解它如何将演示文稿与内容区分开来。但是,一旦你进入一个商店,他们是两个截然不同的角色,优势开始变得更加明显。

    如果您知道自己在做什么,并且拥有良好的工具,那么在布局方面,CSS确实比表具有显著的优势。虽然每个项目本身可能不能证明放弃桌子是正当的,但把它们放在一起通常是值得的。


    不幸的是,css zen garden不能再被用作好的html/css设计的示例。实际上,他们最近的所有设计都使用图形作为章节标题。这些图形文件在CSS中指定。

    因此,一个网站的目的是显示出将设计从内容中排除的优势,现在它经常犯下将内容放入设计中的无法言喻的罪行。(如果要更改HTML文件中的节标题,则显示的节标题将不会更改)。

    这只能说明,即使那些崇尚严格的Div&css宗教的人,也不能遵守自己的规则。你可以用它来指导你如何严格遵循它们。


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


    一张布局表也不会那么差。但大多数情况下,只使用一个表就无法获得所需的布局。很快您就有了2到3个嵌套表。这会变得很麻烦。

    • 它很难阅读。这不符合意见。有更多的嵌套标签,上面没有识别标记。

    • 将内容与演示分开是一件好事,因为这样可以让你专注于你正在做的事情。混合这两种方法会导致页面膨胀,难以阅读。

    • 样式的CSS允许浏览器缓存文件,随后的请求速度更快。这是巨大的。

    • 桌子把你锁在一个设计中。当然,不是每个人都需要CSS禅宗花园的灵活性,但我从来没有在一个网站上工作过,我不需要在这里或那里稍微改变设计。使用CSS更容易。

    • 桌子很难设计样式。您对它们没有太大的灵活性(即,您仍然需要添加HTML属性来完全控制表的样式)

    我大概有4年没有使用非表格数据的表格了。我没有回头看。

    我真的想建议你读安迪·巴德的《精通CSS》。太棒了。

    图片位于ecx.images-amazon.com http://ecx.images amazon.com/images/i/41th5nfkpel._sl500_bo2204203200_pisti-dp-500-arrow,右上角,45,-64_ou01_aa240_sh20_.jpg


    It's good to separate content from layout
    But this is a fallacious argument; Cliche Thinking

    这是一个错误的参数,因为HTML表是布局的!内容是表中的数据,表示是表本身。这就是为什么有时将CSS和HTML分离非常困难的原因。你不是把内容和演示分开,而是把演示分开!一堆嵌套的div和一个表没什么不同——只是一组不同的标记。

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

    我认为表与div可以归结为应用程序的需求。

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

    然而,我们的产品拥有非常封闭的受众(我们销售带有Web界面的硬件),并且可访问性问题对我们来说不是一个问题。我不知道为什么屏幕阅读器不能很好地处理表格,但我想如果是这样的话,那么开发人员必须处理它。

    或默认的表示,它们并不等同于表示元素而不是语义元素。
  • 我不是专门讨论HTML,而是在基本的UI设计中概念性地讨论HTML。表格规定了屏幕上的布局,即它们如何呈现给用户。这就是演示文稿。
  • @Erlando:是的,但是大多数使用div的设计都会在左侧浮动列,因此在HTML中稍后会有导航。我还没有看到一个设计,在这个设计中导航是HTML中的第一件事。
  • "我花了好几天的时间试图让它工作"——如果我想弄明白的事情需要几个小时以上,我就把它放到StackOverflow社区。不知道如何正确地做某件事是不正确地做这件事的借口。尤其是当我们掌握了所有的答案。
  • +1对于"一堆嵌套的div和一个表没有什么不同——它只是一组不同的标记。"我必须补充说,大多数时候,我需要相同数量的标记才能获得相同的结果。
  • 表只能用于数据,不能用于布局。是的,如果你的老板不太清楚,或者你不关心SEO,或者你不关心你是否写了垃圾代码,你可以将它们用于布局。@夜狼,这是我听过的最荒谬的事情,三倍的标签需要做同样的事情作为一个DIV标签。
  • @B第44部分:是的,你是对的。在某些情况下,一个"div tag"就可以完成这个技巧,"table tags"仍然需要它的庞大数量。但是作为一个例子,如果您使用DIV布局创建一个登录屏幕,那么您不能使用比"表标记"更少的标记来创建相同的布局。如果你仍然不同意我,我想让你告诉我如何改进我的登录屏幕代码。别误会我,我相信你应该使用不显示数据的div,即使它比表更多标记。
  • @夜狼,是的,这是旧的,但我想看到你的登录屏幕代码,并用更有效的标签重写它。请分享!D
  • @metalfrog:您可以在这里找到我的登录屏幕代码:chat.stackoverflow.com/rooms/6887/layout-in-html。
  • @夜狼,亲爱的!应该是好玩的!

  • CSS/DIV——这只是设计人员的工作,不是吗?我花了数百个小时调试DIV/CSS问题,搜索互联网,让标记的某些部分与一个模糊的浏览器一起工作——这让我很生气。你只做了一点小小的改变,整个布局就大错特错了——EATH的逻辑在哪里。花几个小时移动3个像素,然后再移动其他2个像素的像素,以使它们全部对齐。这在我看来显然是错误的。仅仅因为你是一个纯粹主义者,有些事情"做得不对",并不意味着你应该在任何情况下,特别是当它让你的生活轻松1000倍时,把它发挥到第n个程度。

    所以我最终决定,纯粹是出于商业目的,尽管我尽量少用,如果我期望20小时的工作来正确地放置一个分区,我会坚持在一张桌子上。这是错误的,它让纯粹主义者不安,但在大多数情况下,它花费的时间更少,管理起来也更便宜。然后我可以集中精力让应用程序按照客户的要求工作,而不是取悦纯粹主义者。毕竟,他们确实支付了账单,而我对一个强制使用CSS/DIV的经理的意见是——我只会指出客户也支付了他的薪水!

    所有这些CSS/DIV参数出现的唯一原因是,首先是由于CSS的缺点,以及浏览器之间不兼容,如果是这样的话,世界上一半的网页设计师都会失业。

    当你设计一个Windows窗体时,你不会在布局完之后尝试移动控件,所以我觉得你为什么要用一个Web窗体来这样做对我来说有点奇怪。我就是不明白这个逻辑。从正确的布局开始,有什么问题。我认为这是因为设计师喜欢与创造性调情,而应用程序开发人员更关心的是让应用程序实际工作,创建业务对象,实现业务规则,计算出客户数据之间的相互关系,确保事物满足客户的需求,你知道,就像真实世界的东西。

    别误会,这两个参数都是有效的,但是请不要批评开发人员选择一种更简单、更合理的设计表单的方法。我们通常比在DIV上使用表的正确语义更需要担心的事情。

    基于这个讨论,我将一些现有的TDS和TRS转换为DIV。45分钟的纠结,试图让每件事都排在一起,我放弃了。10秒钟后,所有浏览器上的TDS都会立即恢复工作,无需做其他任何事情。请试着让我明白-你有什么可能的理由让我以其他方式去做!


    布局应该简单。关于如何在CSS中实现带有页眉和页脚的动态三列布局,有很多文章都是这样写的,这说明它是一个糟糕的布局系统。当然,你可以让它工作,但网上有成百上千篇关于如何工作的文章。对于具有表的类似布局,几乎没有类似的文章,因为这显然是显而易见的。无论您对表说什么,还是支持CSS,这一事实都会使其失效:CSS中的基本三列布局通常被称为"圣杯"。

    如果这不能让你说"wtf",那么你现在真的需要放下"kool aid"。

    我喜欢CSS。它提供了惊人的样式选择和一些很酷的定位工具,但作为一个布局引擎,它是不足的。需要有某种类型的动态网格定位系统。一种简单的方法,可以在不知道盒子大小的情况下,在多个轴上对齐盒子。如果你称它为

    或其他什么的话,我一点也不在乎,但这是一个基本的布局特性,它在CSS中是缺失的。

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

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


    根据508合规性(对于视觉刺穿的屏幕阅读器),表格只能用于保存数据,而不能用于布局,因为它会导致屏幕阅读器发疯。有人告诉过我。

    如果为每个div指定名称,也可以使用css将它们全部剥皮。他们只是让你坐在你需要的地方有点痛苦而已。


    以下是最近项目的HTML部分:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    <?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>
        {DYNAMIC(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>
       
            <!-- Page title -->
           
                <!-- Navigation items -->
           
           
       
       
            <!-- Sidebar content -->
       
        <!-- Page content -->
        <p id="footer"><!-- Footer content -->
    </p>
    </body>
    </html>

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

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    <?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>
        {DYNAMIC(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对应布局的两倍大。在我们的高速宽带上,这不是一个大问题,但在那些拨号调制解调器上。


    我想补充一点,基于DIV的布局更易于维护、发展和重构。只需在CSS中进行一些更改,就可以对元素重新排序。根据我的经验,重新设计一个使用表的布局是一个噩梦(如果有嵌套表,则会更糟)。

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


    没有任何论据对我有利。

    我会说:如果鞋子合适,就穿上它。

    值得注意的是,如果不可能找到一个在两列或三列中呈现内容的好的DIV+CSS方法,那是很困难的,这在所有浏览器上都是一致的,而且看起来仍然像我想要的那样。

    这在我的大多数布局中都有一点倾向于表格的平衡,尽管我对使用它们感到内疚(不知道为什么,人们只是说这很糟糕,所以我试着去听),但最终,实用的观点是,我使用表格更容易、更快。我不按小时付钱,所以桌子对我来说比较便宜。


    如果内容按自然顺序排列,并且没有样式表就有意义,那么CSS布局对于可访问性通常要好得多。而不仅仅是屏幕阅读器与基于表的布局作斗争:它们还使移动浏览器更难正确地呈现页面。

    另外,对于基于DIV的布局,您可以很容易地使用打印样式表来完成一些很酷的事情,例如从打印页面中排除页眉、页脚和导航-我认为使用基于表的布局来完成这项工作是不可能的,或者至少更困难。

    如果您怀疑使用div比使用tables更容易将内容与布局分离,请查看css zen garden中基于div的HTML,了解如何更改样式表可以显著更改布局,并考虑如果HTML是基于table的,您是否可以实现相同的布局类型…如果是基于表的布局,则不太可能使用CSS来控制单元格中的所有间距和填充(如果是,则首先几乎可以肯定会发现使用浮动分隔符等更容易)。如果不使用CSS来控制所有这些,并且由于表在HTML中指定了从左到右和从上到下的顺序,表往往意味着您的布局在HTML中变得非常固定。

    实际上,我认为完全改变基于DIV和CSS的设计的布局而不改变DIV是非常困难的。但是,使用基于DIV和CSS的布局,更容易调整诸如不同块之间的间距及其相对大小之类的内容。


    这是一个备受争议的问题,这一事实证明W3C未能预测到将要尝试的布局设计的多样性。使用divs+css进行语义友好的布局是一个很好的概念,但是实现的细节是如此的缺陷以至于它们实际上限制了创造性的自由。

    我试图把我们公司的一个网站从一张桌子换成一张沙发床,这太让人头疼了,我完全放弃了投入其中的工作时间,回到了桌子上。为了控制垂直排列,我试图和我的跳水运动员扭打,这使我受到了严重的心理问题的诅咒,只要这场争论继续下去,我就永远不会动摇。

    人们必须经常想出复杂而难看的解决方法来实现简单的设计目标(如垂直对齐),这一事实强烈表明规则的灵活性不够。如果规格足够,那么为什么高调网站(像这样)认为有必要使用表格和其他解决方法来修改规则呢?


    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?

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


    由于必须与一个包含由某些应用程序生成的6层嵌套表的网站一起工作,并且让它生成了无效的HTML,因此实际上需要3个小时的时间来纠正它,只需稍作改动。

    这当然是边缘情况,但是基于表的设计是不可维护的。如果您使用CSS,您将样式分离出来,这样在修复HTML时就不必担心破坏。

    另外,用javascript试试这个。将单个表格单元格从一个位置移动到另一个表格中的另一个位置。在DIV/SPAN只进行复制粘贴的情况下,执行起来相当复杂。

    "我老板在乎吗?"

    如果我是你的老板。你会在乎的。如果你珍惜你的生命。


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


    布局灵活性想象一下你正在制作一个有大量缩略图的页面。DIVs:如果您将每个缩略图放在一个分区中,向左浮动,其中可能有10个适合一行。把窗户再窄一点,砰的一声——一排6个,或者2个,或者多少合适。表:您必须明确地说出一行中有多少个单元格。如果窗口太窄,用户必须水平滚动。

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


    • 508合规性-屏幕阅读器能够理解您的标记。
    • 等待呈现-直到到达

      元素的末尾,才会在浏览器中呈现表。


    看起来你只是习惯了桌子,就这样。将布局放在表中只会限制您使用该布局。使用CSS,您可以四处移动位,请访问http://csszengarden.com。/不,布局通常不需要很多嵌套的div。

    由于没有用于布局和正确语义的表,HTML更干净,因此更容易阅读。为什么不能理解CSS的人要尝试阅读它?如果有人认为自己是网页开发人员,那么很好地掌握CSS是必须的。

    SEO的好处来自于能够让最重要的内容更高的页面和具有更好的内容与标记比率。

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


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

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

    开发人员需要停止提供暗示布局的标记,这样我们中那些有能力展示内容的人就可以继续我们的工作,而开发人员不必在展示需要更改时回到他们的代码中进行更改。


    另外,别忘了,在移动浏览器上,表的表现不太好。当然,iPhone有一个超级浏览器,但每个人都没有iPhone。对于现代浏览器来说,表渲染可能是微不足道的,但对于移动浏览器来说,这是一堆西瓜。

    我个人发现,很多人使用过多的标签,但在一定程度上,它可以非常干净,易于阅读。你提到人们阅读CSS比阅读表格要困难;从"代码"的角度来说,这可能是正确的;但是从阅读内容(视图>源代码)的角度来看,用样式表理解结构比用表格更容易。


    这并不是说"对于布局来说,分隔符是否比表更好"。了解CSS的人可以非常直接地使用"布局表"复制任何设计。真正的胜利是使用HTML元素来实现它们的用途。不将表用于非表数据的原因与不将整数存储为字符串的原因相同——当您将技术用于设计它的目的时,它更容易工作。如果有必要使用表格进行布局(由于20世纪90年代早期浏览器的缺陷),那么现在肯定不是了。


    有必要计算出CSS和div,这样中心内容列就可以在页面布局的侧边栏之前加载和呈现。但是,如果你正努力使用浮动分隔线来垂直地将一个标志与一些赞助文本对齐,只需使用表格并继续生活。禅院的宗教只是没有给多少钱。

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

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

    如果您真的想有效地划分代码,请使用Subversion并查看更改日志。然后使用最简单的编码技术——div、tables、javascript、includes、函数、对象、continuations等等——来构造应用程序,使更改以一种简单而舒适的方式适应。


    由于创建布局所需的代码量大,使用表布局的工具可能会变得异常沉重。默认情况下,SAP的NetWeaver门户使用表来布局页面。

    我目前工作的生产SAP门户有一个主页,其HTML重量超过60K,有七个表深,三次在页面内。加上javascript,16个iframe被误用了,里面有类似的表问题,CSS太重了,页面的重量超过了5MB。

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


    我很惊讶地看到一些问题还没有被涵盖,所以这里是我的2分,除了前面提到的所有非常有效的点:

    1。CSS与SEO:

    a)CSS曾经对SEO有非常重要的影响,它允许将内容放在页面中任何你想要的位置。几年前,搜索引擎非常重视"页面上"因素。页面顶部的内容被认为比底部的内容更与页面相关。"页面顶部"对于蜘蛛"的意思是"在代码的开头"。使用CSS,您可以在代码的开头组织关键字丰富的内容,并将其放置在页面中您喜欢的任何位置。这仍然有点相关,但是页面上的因素对页面排名的重要性越来越小。

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

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

    2。生成内容:

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

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

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

    此外,当生成一个表时,内容(变量中)已经与布局(代码中)分隔开,因此很容易修改。

    这就是一些设计良好的网站(例如)仍然使用表布局的原因之一。

    当然,如果结果需要通过javascript进行操作,那么div就值得麻烦了。

    3。快速转换测试

    当确定什么对特定的受众有效时,能够以各种方式更改布局以确定获得最佳结果是很有用的。基于CSS的布局使事情变得相当容易

    4。针对不同问题的不同解决方案

    布局表通常是分散的,因为"每个人都知道divs&css"是解决问题的方法。

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

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

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

    就我而言,我厌倦了膝盖抽搐的反应"哦,不!布局表格!"

    至于"这不是为了这个目的,所以你不应该这样使用"的人群,那不是伪善吗?你对所有的CSS技巧有什么看法?你必须使用这些技巧才能让darn在大多数浏览器中正常工作?他们是为了这个目的吗?


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

    在表象标记和CSS支持同一种设计的情况下,CSS显然是更好的选择,没有人会在他们正确的头脑中争辩说,font标记比在css中指定排版更好,因为css提供的功能与font标记相同,但方式要干净得多。

    但是,表的问题基本上是,在Microsoft Internet Explorer中不支持CSS中的表布局模型。因此,表和CSS在功率上是不等价的。缺少的部分是表格的类似网格的行为,其中单元格的边缘垂直和水平对齐,而单元格仍然展开以包含其内容。在没有硬编码某些维度的纯CSS中,这种行为是不容易实现的,这使得设计变得僵硬和脆弱(只要我们必须支持Internet Explorer-在其他浏览器中,使用display:table-cell很容易实现)。

    因此,这实际上不是一个表或CSS是否更可取的问题,而是一个认识到使用表可能使布局更灵活的特定情况的问题。

    不使用表的最重要原因是可访问性。Web内容可访问性指南http://www.w3.org/tr/wcag10/advice againt using tables for layout。如果您关心可访问性(在某些情况下,您可能在法律上有义务这样做),那么即使表更简单,也应该使用CSS。请注意,您总是可以使用CSS创建与表相同的布局,这可能只需要做更多的工作。


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

    使用语义分隔符:

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

    附表:

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

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


    因为维护一个使用表的站点是很糟糕的,而且需要更长的时间来编写代码。如果你害怕漂浮的潜水艇,就去上一门课程。它们不难理解,而且它们的效率大约是它们的100倍,比屁股上的疼痛要低100万倍(除非你不理解它们——但是,嘿,欢迎来到计算机世界)。

    任何人考虑用一个更好的表来做他们的布局,都不希望我维护它。这是渲染网站最愚蠢的方法。感谢上帝,我们现在有更好的选择。我再也不会回去了。

    令人害怕的是,有些人可能不知道使用现代工具创建一个网站所带来的时间和精力效益。


    我不得不用这两种方式来做站点,加上第三种,可怕的"混合"布局,包括表格、div和样式:div/css轻松获胜。

    您必须将三个深的div嵌套,以便只匹配一个表单元格的代码权重,这一点就在最前面。这种效果可以用嵌套表来扩展。

    我还希望对我的站点中的每一页进行一次布局更改,而不是一次更改。

    我用divs/css完全控制了演示的各个方面。表格以可怕的方式把这搞得一团糟,特别是在IE浏览器中,我还没有选择不支持它。

    我对divs/css网站进行维护或重新设计的时间只是表格中的一小部分。

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

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


    严格区分演示文稿和内容的问题使我大致类似于将C++中的头文件与实现文件分开。这是有道理的,但也可能是一种痛苦。JAVA JAVA和C类,其中类定义在一个源文件中。新语言的作者注意到了一些引起程序员头痛的事情,于是他们就把它处理掉了。这似乎是这次讨论的要点。一方面是说CSS太难了,另一方面是说必须成为一个CSS大师。

    对于简单的布局问题,为什么不弯曲表示演示必须完全分离的规则呢?一个新的标签(或者DIV标签的一些扩展)可以让我们直接在HTML中控制表示吗?毕竟,我们不是已经将演示文稿泄漏到HTML中了吗?看h1,h2…h6。我们都知道这些控制演示。

    读取代码(HTML就是代码)的能力非常重要。古鲁斯倾向于忽略使编程环境尽可能地为大众所访问是多么重要。认为只有专业的程序员才重要是很短视的。


    One example: you want to center the
    main content area of a page, but in
    order to contain the floats inside it,
    it needs to be floated. There is no
    "float: center" in CSS.

    这不是在中心元素中"包含浮点"的唯一方法。所以,一点都不好的争论!

    在某种程度上,这是一个错误的前提,"divs tables"的事情。

    快速而肮脏地将一页分成三列?说实话,桌子更容易。但是没有专业人员将它们用于布局,因为它们将页面元素的位置锁定到页面中。

    真正的论点是"由CSS(希望在远程文件中)完成定位",而不是"由HTML在页面中完成定位"。当然每个人都能看到前者的好处而不是后者?

  • 大小——如果您的页面布局是在HTML中,在页面中,它不能被缓存,并且必须在每个页面上重复。如果您的布局是在缓存的CSS文件中,而不是在页面中,那么您将节省大量的带宽。
  • 多个开发人员可以同时处理同一个页面——我处理HTML,其他人处理CSS。不需要存储库,不存在过度写入、文件锁定等问题。
  • 进行更改更容易——不同浏览器中的布局会有问题,但您只需要修复一个文件,即CSS文件,就可以对其进行排序。
  • 如前所述,无障碍。表假设每个人都有一个二维的布局。这不是一些用户如何查看你的内容,也不是谷歌如何查看你的内容。
  • 考虑一下:

    1
    2
    [ picture ] [ picture ] [ picture ]
    [ caption ] [ caption ] [ caption ]

    它表示一个表中有6个单元格的两行。可以看到二维表格布局的人将看到每张图片下的标题。但是使用语音合成,或者PDA,对于搜索引擎蜘蛛来说,

    1
    picture picture picture caption caption caption

    关系,这是显而易见的表到位,消失。

    Div和CSS是否更适合于在HTML页面上简单地布局矩形以在尽可能短的时间内实现给定的设计?不,可能不是。但我不想为了得到一个给定的设计而快速地布局矩形。我在想一个更大的图景。


  • 尝试合并/拆分一个10/20的深度colspan/rowspan。不止一次,我不得不抑制自己的本能,开始和别人打架。[?!!
  • 尝试在不更改可见顺序的情况下更改源代码顺序。[搜索引擎优化,可用性…]
  • 我们看到的非常(非常简单)的页面是~150K。我敢打赌,使用适当的CSS,它几乎可以减半。[搜索引擎优化(是,搜索引擎优化,阅读最新谷歌规范等),性能,…]
  • 尝试创建一个可以在任何宽度上工作的迭代器模板。
  • 在这个基于表的SO媒介中讨论这个问题会导致奇点,并摧毁我们所有人。

  • 内容和布局之间的分离也使得为站点生成打印机友好的布局或只是不同的外观(样式)更容易,而无需创建不同的HTML文件。一些浏览器(比如火狐)甚至支持从视图菜单中选择样式表。

    我认为保持无表布局更容易。您不必担心行范围、列范围等,只需创建一些容器划分并将内容放在需要的地方。也就是说,我认为它更具可读性(

    ... ...

    sidebar

    )。

    这只是一个你必须学习的"小把戏"(一旦你掌握了这个把戏,我认为它会更容易,更有意义)。


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

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

    在找到最后一个"/table"之前,嵌套表(单元格内的表等)不会呈现到浏览器窗口。更糟的是-定义不好的表有时甚至无法呈现!或者当它这样做的时候,事情就不正常了。(未与"td"等进行适当的交叉)

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


    我曾经了解到一个表同时加载,换句话说,当连接速度慢时,在加载整个表之前,表所在的空间保持空白;另一方面,DIV加载的速度与数据的速度一样快,而不管它是否完全就绪。


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

    然后用一个语义正确的DIV布局站点来尝试它。

    你会看到区别的。

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


    要响应"tables are slower"参数,您需要考虑渲染时间,这是错误的度量。通常,开发人员会编写一个巨大的表来完成页面的整个布局——这会大大增加要下载的页面的大小。不管你喜欢与否,仍然有大量的拨号用户。

    另请参见:过度使用视图状态


    DIV和CSS定位允许更灵活的设计,从而更容易修改和模板化网页。

    这就是说,如果你对灵活性不感兴趣,那么使用一个表格而不是一些通过CSS变形成表格的div肯定是非常容易和快速的。我经常在设计时使用桌子,只是为了让它看起来更快一点。


    当我使用CSS设计布局时,我通常给每个主要部分分配自己的根(body-level)分区,并使用相对/绝对定位将其放置到适当的位置。这比表要灵活一些,因为我不局限于使用行和列表示的排列。

    此外,如果我决定重新排列布局(比如说我希望导航栏现在在),我可以简单地在一个位置(CSS文件)更改元素的位置,HTML不必更改。如果我在处理表的时候这样做,我就必须进去查找信息,并进行大量的属性修改、复制和粘贴,以获得相同的效果。

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

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

    因此,最终,灵活性和管理才是真正的赢家。通常,CSS允许您对布局做更多的工作。从技术上讲,基于表的布局没有不标准的地方,但是为什么要限制自己呢?


    由于仍然使用表格进行布局,我们缺少了DIV方面的创新。

    许多人都提出了解决方案,使为div创建布局更加容易。最流行的是网格体系结构。有基于此体系结构的动态布局生成器。退房:1)960.gs和(http://grids.heroku.com/)2)蓝图很多人都迟到了。

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

    我想说的是,除了所有的理论,实际上用CSS和div进行布局更快。相反,在这个方向上的创新使它比任何事情都容易。


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

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

    2-呈现表的算法很昂贵,而且不是一次性的。浏览器在获取内容时,将尝试渲染计算内容的宽度和高度。因此,如果您有嵌套表,比如浏览器收到了第一行,而第一个单元格的内容、宽度和高度都没有定义,它将计算宽度并呈现第一行,平均来说,当它得到第二行时,单元格2将有大量内容!它现在将计算第二行单元格的宽度。第一个怎么样?它将递归地计算宽度。这在客户方是不好的。(举一个例子)作为一个程序员,你会优化一些东西,比如获取数据的时间,优化的数据结构等等。你会优化一些要在服务器端完成的东西,比如说2秒钟,但是最终用户会在8秒钟内获得最终的视图。这里怎么了?1。可能是网络慢了!如果网络正常怎么办?什么是网络在接下来的1秒钟内传递内容?额外的5秒消耗在哪里?需要担心的是——浏览器可能在估计和呈现表时花费了大量的时间!

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

    但是,最后,DIV是很好的方式,因为CSS可以被浏览器缓存;而表则不被缓存!


    flex有一个标签,用于在垂直列中排列内容。老实说,我认为他们的整个布局/内容都不正确,但至少他们已经解决了这个问题。

    像许多对CSS感到沮丧的人一样,我也四处寻找一个简单的答案,当我以为自己找到了它时,我感到很高兴,然后当我用Chrome打开页面时,我的希望破灭了。我肯定不太擅长说这是不可能的,但我还没有看到有人为同行评审提供示例代码,明确证明它可以可靠地完成。

    那么,这个岛的CSS方面的人能推荐一种思路/方法来布局垂直列吗?我试过在第二行和第三行中进行绝对定位,但最终我发现到处都是重叠的内容,如果页面缩小,float也会出现类似的问题。

    如果有答案的话,我会欣喜若狂,做正确的事情,告诉我,"嘿,你试过**流:垂直水平",我完全脱发了。


    我仍然不太明白Divs/css如何使更改页面设计变得更容易,当您考虑测试的数量以确保更改在所有浏览器上都有效时,尤其是在所有黑客等情况下。这是一个非常令人沮丧和乏味的过程,浪费了大量的时间和金钱。值得庆幸的是,这508条法律只适用于美国(自由之地——是的权利),因此,作为我在英国的基地,我可以以我选择的任何方式开发网站。与美国的普遍看法相反,华盛顿制定的立法并不适用于世界其他地区——感谢上帝。从立法生效之日起,这一定是网页设计界的好日子。我认为随着我在IT行业25年的成长,我越来越愤世嫉俗,但我相信这种立法只是为了保护就业。事实上,任何人都可以用几张桌子把一个合理的网页拼凑起来。使用divs/css执行此操作需要更多的努力和知识。根据我的经验,要想找到解决简单问题的方法,要花上好几个小时的时间,还要在充满理想主义狂热者的论坛上阅读难以理解的文章,这些人都在争论如何"正确"地做事。你不能只是把你的脚趾浸入水中,让事情在任何情况下都能正常工作。在我看来,对使用div/css"开箱即用"缺乏明确的指导,这适用于所有情况,在浏览器上工作,使用"正常"语言而不使用极客语言书写,也有一点保护主义的味道。我是一个应用程序开发人员,我认为解决布局问题和测试所有浏览器所需的时间几乎是创建基本应用程序、设计和实现业务对象以及创建数据库后端所需时间的两倍。我的时间=金钱,对我和我的客户都一样,所以如果我不拒绝所有支持削减成本和为我的客户提供物有所值的pro-div/css参数,我很抱歉。也许这只是开发人员考虑工作的方式,但在我看来,更改复杂的表结构比修改divs/css要容易得多。值得庆幸的是,现在似乎有了解决这些问题的方法——称为WPF。


    谷歌对表格中的文本内容的优先级很低。我在给当地的慈善机构一些搜索引擎优化的建议。在检查他们的网站时,他们使用表格来布局网站。从我在谷歌搜索框中使用的每一个页面来看,无论是哪一个词,或是单词的组合,这些页面都不会出现在任何顶级搜索页面中。(但是,通过在搜索中指定站点,页面被返回。)一页是按正常标准编写的,以便在搜索中产生良好的结果,但在返回的搜索结果的前几页中,它仍然没有出现。(请注意,此文本位于表格中。)然后我在页面上发现了一段文本,它是在一个分区中,而不是在一个表中。我们在搜索引擎中放了那个分区的一些单词。结果?它出现在搜索结果的第二位。


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

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

    "您可能会听到一些可访问性倡导者说布局表是个坏主意,而应该使用CSS布局技术来代替。他们所说的是真实的,但老实说,使用表进行布局并不是在可访问性方面最糟糕的事情。各种残障人士都可以轻松访问表格,只要表格设计时考虑了可访问性。"


    我为我的英语感到抱歉,但还有一个原因:

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

    问题是,如果这个"翻译机器"是用表格做的,它就不能阅读网站。为什么?因为表是用于数据的。

    事实上,如果您使用表,对于每个单元格,您必须指定一些信息,以让残疾人知道他们在表中的位置。想象一下,你有一张大桌子,必须放大才能看到屏幕上只有一个单元格:你必须知道你在哪一行/哪一列。

    所以,使用了DIV,残疾人可以简单地阅读文本,当他们不必在那里的时候,也不会得到关于行/列的一些奇怪的信息。

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


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

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

    2:可读性:错误。如果所有的表示代码都是CSS,那么我可以阅读HTML,并且可以理解页面的内容。或者我可以阅读CSS并理解演示文稿。如果HTML中的所有内容都混在一起,那么在我看到什么是内容,什么不是内容之前,我必须从精神上删除所有与表示相关的部分。此外,我害怕遇到一个不懂CSS的Web开发人员,所以我真的不认为这是个问题。

    3:桌子比较慢,是的。原因很简单:在呈现表之前,必须完全解析表,包括其内容。即使在对其内容进行分析之前,也可以在遇到DIV时呈现它。这意味着在页面完成加载之前,将显示div。

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

    当然1是最大的。很多工具和应用程序都依赖于网页的语义。通常的例子是视障用户的屏幕阅读器。如果你是一个网站开发人员,你会发现许多大公司可能会雇佣你在一个网站上工作,即使在这种情况下,也要求该网站是可访问的。这意味着您必须考虑HTML的语义含义。通过语义Web,或者更相关的微格式、RSS阅读器和其他工具,您的页面内容不再只通过浏览器查看。


    在过去,屏幕阅读器和其他可访问性软件很难高效地处理表。在某种程度上,这在屏幕阅读器中由阅读器根据在表中看到的内容在"表"模式和"布局"模式之间切换来处理。这通常是错误的,因此用户在浏览表时必须手动切换模式。在任何情况下,通常高度嵌套的大型表在很大程度上仍然很难使用屏幕阅读器浏览。

    当使用div或其他块级元素重新创建表并高度嵌套时也是如此。divs的用途是用作一个foomatching和lay out元素,因此用于保存类似的信息,并将其显示在屏幕上供视觉用户使用。当屏幕阅读器遇到一个页面时,它常常忽略任何布局信息,既基于CSS,也基于HTML属性(并非所有屏幕阅读器都是如此,但对于最流行的阅读器,如jaws、windows eyes和orca for linux,它是如此)。

    为此,表格式数据,也就是说,在两个或多个维度中排序具有逻辑意义的数据(带有某种标题),最好放在表中,并使用div来管理页面上内容的布局。(考虑什么是"表格数据"的另一种方法是尝试用图表形式绘制……如果不能,则很可能无法在表中最好地表示出来)

    最后,使用基于表的布局,为了实现对页面上元素位置的细粒度控制,通常使用高度嵌套的表。这有两个影响:1.)增加了每一页的代码大小-由于导航和公共结构通常是用表完成的,所以对于每个请求,在网络上发送相同的代码,而基于DIV/CSS的布局将CSS文件拉过一次,然后使用较少的单词DIV。2.)高度嵌套的表需要更长的时间来呈现客户机的浏览器,从而导致加载时间稍慢。

    在这两种情况下,"最后一英里"带宽的增加,以及更快的个人电脑都减轻了这些因素,但同样,它们仍然是许多网站存在的问题。

    正如其他人所说,考虑到所有这些,表更容易处理,因为它们更面向网格,思想更少。如果所讨论的站点预计不会很长,或者不会被维护,那么做最简单的事情可能是有意义的,因为这可能是最具成本效益的。但是,如果预期的用户群可能包括大量的残疾人,或者如果网站将由其他人维护很长一段时间,那么将时间花在前面以一种简洁、易懂的方式做事情,最终可能会获得更多的回报。


    我相信这是一个与一般问题有关的问题。当HTML诞生时,没有人能够预见它的广泛使用。另一项在自身成功的重压下几乎崩溃的技术。当HTML页面用vi语言写在绿色文本终端上时,只需要一个表就可以向页面的访问者呈现数据,而大多数情况下,表形式的数据都是有意义的。

    我们都知道事物是如何进化的。相对而言,表最近已经过时了,但是有很多理由选择基于div和css的布局(可访问性不是最后一个)。当然,我不能写一个CSS来拯救我的生命,我认为一个图形设计专家应该随时待命。

    说…即使在现代的网站上,也有许多数据应该以表格的形式呈现。


    我认为没有人关心一个网站是如何设计/实现的,当它表现出色并且运行迅速时。

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

    让我给你几个理由,为什么我选择女主角:

  • 对于一个表,你必须写至少3个标签(table,tr,td,thead,tbody),为了一个好的设计,有时你有很多嵌套的表。

  • 我喜欢页面上有组件。我不知道如何准确地解释,但会尽力的。假设您需要一个徽标,而这个徽标必须放置在下一页内容的上方,只是其中的一小部分。使用表格,您必须剪切2个图像并将其放入2个不同的TDS中。使用div,你可以有一个简单的CSS来按你想要的方式排列它。你最喜欢哪种解决方案?

  • 当3个以上的嵌套表用于执行某些操作时,我正在考虑使用div重新设计它。

  • 但我仍在使用表格:

  • 表格数据

  • 自我扩展的内容

  • 快速解决方案(原型),因为每个浏览器上的divs box模型不同,因为许多生成器正在使用表等


  • 从过去的经验来看,我必须使用DIV。即使在OOP中,主要目的是减少对象之间的耦合,所以这个概念可以应用到DIV和表中。表用于保存数据,而不是将其安排在页面周围。DIV是专门为在页面周围安排项目而设计的,因此设计应该使用DIV,表应该用于存储数据。

    另外,用表格编辑网站也很难(在我看来)


    我尽量避免使用表格,但是当我们设计复杂的表格,将多种控制类型和不同的标题位置与严格的分组控制相结合时,使用div是不可靠的,或者几乎不可能。

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

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


    表对于您为了简单或临时的事情而聚集在一起的HTML是很好的。如果你正在建立一个大型网站,你应该使用div和css,因为随着时间的推移,随着网站的变化,维护起来会更容易。


    当需要确保元素需要保持在布局中的特定物理关系中时,可以使用表。对于数据,表通常是要使用的最佳布局元素,因为您不希望列以uxexpected的方式换行并混淆关联。

    也有人认为,必须保持在特定关系中的非数据元素也应呈现在表中。

    灵活的CSS布局非常适合于适合移动设备、大屏幕、打印和其他显示类型的内容,但有时内容只需以非常特定的方式显示,如果这要求屏幕阅读器无法轻松访问内容,则很可能是合理的。


    超短的答案:设计可维护的网站很难用表格,用标准的方法很简单。

    网站不是一张表,而是一组相互作用的组件。把它描述成一张桌子是没有意义的。


    用作纯布局的表确实对可访问性造成了一些问题(我听说过)。但我理解这里的问题是,不知何故,使用表格来确保页面上的内容正确对齐,从而破坏了Web。

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

    使用一个表来确保几个元素正确排列会导致代码的大量增加,这一论点往往包括单个DIV如何满足其所有需求的示例。它们并不总是包含10行CSS和为IE5、IE5.5、IE6、IE7编写的特殊浏览器黑客…

    我想在你的设计中使用平衡。桌子在工具箱里,记住它们是用来做什么的…


    使用DIV,您可以轻松地切换内容。例如,您可以这样做:

    1
    2
    3
    4
    5
    6
    7
    Menu | Content

    Content | Menu

    Menu
    ----
    Content

    在CSS中很容易更改它,而不是在HTML中。您还可以提供多种样式(右手、左手、小屏幕专用)。

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

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


    毫无疑问,这次行动有点接近尾声,争论似乎那么激烈,很容易反驳。

    网页是Web开发人员的领域,如果他们说DIV&CSS比表更好,那对我来说就足够了。

    如果一个布局是由服务器应用程序生成的表实现的,那么一个新的布局就意味着对应用程序的更改,应用程序的重新构建和重新定义,就像对CSS文件的更改一样。

    此外,可访问性。用于布局的表使网站不可访问,因此不要使用它们。更不用说违法了,这是一个很简单的问题。


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

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

    内容与设计分离=更新设计,可能还有一些内容。

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


    所见即所得!!!!我不能让我们的设计师在CMS项目中的客户机应该使用的模板中停止使用嵌套的div和elementid css样式。这就是WYSIWYG在线编辑的全部观点。您同时控制内容和布局!在这个场景中,首先根本没有分离。在一些外部样式表中定位和样式化的分区对WYSIWYG编辑的整体理念来说是一种诅咒。可以看到表,插入行,合并单元格等等。祝你在使用Div时好运,不要让用户失望。


    数据:使用表格。布局:使用样式。使用非常精简的浏览器(即链接2或不带样式的lynx,只需简单的标记),表可以呈现得最快。


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

    使用一张表格作为整体布局并在其中划分。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    <table>
        <tr><td colspan="3">Top content</td></tr>
        <tr>
            <td>Left navigation</td>
            <td>Main content</td>
            <td>Right navigation</td>
        </tr>
        <tr><td colspan="3">Bottom content</td></tr>
    </table>

    look-没有嵌套表。

    我读过很多关于如何通过DIV实现这一目标的文章,但从未发现任何东西每次都能毫无问题地工作。

    一旦你有了整体结构,div就很好了,但是坦白地说,fluid header/footer和三个fluid columns是div的一大难题。沙发床不是为流动性设计的,所以为什么要使用它们?

    请注意,此方法将在链接文本处为您提供100%的CSS遵从性


    我发现,即使有最好的计划,也有几个方面的不足。例如。即使其他内容不在浏览器的底部,Div也无法拥有始终位于浏览器底部的底部栏。此外,您不能优雅地做任何比三列更好的事情,并且您不能让列根据其内容的宽度进行增长和收缩。最后,我们试着先用跳水。但是,我们不会根据一些宗教内容和布局理想来限制HTML设计。