Web 开发标准 | 青训营

143 阅读6分钟

Web标准组织

web标准的制定者是万维网联盟,又称W3C理事会。   万维网联盟是Web技术领域最具权威和影响力的国际中立性技术标准机构,创建于1994年10月,原为欧洲核子研究组织的一个项目,万维网联盟是国际最著名的标准化组织,主要工作是发展Web规范,它已发布200多项影响深远的Web技术标准及实施指南,如广为业界采用的超文本标记语言、可扩展标记语言等,对互联网技术的发展和应用起到了基础性和根本性的支撑作用。

W3C 流程

W3C 规范的批准步骤 在 W3C 发布某个新标准的过程中,规范是通过下面的严格程序由一个简单的理念逐步确立为推荐标准的:

W3C 收到一份提交 由 W3C 发布一份记录 由 W3C 创建一个工作组 由 W3C 发布一份工作草案 由 W3C 发布一份候选的推荐 由 W3C 发布一份被提议的推荐 由 W3C 发布推荐 在本教程下面的章节,总结了 HTML、CSS、XML、XSL 在 W3C 的相应活动,包括每项 Web 标准的状态和时间线。

W3C 提交 (W3C Submissions) 任何 W3C 的成员都可向联盟提交希望成为 Web 标准的某项建议(案)。大多数W3C推荐都发源于向联盟做出的某个提交。

如果某项提交在 W3C 的工作领域(或宪章)内,那么 W3C 将决定是否启动对该项提议的改进工作。

W3C 记录 (W3C Notes) 通常,一项对 W3C 的提交会成为一份记录。记录是对作为一份公共文档来提炼的一项提议的描述。

W3C 仅记录用户讨论。记录的发布并不代表对其的认可。记录的内容是由提交此记录的会员来编辑的,而不是 W3C。记录可在任何时间被更新、替换或废弃。记录的发布也不表明 W3C 已启动与此记录相关的任何工作。

W3C 工作组 (W3C Working Groups) 当某项提交被 W3C 承认,一个工作组就会成立,其中包括会员和其他有兴趣的团体。

工作组通常会定义一个时间表,并发布有关被提议标准的工作草案。

W3C 工作草案 (W3C Working Drafts) W3C 工作草案通常会被发布于 W3C 的网站上,连同对公共注解的邀请。

工作草案会说明进行中的工作,但不应被用作任何参考材料。其内容可在任何时间被更新、替换或废弃。

W3C 候选推荐 (W3C Candidate Recommendations) 某些规范会比其他规范更复杂,并可能需要来自会员和软件开发商的更多的经费、更多时间以及更多测试。有时,这些规范会作为候选的推荐来发布。

候选的推荐也是一种"正在进行的工作",同样不应被用作参考材料。此文档可在任何时间被更新、替换或废弃。

W3C 提议推荐 (W3C Proposed Recommendations) 提议的推荐意味着工作组中工作的最后阶段。

提议推荐也是一种"正在进行的工作"。此文档可在任何时间被更新、替换或废弃。不过即使它不意味着 W3C 的任何官方的认可,在极多的情况下,提议的推荐无论在内容还是时间上都已接近于最后的推荐。

W3C 推荐 (W3C Recommendations) W3C 推荐已经通过了 W3C 会员们的评审,并得到了 W3C 主任的正式批准。

W3C 推荐是一份稳定的文档,并可被用作参考材料。

在本教程下面的章节,总结了 HTML、CSS、XML、XSL 在 W3C 的相应活动,包括每项 Web 标准的状态和时间线。

TC 39 流程

ECMAScript特性的每个提案都要经历以下几个成熟阶段,从阶段0开始。从一个阶段到下一个阶段的进展必须得到TC39的批准。 阶段0:strawman 为 ECMAScript 的发展提供一种自由的提交想法的方式。提交者必须是TC39成员或已注册为TC39贡献者的非成员。该文档必须在TC39会议上进行审核(来源),然后将其添加到带有阶段0提案的页面中。 阶段1:proposal 该特性的正式提案。必须确定负责该提案的所谓拥护者(champion)。 拥护者或联合拥护者必须是 TC39 的成员(来源)。 提案解决的问题必须以散文形式描述。解决方案必须通过示例,API 以及语义和算法的讨论来描述解决方案。 最后,必须确定提案的潜在障碍,例如与其他特征的相互作用和实施挑战。 在实现方面,需要 polyfill 和演示。通过接受阶段1的提案,TC39 宣布愿意审查,讨论并为该提案做出贡献。 展望未来,有望对该提案进行重大更改。 阶段2:draft 规范中内容的第一个版本。在这一点上,该特性可能最终包含在标准中。 现在,该提案还必须对该特性的语法和语义进行正式描述(使用 ECMAScript 规范的正式语言)描述应该尽可能完整,但是可以包含待办事项和占位符。 需要对该特性进行两个实验性的实现,但是其中一个可以在诸如Babel 的编译器中进行实现。从现在开始,只会进行预期增量更改。 阶段3:candidate 该提案大部分已经完成,现在需要实现和用户的反馈来进一步推进。 规范文本必须完整。 指定的审阅者(由 TC39 任命,而不由 拥护者任命)和 ECMAScript 规范编辑者必须在规范文本上签字。 必须至少有两个符合规范的实现(默认情况下不必启用)。 下一步是什么? 从今以后,仅应针对实现及其使用引起的关键问题进行更改。 阶段4:finished 该提案已准备好包含在标准中。 提案到达此阶段需要做以下事情:测试 262 验收测试(大致来说,是用 JavaScript 编写的语言功能单元测试)。通过测试的两个符合规范的运输实现。具有丰富的实践经验。 ECMAScript 规范编辑器必须在规范文本上签名。