【译】我们盲目地奔跑在语义化的道路上

作者:Divya Manian                       

时间:2011年11月11日      标签:HTML, HTML5, 语义化      评论:174条

正文:点击查看原文

 

最近更新(2011年11月12日):

     读了Jeremy Keith对本文的一个回复,他非常认可语义化的重要性,并在该回复中对本文所提到的问题进行了讨论。

 

允许我勾勒这么几个画面:

  1. 你目前正忙着创建一个网站。
  2. 你有一个想法,“噢,我现在必须添加一个元素。”
  3. 接着又有另外一个想法,“对于新添的这个<div>,我感到非常内疚。因为我听说,Div本身很糟糕。”
  4. 于是,你又想,“我应该用用其他元素,<aside>可能会更合适些。”
  5. 查阅了相关信息之后,你相当确信,在语义上<aside>也不准确。
  6. 最后,你决定用<article>,因为它至少不是<div>。
  7. 至此,你已经浪费了40分钟,却没有得到实实在在的好处。 

 

这真的很衰

这个话题并不是第一次讨论。早在2004年,Andy Budd写了一篇关于纯粹语义和现实语义的文章。

如果你对HTML5的最大疑惑是 <aside>和<blockquote>的区别 或 如何正确的标记地址,那你现在使用HTML5的方式并不是它的设计初衷。

但是,你对标签的选择和我们待会讲的内容不怎么相关。让我们看看为啥不相关。 

 

web不再只包含结构化的内容

在web发展的黄金阶段,网页被认为是信息存储的仓库,再没其他特殊需求了。而如今,web不但包含内容,而且使其更有意义的,是源于它能和用户之间进行交互。 

XML, RDFA, Dublin Core和其他结构化规范都有非常严格的使用案例,但是那些案例并没有考虑web上的大部分交互。不幸的是,没有一个网站依据这些规范的要求做到绝对的语义化。Mark Pilgrim在这方面写得比我好多了。

如果你有需要语义化的内容,比如图书馆数据库、需要目录的文档、或在线图书(即语义化能使它变得更有意义的任何东西),那么,你就果断去看 HTML5 outline algorithm 吧,然后仔细区分下哪些元素应该用<article>,哪些元素应该用<section>。目前,没有面向用户的工具(利用outline algorithm生成表格式内容)存在。浏览器厂商似乎也不准备去开发。 

 

它真的易理解吗?

如果易理解性是你选择语义化标签的原因,那么你需要明白,易理解性和语义化标记之间几乎没有任何关联,由于Web上HTML标签的大量滥用。(我很想链接到Mark Piligrim的一个帖子上,但它已经不存在了,所以我们只好去这将就看下。)

从规范所关注的点来看,标签<b>,<strong>,<i>,<em>和<span>相似。HTML5中的一些标签也如此。 

谈到HTML5的可理解性,几乎每一个新的HTML5元素现在都有一个辅助技术,那就是尽可能多的阐述其语义化信息,就像div元素那样。所以呢,如果你觉得用了HTML5元素会让你的网站好理解些,那你再重新考虑考虑吧。(标签<figure>和<figcaption>带来的附加信息有多少?答案是:没有。)  

语义化信息和元素本身之间的关联并不大,最近关于<time>元素的讨论(或者说是争吵?)就是一个很好的例子。

  

它真的易被检索到吗? 

如果你是考虑到SEO(搜索引擎优化)才决定用语义化标记的,那么你需要知道,大部分搜索引擎并不会单纯的因为网页的语义化而给这个页面一个高的可信值。在Google的SEO指南中,它提到的唯一一件事是它会用到相关的head信息和a链接(其他搜索引擎的工作方式也类似)。使用HTML5元素或<strong>标签或<span>标签就不会影响到搜索引擎读取网页内容的方式。 

有另外一种方式能为搜索引擎提供富数据,那就是通过微数据(micro-data)。

但这种方式也不会让你的网站在搜索引擎中的排名更靠前,它只是当在你的网站上发现了相关内容的时候,简单地向搜索结果中增加价值

 

它真的便于移植吗?

