2015年7月21日，W3C的Web应用安全工作组（Web Application Security Working Group）就内容安全策略（Content Security Policy Level 2）候选推荐标准向公众征集参考实现。该文档定义了一个策略语言，用来声明一组对Web资源的访问限制（restrictions），并定义了一种在服务器和客户端之间传递策略并确保策略强制执行的机制。
更多信息，请参阅英文原文，及W3C的安全标准计划（Security Activity）。
W3C发布预加载（Preload）的首份标准工作草案
2015年7月21日，W3C的Web性能工作组（Web Performance Working Group）发布了预加载（Preload）的首个公开工作草案（First public working draft）。该规范定义了HTML和link元素的预加载关系。HTML link 元素的预加载关系提供了一种声明性的获取原语（fetch primtive），可以实现对远程资源的预先加载，以及在资源执行过程中的分段加载（seperate fetching）。
更多信息，请参阅英文原文，及W3C的富Web客户端标准计划（Rich Web Client Activity）。
W3C发布编辑工具可访问性指南（ATAG）2.0的提案推荐标准
2015年7月21日，W3C的编辑工具可访问性指南工作组（Authoring Tool Accessibility Guidelines Working Group，ATAG WG）发布编辑工具可访问性指南（Authoring Tool Accessibility Guidelines，ATAG) 2.0提案推荐标准（Proposed Recommendation)。同时还发布了实现ATAG2.0（Implementing ATAG 2.0）的工作草案。
ATAG2.0为设计Web内容编辑工具提供了指南。ATAG2.0分为两部分，每部分都反映了编辑工具可访问性的关键方面：A部分涉及残障作者编辑工具用户接口的可访问性，残障作者可以更加容易地访问和使用这些工具；B部分涉及来自所有作者（不仅是残障作者）的编辑工具支持，这些工具允许、支持、促进了残障终端作者更易访问的Web内容的创建。
更多信息，请参阅英文原文，及W3C的Web信息无障碍计划（Web Accessibility Initiative，WAI)。
ISO/IEC正式批准MathML 3.0成为ISO/IEC国际标准
2015年6月23日，世界万维网联盟（W3C），信息技术领域国际标准化组织（ISO）与国际电工委员会（IEC)的信息联合技术委员会JTC 1（ISO/IEC JTC 1）宣布正式批准MathML 3.0版第二版( MathML Version 3.0 2nd Edition )为ISO/IEC的一项国际标准(ISO/IEC 40314:2015)。
数学标记语言MathML是一种软件与开发工具中的标记语言，是用于Web中统计、工程、科学、计算及学术的数学表达式中的标记语言。MathML提供了 在XML中描述可视化公式（带有数学符号、组合公式和字体样式的可视化公式）及其语义（参考不同数学领域的语义）的方法。MathML的第一个版本 MathML 1于1999年发布。
作为一项ISO/IEC JTC 1国际标准，MathML 3.0 现今可从ISO/IEC国际标准中获得。获得JTC 1的认可既未改变也未取代W3C的现有标准，MathML3.0标准仍然可以通过W3C的网站免费获取。MathML是继W3C 2011年的网络服务(Web Services)与2012年的网络无障碍内容指南2.0版（Web Acccessibility Content Guidelines 2.0）之后的第三个被ISO/IEC认可的国际标准。
点击查看W3C关于MathML3.0的正式新闻通稿及其中文翻译版本。
W3C TAG: Web的端到端加密（End-to-End Encryption and the Web）
2015年7月16日，W3C的技术架构组（Technical Architecture Group，TAG）发布Web的端到端安全（End-to-End Encryption and the Web）的技术架构组发现（TAG Findings）。
在这份文档中，TAG认为Web是一个用户信任的互操作开放平台。基于强加密（Strong Encryption），万维网可以支持商业创新，并维护用户的信任。在另一份关于加密的TAG发现中，TAG强烈表达了支持采用HTTPS来确保用户的认证性与内容加密保护。最近的W3C标准（如安全上下文、升级非安全需求等）使得加密Web更容易实现。基于TLS的内容加密对于抵御用户信任获取的攻击（如 Permacookie），以及攻击用户的信任证及其他敏感信息的攻击（如FireSheep）等有较好效果。
更多内容，请参阅英文原文。
W3C发布性能时间基线（Performance Timeline Level 2）的首份公开工作草案
2015年7月16日，W3C的Web性能工作组（Web Performance Working Group）发布了性能时间基线第二级（Performance Timeline Level 2）的首个公开工作草案。通过提供存储和检索高分辨率性能指标数据的方法，该规范扩展了高分辨率时间规范HR-TIME-2。
更多信息，请参阅英文原文，及W3C的富Web客户端标准计划（ Rich Web Client Activity）。
W3C发布四份与Web CSV数据相关的候选推荐标准 征集参考实现
2015年7月16日，W3C的Web CVS工作组（CSV on the Web Working Group）发布了四份与Web上的CVS数据相关的候选推荐标准：
- Web表格数据模型及元模型（Model for Tabular Data and Metadata on the Web）候选推荐标准: 该文档给出了一个面向表格数据（tabular data）及其元数据（metadata）的基本数据模型（信息集/infoset），也给出了在表格中定位数据的不同方法，及一些关于如何将表格数据映射到该数据模型的案例和最佳实践。
- 表格数据元数据词汇表（Metadata Vocabulary for Tabular Data）候选推荐标准: 该文档定义了一组标准词汇表，用于描述表格数据特征的元数据，该文档可用于为各类Web数据集（如CSV等）提供不同层次的元数据信息，以及定义表格数据的不同单元格之间的关系。该词汇表采用JSON格式，与JSON-LD兼容。
- 从Web表格数据生成JSON（Generating JSON from Tabular Data on the Web）候选推荐标准: 该文档定义了如何将表格数据转换为JSON格式。
- 从Web表格数据生成RDF（Generating RDF from Tabular Data on the Web）候选推荐标准: 该文档定义了如何将表格数据转换为RDF格式。
上述候选推荐标准的发布意味着Web CVS工作组已认定上述文档的技术设计层面已经完成，现正寻求有关上述文档实现层面上的反馈。现已有超过600多个测试用例以及一个独立的表述如何使用上述标准的文档与有关实现结果的报告（document on how to use them and report on implementation results）。工作组希望通过以下方式得到有关这些标准的评论及实现经验的反馈：作为工作组GitHub存储库中的问题（issues on the Group’s GitHub repository）；发送至CVS工作组邮件列表[email protected]。
Web CVS工作组预计将于2015年10月30日前完成文档实现的目标（例如，每个测试用例至少有两个独立的实现）。更多信息，请参阅英文原文，及W3C的数据标准计划（Data Activity）。
W3C Blog: WICG: 从头开始设计新一代Web
2015年7月8日，Marcos Caceres在W3C官方博客发布文章：WICG: 从头开始设计新一代Web。文章内容如下：
我们要超级兴奋地宣布：W3C的 Web Platform Incubator Community Group， (WICG，W3C Web平台孵化器社区组)启动了！ 虽然名字有点可笑 (“the Why-See-Gee, really?”“啥－看－哇，真的？”)，这是一个美好的新计划，旨在寻求一种更便捷的方式，让开发者把可行的Web平台新特性提交到标准里。
我们希望达成的目标
WICG的目标有：
- 尽可能简单地让开发者提出Web平台新特性，实现《可扩展Web宣言》的精神；
- 提供开发者和实现者的Web平台新特性交流空间；
- 培育新的想法，给没有参与过标准贡献（当然，也包括那些贡献过的!:D）的开发者提供技术指导、必要支持和周到的环境；并且最终把这些想法转化到W3C工作组里进入正式到标准化流程（也就是说，成就一份“W3C正式推荐规范”）；
- 把规范化Web平台新特性的过程变得更现代化（耶！摆脱邮件列表了...除非你真的想用邮件交流）；
- 提供一套法律保障架构，让所有的贡献变得免费和开放。
简而言之，我们希望成为一个立志规范化Web的支持性组织。我们希望能提供你所须的一切帮助，来把你的想法或提案引领到下一阶段。
我们并非...
我们并非计划成为新的“掌权人”。你没有必要去说服我们你的想法有多好，即使你说服了我们，对你也没有什么帮助。我们希望给你的，是在你构想提案的过程给予反馈，是在你把提案呈现到正确的组织后、帮助你迭代和推进你的想法。
浏览器厂商参与了吗？
是的！必须的。Microsoft，Apple，Google和Mozilla全力支持这次尝试。
受到RICG的成功启发，浏览器厂商们希望，关于新特性，能有一种简单的对话方式，提供合理的法律保障同时让繁文缛节最小化。因而，我们需要双方参与者签署《W3C社区贡献许可协议（CLA）》。
尽早地得到浏览器厂商的承诺，是让一个属性得到跨浏览器实现的关键。由于所有的浏览器重要厂商都参与了这次行动，大家的想法能在这里得到开发者和浏览器厂商的快速审阅。
通过共同努力，希望我们所创造的新属性既达成使命又易用，有效帮助我们解决现实世界的问题！
我们怎么让流程变得简单些？
简而言之：GitHub＋装备＋社区支持。
W3C的精灵们一直忙于为我们提供尽可能简单的参与装备。我们将编写规范或用例文档，像别的开源项目一样。
具体流程是什么？
大体上，我们需要遵循已在RICG里实践过的一些流程，虽然我们可能会根据自身的发展去改进这些规定。也就是说，去完成以下流程：
1. 阐述问题：用一份文档描述你发现的这个Web平台缺陷，把它提交到Discourse，并分立一个GitHub repo；或者把它发布到其它地方（例如，blog，gist，任意你喜欢的渠道）。这个问题应该所是你认为Web平台遗漏的角落，添加或者补救以后会大大改善开发者的工作。它也可以是你发现在开发过程反复出现的痛点，可通过写进标准的方式来克服。
2. 签署CLA：在和社区组分享你的想法之前，请签署《W3C社区贡献许可协议》。这是很关键的一步，如这份协议未被签署，我们无法审阅或讨论你的提案。如果你忘记了，没关系，社区组的主席们会友好地提醒你，缠着你直到你签署为止。
3. 评估：作为一个社区，我们会评估你所提出的问题是否真的不能以现有的Web技术去解决。我们也会考虑有多少开发者会受到这个提案的影响。这会涉及到收集数据，真实用例，等等。
4. 用例：如果有必要，我们会把以上信息正式确认在一份用例文档里。这份文档能向社区证明，这是一个有必要去标准化的解决方案（可参考《响应式图片用例与需求》，譬如）。
5. 鼓吹：我们会向浏览器厂商和尽可能多的社区传播这个提案——我们会向任何愿意倾听的组织去推销这个想法。把所有相关人员拉到谈判桌边，也就是我们这个“墙角”里，是很重要的。
6. 标准化：一旦我们得到浏览器厂商或者社区的认同，我们会把大致提案整理好（如，一个新的HTML元素，API，或者HTTP header...），然后完成一份“提交意向”：即把这份规范提交到W3C工作组，以获取W3C会员的royalty free licensing commitments（你懂的，就是free and open里面的free）。
7. （加分）实现：把这份提案从纸上之谈，以代码实现为现代浏览器里面的新特性。
如果你对正式流程感兴趣，可以看看《Web平台孵化器社区组章程》。
支持
我们不会过于糖衣包装：标准化的过程是非常艰难的，不信，问问在RICG幸存下来的人 :-)。
往Web里添加新属性的门槛是相当高的：我们有可能需要募集金钱。或者把大家拉到一个房间开会，像我们有一次在巴黎所实践的。或者在会议里宣传这个特性以吸引开发者的兴趣，为这个特性造势。
然而，任何选择参与的人都会得到很给力的支持。我们有大把顶尖的浏览器/标准工程师聚集在这里帮忙。如果你感到无从下手，或者不太了解你到WebIDL里的RFC2119，不要担心。我们是你的给力后援！
与RICG的合作
我们和RICG是怎么样的关系？既然我们的成员和名字缩写那么相似，还是值得解释一下的。
RICG旨在向浏览器和规范里发掘和推动响应式属性，同时带领更多的开发者参与标准化的流程。而WICG更关注第二点：培育Web平台里的新特性。我们会帮助你整理关于Web平台缺陷的想法，发展这个提案直到它被合适的组织接受为止。当然，这个过程也有可能你的想法被RICG所接纳。
RICG会继续处理和“响应式”相关的Web特性，处理那些从让某人眼前一亮到准备就绪的问题提案。
译者注：RICG成功推动了picture元素，srcset，sizes等响应式图片属性的标准化以及在FireFox与Chrome里的实现。
其它社区组是怎么样的？
其它社区组继续如常工作。然后，WICG为那些浏览器特性提案提供一站式服务。针对特殊情况，我们可能从WICG里衍生新的社区组去处理特殊的特性。
有疑问？
你能随时在twitter找到社区组的主席：
- Marcos Caceres
- Yoav Weiss
- Chris Wilson
译者：希望中文交流的童鞋可通过微博账号@w3c中国 与我们联系。
更多信息，参阅英文原文，W3C Blog: WICG: Evolving the Web from the ground up，以及W3C@siusinng小倩的翻译。更多博客文章，请参阅W3C Blog（中文）。欢迎您使用W3C官方博客及W3C中国网站参与互动讨论。
W3C发布高解析度时间（High Resolution Time Level 2）的标准工作草案
2015年7月14日，W3C的Web性能工作组（Web Performance Working Group）发布了高解析度时间（High Resolution Time Level 2）的标准工作草案。该规范定义了一个API，该API为Web应用提供亚毫秒级（sub-millisecond）解析度的当前时间信息格式，此类信息可以用于应用程序的性能调试或时间同步。
更多信息，请参阅英文原文，及W3C的富Web客户端标准计划（Rich Web Client Activity）。
W3C发布设备API访问权限的工作组备忘
2015年7月14日，W3C的设备API及策略工作组（Device APIs Working Group）发布了一份设备API访问权限（Permissions for Device API Access）的工作组备忘。该工作组备忘指出，这一标准规范的制定工作现已中止，该规范的进一步开展将由Web应用程序安全工作组（Web Application Security Working Group）执行。Web应用程序安全工作组已经发布了一份权限API（Permissions API）的更新版本。
更多信息，请参阅英文原文及W3C的安全标准计划。
W3C发布追踪合规性及适用范围（Tracking Compliance and Scope）的标准草案最终征求意见稿
2015年7月14日，W3C的追踪保护工作组（Tracking Protection Working Group）发布了追踪合规性及适用范围（Tracking Compliance and Scope）标准工作草案的最终征求意见稿（Last Call Working Draft）。该规范定义了“不追踪（Do Not Track, DNT）"偏好的含义、范围及Web站点如何符合用户的各种不同DNT偏好。欢迎您于 2015年10月7日 前提出对该草案的意见和建议。
更多内容，请参阅英文原文，及W3C的隐私保护标准计划（Privacy Activity）。
W3C发布了WAI-ARIA 1.1、Core-AAM 1.1及AccName-AAM的工作草案更新
2015年7月14日，W3C的协议与格式工作组（Protocols and Formats Working Group）更新了可访问富Internet应用（WAI-ARIA)1.1版（Accessible Rich Internet Applications，WAI-ARIA，1.1）、核心可访问性API映射1.1版（Core Accessibility API Mappings，Core-AAM，1.1）及可访问名称与描述：计算及API映射1.1版（Accessible Name and Description: Computation and API Mappings 1.1，AccName-AAM）工作草案。
- WAI-ARIA提供了角色、状态及属性的本体以定义可访问用户界面元素。WAI-ARIA的设计初衷是用来改善Web内容、特别是Web应用方面的可访问性及互操作性。
- Core-AAM描述了用户代理应如何在多内容生成技术（包含大部分WAI-ARIA）并存的情况下，向可访问性API显示Web内容语言的语义。Core-AAM作为基础为其他标准扩展映射到具体技术上提供服务。
- AccName-AAM描述了用户代理如何从Web内容语言中确定访问对象的名称与描述，并在可访问性APIs中显示这些名称与描述。
更多信息，请参阅有关上述三项标准的征集意见通知，英文原文及W3C的Web无障碍计划（Web Accessibility Initiative ，WAI）。
