【W3C要闻】W3C继续推动HTML媒体扩展（Media Extension）的标准化工作; 开发 HTML 5.1; W3C发布报告API（Reporting API 1）的首份公开工作草案 (201604-03)

亲爱的W3C中国区会员：
您好！

有关W3C近期新闻要点，现为您简要总结如下：


  * W3C继续推动HTML媒体扩展（Media Extension）的标准化工作

2016年4月5日，HTML媒体扩展工作组（HTML Media Extension Working Group）完 
成章程修订工作并得到批准，工作组将延至2016年9月。W3C前端交互技术领域负责 
人Philippe Le Hegaret 发表博客文章，确认W3C将继续推动HTML媒体扩展的标准 
化工作。文章要点如下：

随着视频在Web内容中的重要性不断上升，我们于2007年就在HTML5中启动视频相关 
的工作：
https://www.w3.org/blog/news/archives/661

在这一领域，W3C已经为开放Web平台提供了一系列扩展：Web应用可通过本地摄像 
头捕捉图片（capturing images）、处理视频流、面向残障人士的音轨及字幕增 
强、音频处理、实时通讯等。
Media Capture and Streams -> https://www.w3.org/TR/mediacapture-streams/

HTML媒体扩展工作组重点关注两类扩展：媒体源扩展（Media Source 
Extensions，MSE）能够更好的适应流媒体的需要；加密媒体扩展（Encrypted 
Media Extension，EME）关注对受保护内容的播放。所有这些扩展都是为了增强开 
放Web平台在处理各类富媒体时的能力。
Media Source Extensions (MSE)-> https://www.w3.org/TR/media-source/
Encrypted Media Extensions (EME)-> https://www.w3.org/TR/encrypted-media/

W3C支持技术架构组之前做出的声明:
https://www.w3.org/blog/TAG/2015/11/16/strong-web-platform-statement/

即通过更广泛的参与、测试、审计来确保用户的安全及Web的安全。W3C的会员电子 
前沿基金会（EFF）关注加密媒体扩展可能引发的问题，并提出 了一个方案希望得 
到W3C全体会员的支持，这一方案希望安全研究者的工作及提供参考实现的机构能 
够基于美国数字千年版权法案（DMCA，US Digital Millennium Copyright Act） 
及其他国家和地区的类似法案的基础开展。经过几个月的讨论，以及最近一次AC会 
议的审议，我们并没有就此事形成更加广泛的共识。方案内容如下：
https://www.eff.org/pages/objection-rechartering-w3c-eme-group

我们充分认识到Web安全问题的严重性，也认识到安全研究者所开展工作的重要 
性，但我们也认为继续开展EME相关标准的后续研究，努力达到EME 标准启动时的 
承诺是仍然可行的。更多内容请参阅 W3C及加密媒体扩展：
https://www.w3.org/2016/03/EME-factsheet.html

EME 的目标是希望以一种标准的方式替换掉一些无法支持互操作的私有内容保护 
API（详情见媒体管道任务组需求，Media Pipeline Task Force 
Requirements）。通过增强安全、隐私保护及无障碍访问能力，EME 将通过将底层 
内容解密模块放在沙箱中，提供更安全的接口来处理许可证、密钥交换。规范中提 
及的密钥系统并没有执行任何数字版权保护（DRM）的具体功能， 并完全采用了被 
广泛接受的标准机制（如JSON Web密钥格式、RFC7517，以及相关算法、 
RFC7518），其核心是为EME提供完全可互操作的密钥系统。
Media Pipeline Task Force Requirements -> 
https://www.w3.org/2016/03/EME-factsheet.html

我们感谢并欢迎 EFF及其他W3C会员积极探讨技术与政策的关系。技术和研究者将 
从EFF的建议中受益，并帮助更好的为安全研究者提供法律与政策的保护。W3C将持 
续关 注美国 DMCA 及欧盟版权指引（EU Copyright Directive）可能对我们的会 
员及技术团队带来的挑战。
EU Copyright Directive -> 
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:32001L0029:EN:HTML