语义化Web另一个备受吹捧的优势就是数据的可移植性。很神奇地,所有设备都能理解在任何地方出现的语义化标记,并且能够很方便地在其内部对标记进行解析。Aryeh Gregor说让这个神话去做它的白日梦吧

...+ Manu Sprony说语义化Web组收到的反馈是,外带的数据信息很难与内容保持同步。我敢肯定在MediaWiki上的案例不是真的,可是...我所看到 你选择用RDFa或微数据(microdata)而不是用单独的RDF 的场景,要么是你没有足够的网页生成工具,要么是你希望元数据被特定的已知客户端使用,它们只支持嵌入式的元数据(比如搜索引擎支持schema.org或诸如此类)。如果页面正在被一段脚本处理,如果脚本的作者已经准备好使用可以将元数据提取成单独RDF流的服务器端工具的话,那么它通常会去发布嵌入式的流,就像发布一个独立的流那样简单。这样会大大缓解每个页面在展现时的膨胀。
 
那么,现在怎么办?
 
  • 用<div>元素并没有害处;你可以继续使用它,而不是用<section>和<article>。我觉得我们应该使用新的元素,去让我们的标记更可读,而不是说为了更语义化。如果是为了以后的文档阅读者,你想使用HTML5中的<section>和<article>去强调一些特定文本的话,你可以那么做。
  • 今天的一些工具也在利用着<nav>,<header>,<footer>这些元素。NVDA现在给这些元素赋予了隐含的语义,让这些元素更容易被理解和使用。
  • 在屏幕阅读器中,ARIA被很好的支持,但是当同时使用HTML5元素的时候要小心。
  • HTML5还有很多新特性。我们应该学习它,使用它,并给予反馈,让这些特性更健壮更稳定。诚然,其中大部分特性要求你能理解并编写JavaScript,以便为你的用户呈现更丰富的体验。如果这个对你来讲有些困难,那你现在就开始学习如何编程吧,尤其是学习如何编写JavaScript。 
 
 

评论区:

为了更全面地认识语义化,此处将最佳评论中的Top8也一并翻译。 点击查看更多评论
 
Jon    2011年11月11日 6:27 am         +92

"你已经浪费了40分钟,却没有得到实实在在的好处。"

-从另一方面来讲,经过这一折腾,你对元素<div>,<article>,<aside>间的区别更清晰了。这意味着,作为一名开发人员,那40分钟让你学有所获。而这,对于你和你的应用程序来说,都是有长远意义的。

当手头有很多开发任务的时候,你应该在“上线时间”和“基于业务需要的长期维护”之间做权衡,而不是想着去让开发者去追求那所谓的纯粹,也不要说他们不愿意提高技能,更不是基于某些武断的截止日期或者某个中级管理者的日程安排表。

 
Rob Tarr   2011年11月11日 7:33 am         +37

我没法同意文章作者的观点。如果你自己不用恰当标记的原因,是因为“其他人没那么做”,那我想说这就不是问题的所在。因为我们是专业的开发人员。单纯地“”破坏了web的语义化,这种态度有点儿事不关己的嫌疑。我们应该为了未来的应用去创建一个语义良好的web。

想想那些寻找有趣内容的博客聚集器,还有那些为了提高可用性而将内容整合成本地应用的浏览器。

当然,学习新元素的用法会花些我们的时间,但是不正是我们的工作吗?我们从事在这个不断变化着的领域,如果我们都决定就这么忽略这些进步,那么我们将依然使用着IE6。

也许,有些案例说[不在意语义化而]节省下来的时间也是值得的(对此表示不确定)。但我并不那么觉得。一般来说,我们应该摒弃web结构中那些不好的文本标记。

 
Michael Wong   2011年11月11日 8:28 am        +36

我记得,曾经和一位vp开发工程师有以下争论:

我:我们应该用css布局
VP:为什么?tables能办到,我也理解tables
我:css更易维护,也可以减少修复的时间
VP:但是IE.x不能全面地支持css
我:IE终究是会赶上来的。在此期间,我们应该先让它(css)能工作起来。
VP:我觉得我们还是保持目前的方式吧。如果IE支持了,那时我们再换css。

