您的位置: 首页 > 技术文档 > 网页制作 > 不成熟的标准化是我们唯一惧怕的
不要犯WEB字体编辑的10种错误 回到列表 IE7的web标准之道 Ⅱ
 不成熟的标准化是我们唯一惧怕的

作者: 时间: 2008-08-18 文档类型:翻译 来自:Taobao.com UI Team

原文地址:http://yuiblog.com/blog/2008/08/14/premature-standardization/

The web is made of open standards. This was a significant factor in the web’s displacement of proprietary application platforms. Openness is hugely attractive, so much so that the web dominates over competitors with better technologies. The difficult tradeoff that comes with a standards-based approach is that it is difficult to innovate. As a result, the basic technologies of the browser have been stalled for a decade. What innovation we’ve enjoyed, such as the Ajax revolution, has come by mining all of the latent, accidental potential of the existing standards. That potential has been used up.

互联网是由开放的标准组成的。这对互联网代替私有的应用平台是一个重要的因素。开放是非常有吸引力的,也正因为如此互联网凭借更好的技术控制着其他的竞争对手。然而当基于标准的方法来临时,无疑创新会变得越来越困难。结果是,浏览器最基本的技术停滞发展了一段很长的时间。一些让我们欣喜的创新,如AJAX革命等,是一种在现有标准上的再发掘的潜能。然而这种潜能已经几近枯竭。

If we are to go forward, we must repair the standards. This is something that must be done with great care. A revision to a standard is an act of violence, just like any surgical procedure. It should only be undertaken when the likely benefit far exceeds the cost and the pain and the risk. The web is particularly troublesome because it did not anticipate the management of software updates, which is why IE5, an ancient browser, still has more users than Safari and Opera combined. Changes to the standard can put developers in a very difficult position because the benefits to users of some browsers become the seeds of failure for the users of others. Developers must manage this gulf, and it is not easy. Developers are not well served by new standards that make their jobs even harder.

如果我们想继续往前走更远,我们必须修正标准。这是一项必须非常小心的事情。标准的修订是一种暴力行为,如同外科手术一样。只有在标准带来的好处远远高于它本身的耗费及缺点时,标准才能真正被使用。互联网并没有预先的软件升级管理,这使得它成为了一个非常复杂的环境,就比如IE5,一个非常非常古老的浏览器,其用户份额却比Safari和Opera加起来还要更多。正因为如此,标准的改变将使开发者陷入一个非常困难的环境,很多对于某些浏览器的优点却可能变成其他浏览器潜在的错误。开发者必须管理并减小这些差别,但这却是不容易的。同时,开发者未能更好的适应使用新标准也增加了他们工作的难度。

I think it is instructive to look at two approaches to managing innovation within a standards based system, one that I view as a success, and the other not so much. JavaScript was a promising but half-baked language that was irresponsibly rushed to market and then irresponsibly cast into a standard. That standard is called ECMAScript to avoid a trademark dispute. That standard was last revised in 1999.

我觉得,把基于标准的系统和并不十分标准的系统放在一起比较并产生革新是非常有益的。JavaScript是一个非常有希望的语言,但它的自身也非常不成熟,它被过快的不负责任地扔入了浏览器市场,又被不负责任地扔入了标准的圈子里。为了避免潜在的版权纠纷,这项标准被称为ECMAScript。它最后更新的时间是1999年。

It is clear that the language needs to be updated, but TC39 (the committee that is responsible for drafting a new standard) could not reach consensus on how to do it, so it split into two groups, each producing its own proposal. This was a good thing in that competition is healthy, and I believe that competition inspired improvements to both proposals. This was also a bad thing because no standards organization can adopt two proposal for the same standard. Without consensus, both proposals must fail.

非常显而易见的,这门语言需要更新升级了。但是TC39在如何更新的问题上,却不能达到一致。所以他们分成了两个小组,分别实现各自的目标。这样的健康的竞争是非常有帮助的,我也相信竞争会改善两组各自的目标。 但是,这也是个不好的事情,因为没有一个标准组织会接受一项标准拥有两个不同的提议。如果不能达成一致,这两个提议都将会失败。

