我从来没有(或者说实话很少)对此有很好的论据。通常的答案是:
也许是我或我的同伴开发人员,他们必须维护网页……表的维护性较差吗?我认为使用表格比使用div和CSS更容易。
顺便说一句…为什么使用div或span不能很好地将内容与布局和表格分开?仅使用div获得良好的布局通常需要大量嵌套的div。
我认为代码的可读性是相反的。大多数人了解HTML,很少人了解CSS。
SEO最好不要使用表, 为什么呢?有人可以证明它是吗?还是Google声明从SEO角度不鼓励使用表?
表比较慢。 必须插入一个额外的tbody元素。这是用于现代Web浏览器的花生。向我展示一些基准测试,在这些基准测试中使用表会大大降低页面速度。
没有桌子,布局检修会更容易,请参见cssZenGarden。大多数需要升级的网站也需要新内容(HTML)。新版本的网站仅需要新的CSS文件的情况不太可能发生。ZenGarden是一个不错的网站,但是有点理论化。更不用说它对CSS的滥用了。
我真的对使用divs + CSS而不是表的好参数感兴趣。
我将一遍遍地讨论您的论点,并尝试显示其中的错误。
将内容与布局分开是很好的,但这是一个谬误的论点。陈词滥调的思考。
这根本不是谬误,因为HTML是故意设计的。元素的滥用可能不是完全没有问题的(毕竟,其他语言也开发了新的习惯用语),但是可能的负面影响必须加以抵消。此外,即使<table>今天没有反对滥用该元素的争论,但由于浏览器供应商对元素进行特殊处理的方式可能还会出现明天。毕竟,他们知道“ <table>元素仅用于表格数据”,并且可能会使用此事实来改进渲染引擎,在此过程中巧妙地更改<table>s的行为,从而打破了以前被滥用的情况。
<table>
所以呢?我的老板在乎吗?我的用户在乎吗?
依靠。你的老板是长发吗?然后他可能不在乎。如果她有能力,那么她会在乎的,因为用户会。
实际上,表 _的_可维护性较差应该是显而易见的。使用表格进行布局意味着更改公司布局实际上意味着更改每个页面。这可能 _非常_昂贵。另一方面,明智地将语义上有意义的HTML与CSS结合使用_可能会将_此类更改限制在CSS和所使用的图片中。
深度嵌套<div>s和表布局一样都是反模式。优秀的网页设计师不需要很多。另一方面,即使这样的深层div也没有很多表格布局问题。实际上,它们甚至可以通过将内容按逻辑划分为一个语义结构。
<div>
我认为代码的可读性是相反的。大多数人了解html,很少了解css。更简单。
“大多数人”没关系。专业很重要。对于专业人士而言,表格布局比HTML + CSS产生更多的问题。这就像说我不应该使用GVim或Emacs,因为记事本对大多数人来说更简单。还是我不应该使用LaTeX,因为MS Word对大多数人来说更简单。
SEO最好不要使用表格
我不知道这是否正确,也不会将其用作参数,但这是合乎逻辑的。搜索引擎搜索 相关 数据。虽然表格数据当然可能是相关的,但很少是用户搜索的内容。用户搜索页面标题或类似突出位置中使用的术语。因此,将表格内容从过滤中排除,从而将处理时间(和成本!)大大减少是合乎逻辑的。
表比较慢。必须插入一个额外的tbody元素。这是用于现代Web浏览器的花生。
多余的元素与表变慢无关。另一方面,表的布局算法要困难得多,浏览器通常必须等待整个表加载后才能开始对内容进行布局。此外,无法缓存布局(可以轻松缓存CSS)。所有这些都在前面提到过。
向我展示一些基准测试,在这些基准测试中使用表会大大降低页面速度。
不幸的是,我没有任何基准数据。我自己会对它感兴趣,因为这种说法缺乏一定的科学严谨性是正确的。
大多数需要升级的网站也需要新的内容(html)。新版本的网站仅需要新的CSS文件的情况不太可能发生。
一点也不。我曾研究过几种情况,其中通过将内容和设计分离而简化了设计更改。通常仍然需要更改一些HTML代码,但是更改总是局限得多。此外,有时必须动态进行设计更改。考虑模板引擎,例如WordPress博客系统使用的模板引擎。表布局实际上会杀死该系统。我曾为商业软件处理过类似案例。能够更改设计而不更改HTML代码是业务需求之一。
另一件事。表格布局使网站的自动解析(屏幕抓取)变得更加困难。这听起来很琐碎,因为毕竟是谁做的?我自己感到惊讶。如果有问题的服务没有提供WebService替代品来访问其数据,则屏幕抓取将有很大帮助。我正在从事生物信息学研究,这是一个可悲的现实。现代Web技术和WebService尚未普及到大多数开发人员,并且通常,屏幕抓取是使获取数据过程自动化的唯一方法。难怪许多生物学家仍然手动执行此类任务。适用于数千个数据集。