W3C正在设置一个新的技术与策略兴趣组（Technology and Policy Interest 
Group）跟踪这些与法律及政策相关的挑战及讨论。
https://www.w3.org/2016/02/proposed-techpolig.htm

英文原文：https://www.w3.org/2016/02/proposed-techpolig.htm


  * 开发 HTML 5.1

2016年4月6日，W3C的 Leonie Watson 发布博客文章 Working on HTML 5.1，代表 
Web平台工作组的主席（Chaals, Leonie, Ade）和编辑（Alex, Arron, Steve, 
Travis）介绍了目前HTML 5.1标准化工作的目标、时间安排、如何参与及标准测 
试。概要如下：

HTML5已经于2014年底发布，此后W3C计划持续发布HTML 标准的新进展。目前，W3C 
的 Web平台工作组（Web Platform Working Group，WP WG）正在推动在未来 6 个 
月内完成 HTML 5.1 的发布工作，并争取在 2016年底发布 HTML 5.1 的稳定版本。

时间安排：我们计划于 2016年9月发布 HTML 5.1的正式W3C推荐标准。为了达到这 
个目标，需要在2016年6月中旬发布HTML 5.1的候选推荐标准（Candidate 
Recommendation），并同时发布 Call For Consensus。关于近期标准内容的更 
新，请参阅 changes：
http://w3c.github.io/html/changes.html#changes

未来，我们将建立 HTML 规范的持续发布机制，可以通过 Github pulse了解新的 
进展，并在 Twitter 上关注 @HTML_commits 及 @HTMLWG。
Github pulse -> https://github.com/w3c/html/pulse/monthly

参与标准制定：HTML 5.1的最新版本规范文本发布在 Github 上。如果您发现有什 
么特性不能在浏览器上实现，请 File an issue，或直接通过Pull Request 来修 
改并提交标准文本。我们将删除那些没有获得两个独立浏览器内核版本支持的特 
性。HTML是一个很庞大的标准，我们通过 Bikeshed preprocessor 帮助处理相关 
源文件，并实现标准的自动迭代。同时，W3C的标准需要坚持 Royalty Free 的专 
利政策。此外，我们欢迎更多创新想法， Web平台孵化社区组（Web Platform 
Incubator Community Group，WICG）将帮助提出、讨论各种创新想法。
File an issue -> https://github.com/w3c/html/issues/
Pull Request -> https://github.com/w3c/html/pull/new/master

测试：W3C的每个工作组都需要说服 Tim Berners Lee 所制定的标准是“足够清 
晰、完整，且满足市场需要，并能确保标准中的每个技术特性能够独立的、可互操 
作的实现”。在HTML 5.0的制定过程中，我们启动自动测试系统 Webapps test 
harness：
https://www.w3.org/wiki/Webapps/Harness

但为了达到标准的质量目标，我们希望接纳更多能够展示互操作性的测试用例，无 
论这些测试用例能否被自动测试系统自动执行。

我们希望定义一个新的 HTML 标准，无论标准作者还是技术特性的实现者都能够更 
容易且更有信心的使用。我们希望让 HTML 5.1 成为比 HTML 5.0 更好的标准。这 
需要您的参与从而每个用户角度改进 HTML，进而定义更好的Web。

英文原文：https://www.w3.org/blog/2016/04/working-on-html5-1/


  * W3C发布报告API（Reporting API 1）的首份公开工作草案

2016年4月7日，W3C的Web性能工作组（Web Performance Working Group）发布了 
报告API（Reporting API 1）的首份公开工作草案：
https://www.w3.org/TR/2016/WD-reporting-1-20160407/

该文档定义了一个通用的信息报告框架，允许Web应用的开发者将一组命名报告端 
点（named reporting endpoints，如接受错误报告信息的点）与错误或异常报告 
源匹配和连接起来。内容安全策略（Content Security Policy）及网络错误报告 
（Network Error Reporting）等上层机制需要在这一框架的支持下工作，通过这 
些报告端点以一种标准机制发布特定功能的报告。

英文原文：https://www.w3.org/blog/news/archives/5339

更多内容，欢迎访问W3C中国官方网站：
http://www.chinaw3c.org/


Xueyuan