On one side there was the proposal called ES4. It was unfortunate that it adopted that name because it strongly suggested that it was destined to be the Fourth Edition of ECMAScript, a fate that was not certain. The project was very open to new ideas and features, adopting a porkbarrel attitude that was almost Congressional in its expansiveness. Lots of good ideas were included without an adequate analysis of the language as a whole system. As a result, many overlapping features were adopted which would have significantly increased the complexity of the language.

其中一项提议被称为ES4。这个名称的使用很不幸运,因为它强烈的暗示了它一定会是ECMAScript的第四版,然而它并不一定会是。该项目对于新思想新特征非常的开放,并采纳了许多看法,尽管这些思想并没有基于这门语言系统进行充分的分析。结果,许多复杂的特征被采用,并最终提升了整个语言的复杂性。

ES4 was so large and so innovative that there were doubts about whether it could be successfully specified and implemented. More worrisome, there was no experience with the language itself. Would the interaction of features cause unintended problems as we saw in ES1 and ES3? The schedule for ES4 required that the standard be put in place and adopted by the browser makers before that question could be answered. This is a problem because once a bug is inserted into a standard, it can be extremely difficult to remove it. All of the features, considered individually, were attractive. But taken as a whole, the language was a mess.

ES4非常的庞大,也引入了许多新思想,这不禁令人们担心它会不会被成功的接受和使用。更令人不安的是,对于语言的本身,并没有任何使用经验。那些极富吸引力的新特性会不会如ES1和ES3一样产生许多潜在的问题?ES4的制定安排要求这项标准必须被浏览器开发者接受并植入浏览器后才能回答刚才的问题。这会是一个很大的问题,当一个小bug错误的加入了标准,到时候想要去除掉它就会非常的困难了。单独考虑ES4所有的新特性,都是非常有吸引力的。但是全部放到一起,语言非常的混乱。

On the other side was a proposal called ES3.1. Its name indicated a less ambitious proposal, being a smaller increment over the current Third Edition. This project was intended to repair as many of the problems with the language as possible while minimizing the pain of disruption. New syntax was considered only when it was already implemented and proven in at least three of the four major browsers. Feature selection tended to favor necessary improvements over desirable improvements.

另一项提议被称为ES3.1。它的名字暗示它相比于现在的ES3只有较少的变革。这个项目的目标是修复语言中存在的诸多错误。新的句法只有在至少三至四个主流浏览器植入并测试过之后才会被考虑加入。他们更多的选择必须的特性,而不是可拥有的特性。

ES3.1 was more minimal in approach. The set of feature interactions was much smaller and much easier to reason about. ES3.1 is likely to complete its specification and will be the candidate for the Fourth Edition.

ES3.1更容易接受。新特性的吸引力会较小,但是也更容易实现。ES3.1也可能完成它的文档,从而成为ES真正第四版的候选。

ES4 had a large head start (by as much as seven years by some estimates), but was unable to meet its deadlines. Ultimately, the project fell apart when some of the key members left.

ES4的制定起步很早(估计至少7年之前),然而我们看不到它到底什么时候能结束。最终,由于核心成员的离去,这项工程被搁浅。

Some of the features that were in ES4 were reasonable, so a new project, called Harmony, is starting which will look at adapting the best of ES4 on top of ES3.1. The success of this project will depend on the ability of TC39 to do a better job of managing the tradeoffs between innovation and stability, and adopting a discipline for managing complexity. Simplicity should be highly valued in a standard. Simplicity cannot be added. Instead, complexity must be removed.

现在,由ES4引入的一些合理的新特性,重新成为了一项新项目,被称为Harmony。这个项目的成功与否取决于TC39权衡创新与稳定二者的能力,以及对复杂度的管理上。在某种程度上,简约应受到足够的重视,而不应被矫饰。所以,一些冗余必须被剔除。

It turns out that standard bodies are not good places to innovate. That’s what laboratories and startups are for. Standards must be drafted by consensus. Standards must be free of controversy. If a feature is too murky to produce a consensus, then it should not be a candidate for standardization. It is for a good reason that “design by committee” is a pejorative. Standards bodies should not be in the business of design. They should stick to careful specification, which is important and difficult work.

现在看来标准的主体并不是一个创新的好地方。这也正是实验室存在的目的。标准必须经过一致的协商,也必须有充分的辩论。如果一个特性很难达成一致,那么它应 该从标准草案中去除。标准的主体不能在有商业目的的情况下设计。它们必须坚持谨慎的设计,这同时是一个相当困难的工作。