那份工作,我辞了。因为我不想还用上世纪的方法继续工作。你说辅助性的技术从新语义化中得不到啥意义,但并不意味着它们永远不会。当客户从语义化中受益的时候,谁还能保证你今天所做的工作在五六年后还会存在

进步意味着前进。站在商业的角度,更是不进则退。

 
Ryan Buttrey   2011年11月11日 11:44 am        +36

See, if you just put a div around that statement it would mean the same thing. oh wait.

你看,如果你在声明中只用一个div,那意味着同样的事情。哦,等等。

【译者注:此句英文没读懂。作者的意思是如果只用一个div,而其余的标签都换成其他的,这也会导致同样的问题,即之前是div泛滥,之后便会变成另一个新的"div"元素泛滥.....吗?木明白啊,呜呜呜。。。所以,特此奉上英文原文一句】

 
Terry Morgan   2011年11月11日 5:45 am        +35

我想说,更有意义的代码会有利于其他开发人员去接手和维护。我相信,我们见到过很多次一坨<div>的情况。那时,也会在脑中闪过这样一个疑惑:这些<div>都代表什么啊。

越语义化的元素,带给我们的是让代码变简洁的一个机会。比如,用<article>标签而不是用<div>,这不仅使你的HTML更合理,也会让你的css更精致。 

我觉得真正的问题是:一些新元素有歧义,就像Divya一针见血指出的那样。

 
Frederick Yocum    2011年11月11日 7:48 am          +28

“用这些新元素让你的标记更可读,而不是说为了更语义化。”

原文中的这句话有些不足之处。它只说让标记更可读,但是对“谁”而言更可读呢?是通过css选择器看内容的用户?还是通过屏幕阅读器听网页的盲人?是接手代码并试图指出WTF之前开发者意图的开发者?还是代码里通过其他应用程序去解析网页的一个算法?还是以上这些都是?

语义(semantic)这个词从词根上来看,就包含意义(signification)和标记(sign)这两层意思。WWW是第一个试图同时让人和机器都能理解的发布平台。我们目前没有创造出一个能充分利用有意义标记(HTML元素)的机器,但这并不妨碍我们去使用它们。

我觉得,web现在之所以被普遍的标准所控制,是因为一些有原则的设计师坚持强调一致的开发标准,并花时间仔细挑选出最核心的东西,然后呼吁浏览器开发商去注意。

 

Evert   2011年11月11日 6:26 am          +26

语义化终究是关于我们现在正在使用的东西。HTML5中增加了一些我们经常用到的元素和标记;也移除了一些无效或者被滥用的元素和属性。

未来的情形也会如此。任何语义化元素和语义化结构的成功都依赖于我们今天如何使用它们。辅助的技术不应该作为一个比较的基础,因为它并不是关键所在。它只会以它现在正在使用的方式去工作,而不是以它“本该”怎样的方式。

作为web设计师和web开发人员,我们应该去了解我们正在使用的工具。从这个意义上来讲,说选择正确的元素是在浪费时间,那简直就是没有去阅读去理解规范的一个很烂的理由。但这也不是说所有实践性的问题都能从那些规范中找到答案。任何元素的最终语义都是基于它在实际代码中被怎么用的,而不是它在纸上被如何定义的。

这并不是说我们作为设计师|开发者的责任就可以不用负了,也不意味着我们可以忽略规范而仅把它当成一个纲要。这个我可是必定不赞成的。

 

Michael Wong    2011年11月11日 10:31 am       +26

你没抓住问题所在。你现在对语义化标记的反对,就和之前人们反对用CSS去布局一样。换句话说,就是把客户端支持不支持它们考虑在内了(尤其是2001年的IE时期)。你争论的含义是,我们不应该被新技术打扰是因为客户端没有好好用它们。我并不同意这种观点。

如果像Doug Bowman这样的web设计者,曾经在Wired没有打开那封信,那么CSS布局就不会像现在这么广泛应用。不要仅仅因为你不了解一个新东西,就这么快地决定舍弃它。

 

posted @ 2014-01-05 21:59  跑跑佳  阅读(509)  评论(0编辑  收藏  举报