I see similar stories in HTML5. The early work of WHATWG in documenting the undocumented behavior of HTML was brilliant. It went off the rails when people started to just make new stuff up. There is way too much controversy in HTML5. I would like to see a complete reset with a stronger set of design rules. Things can be much worse than the way things currently are. Having smart people with good intentions is necessary but not sufficient for making good standards.

我也在HTML5里面看见了很类似的情况。WHATWG的早期对于文档化HTML中没有文档的特性的工作是非常棒的。然而当人们开始只关注创造新东西时,它们开始偏离轨道。在HTML5中存在太多的争议。事情可能会比现在存在的更糟糕。也许,让一些有目的的聪明人制定好的标准是必须却又不够的。

延伸阅读

http://almaer.com/blog/javascript-2-a-perl-6-disaster-that-matters-so-much-more-but-wait
http://ajaxian.com/archives/ecmascript-harmony-coming-together-after-oslo
http://ejohn.org/blog/ecmascript-harmony/

本文链接:http://www.blueidea.com/tech/web/2008/6110.asp 

出处:Taobao.com UI Team
责任编辑:bluehearts

◎进入论坛网页制作WEB标准化版块参加讨论,我还想发表评论

作者文章 更多作者文章
网站的视觉设计
Photoshop绘制真实的黑莓手机
各版本IIS下ASP.net请求处理过程
奥运"长卷式海报"
AI渐变网格巧绘美女精致五官
关键字搜索 常规搜索 推荐文档
热门搜索:CSS Fireworks 设计比赛 网页制作 web标准 用户体验 UE photoshop Dreamweaver Studio8 Flash 手绘 CG
站点最新 站点最新列表
周大福“敬•自然”设计大赛开启
国际体验设计大会7月将在京举行
中国国防科技信息中心标志征集
云计算如何让安全问题可控
云计算是多数企业唯一拥抱互联网的机会
阿里行云
云手机年终巨献,送礼标配299起
阿里巴巴CTO王坚的"云和互联网观"
1499元买真八核 云OS双蛋大促
首届COCO桌面手机主题设计大赛
栏目最新 栏目最新列表
浅谈JavaScript编程语言的编码规范
如何在illustrator中绘制台历
Ps简单绘制一个可爱的铅笔图标
数据同步算法研究
用ps作简单的作品展示页面
CSS定位机制之一:普通流
25个最佳最闪亮的Eclipse开发项目
Illustrator中制作针线缝制文字效果
Photoshop制作印刷凹凸字体
VS2010中创建自定义SQL Rule

蓝色理想版权申明:除部分特别声明不要转载,或者授权我站独家播发的文章外,大家可以自由转载我站点的原创文章,但原作者和来自我站的链接必须保留(非我站原创的,按照原来自一节,自行链接)。文章版权归我站和作者共有。

转载要求:转载之图片、文件,链接请不要盗链到本站,且不准打上各自站点的水印,亦不能抹去我站点水印。

特别注意:本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有,文章若有侵犯作者版权,请与我们联系,我们将立即删除修改。

您的评论
用户名:  口令:
说明:输入正确的用户名和密码才能参与评论。如果您不是本站会员,你可以注册 为本站会员。
注意:文章中的链接、内容等需要修改的错误,请用报告错误,以利文档及时修改。
不评分 1 2 3 4 5
注意:请不要在评论中含与内容无关的广告链接,违者封ID
请您注意:
·不良评论请用报告管理员,以利管理员及时删除。
·尊重网上道德,遵守中华人民共和国的各项有关法律法规
·承担一切因您的行为而直接或间接导致的民事或刑事法律责任
·本站评论管理人员有权保留或删除其管辖评论中的任意内容
·您在本站发表的作品,本站有权在网站内转载或引用
·参与本评论即表明您已经阅读并接受上述条款
推荐文档 | 打印文档 | 评论文档 | 报告错误  
专业书推荐 更多内容
网站可用性测试及优化指南
《写给大家看的色彩书1》
《跟我去香港》
众妙之门—网站UI 设计之道
《Flex 4.0 RIA开发宝典》
《赢在设计》
犀利开发—jQuery内核详解与实践
作品集 更多内容

杂⑦杂⑧ Gold NORMANA V2