自由分组话题讨论（Breakout sessions）是TPAC大会最具人气的环节之一。参会者可自主发起议题并深度参与讨论，内容涵盖W3C标准动态、Web技术前沿及生态发展的关键挑战与创新趋势。

在TPAC 2025大会期间，来自日本神户线下会场的500余名参会者及近200名线上与会者共同提议并组织了85场分组讨论。

今年会议期间，若干议题方向尤为突出。以下归类虽为自发形成，但生动体现了社区驱动议题的多样性与广泛影响：

• 人工智能（AI）
  • AI智能体与Web生态
  • WebSpatial API：在多模态AI设备上对HTML/CSS和PWA做空间化UI增强
  • 智能体浏览与Web的安全模型
  • 智能体网络协议（ANP）的设计与实现
  • 语义赋能Agentic Web
  • 强强联合：以无障碍目标赋能智能体AI
  • AI驱动的Web规范
• 无障碍
  • 可访问性角色与职责映射（ARRM）及其在无障碍评估中的作用
  • 无障碍兼容性数据更新
  • 针对WCAG及其他无障碍规范的有效且可信的合规性评估
  • 辅助技术与ARIA-AT互操作性的未来展望
  • 移动端无障碍：WCAG2Mobile的阐释与讨论
  • WCAG 2.2与非拉丁语言
  • 动态可访问性修复：边缘无障碍社区组报告
  • Web内容无障碍指南（WCAG）3.0进展
  • “无障碍成熟度模型”小组备忘更新
• 身份、凭证与数字钱包
  • 凭证管理API的融合用例
  • 支持生物特征检测的Web平台功能
  • 移动学生证在日本社会的推行
  • 台湾地区的数字身份钱包项目
  • 数字凭证API安全考量与威胁缓解措施
  • 数字身份系统与威胁的整体视角
  • 针对国家数字身份系统的危害与威胁建模
  • 面向智慧城市的Lean4-Verified协议—解决DID与VC三大核心挑战
  • 基于年龄的Web内容限制
• 隐私与安全
  • 用于数字广告验证的Privacy Pass协议
  • 地理位置与隐私
  • 隐私跨源/跨站预加载
  • 面向Web开发者的安全指南
  • W3C威胁建模指南与Web威胁模型
  • 解决客户端安全问题的创新方案
  • Web支付身份验证：发卡机构视角
  • W3C联盟治理
  • 开放Web平台的未来
  • 探索未来之路
  • W3C标准化流程问题反馈
  • 推动学生与学术界参与Web标准开发
  • 重启W3C QA—标准化质量保障计划
  • 面向所有人：迈向独立标准化工作的可持续未来
  • 提升AC代表参与度

GitHub上每个issue对应一场分组讨论，通常包含讨论议程、演示文稿、会议纪要和相关录制的链接（如有）。我们已邀请各话题组织者提供关于如何开展后续交流的信息。

参会者对本届大会分组讨论的议题质量与议程安排普遍给予积极反馈。今年我们首次尝试将分组讨论分散在多个日期举行，此举显著减少了同一时段并行议题的场次数量，有效缓解了与会者因议程冲突而需做出取舍的难题。

总体而言，今年共设9个时段的分组讨论，同一时段最多开放10个并行会议室；而2024年虽同样举办85场讨论，但仅安排6个讨论时段，且每时段并行会议室数量最多达14间。

这一调整成效显著：我们收到了更多的积极反馈，相关抱怨也显著减少。根据反馈，我们已开始探讨如何在明年增加会议天数以安排更多分组讨论场次，从而进一步减少同时段并行的会议数量。

特此提醒，任何人都可以免费远程参与TPAC分组讨论。诚邀您于2026年10月参加TPAC 2026分组讨论活动。

自2006年以来，W3C一直鼎力支持巴黎Web系列大会。该会议聚焦于web最佳实践，积极推动web无障碍与技术进步。

作为最具包容性的行业盛会之一，会议全程提供法语手语实时翻译、英文演讲的法语同传服务，并配有实时字幕投屏。

在2025年第二十届大会上，François Daoust将发表主题演讲（法语）：Maintenance du web : des données de référence, des boucles et du lien humain。

WebDX社区组成立于2022年，致力于为开发者提供便捷的Web平台功能追踪方案，涵盖已广泛实现及开发中的功能。

小组重点开发开源web-features项目（一个共享的Web平台功能目录）和Baseline 状态，为开发者标注哪些功能可在主流浏览器中稳定运行。Baseline徽章现已集成至Can I Use、MDN、RUM Archive Insights、RUMvision等平台。欢迎观看视频资料Baseline web features for the win（2024年9月发布）快速了解web-features项目。

今天，我们很高兴地宣布WebDX社区组取得的一项重要成果：在@mdn/browser-compat-data项目（BCD）中定义的大部分关键数据（BCD为MDN兼容性表格提供数据，包含Web规范中最完整的细粒度功能集）现已被映射到web-features项目中的1000多个高层级功能。这提供了首份近乎完整的Web功能目录并附带其Baseline状态。该目录以web-featuresnpm包的形式发布。

感谢Open Web Docs、MDN、各浏览器厂商以及所有参与贡献的组织！感谢小组成员为推进该项目所付出的努力！

在目录中绘制浏览器支持数据，展示了Web平台从2003年6月Safari首个版本发布（95项功能）到2025年2月底（1006项功能）的发展历程，包括功能数量的增长及各浏览器中Baseline状态的变化。数据还反映了不同功能的分布情况：截至2025年2月，已有部分浏览器实现的功能328个，Baseline新可用（Baseline Newly Available）功能150项，Baseline广泛可用（Baseline Widely Available）功能528项。请注意，支持数据仅涵盖主流浏览器（Chrome、Edge、Firefox、Safari），且Baseline的概念仅在所有这些浏览器都发布首个版本后才具有意义（Baseline Newly Available状态需在2015年7月后，Baseline Widely Available状态需在2018年1月后）。

[以下内容源自 MiniApps 工作组团队联系人薛富侨发布在 W3C 官网上的博客文章]

W3C MiniApps 工作组与 MiniApps 生态社区组于本月初联合组织了首届 MiniApp 中日韩线上讨论会。会议的主要目的是汇集中日韩相关厂商，更深入地了解各区域的 MiniApp 生态，介绍 MiniApps 工作组、社区组当前开展的工作，以及未来 MiniApp 在 W3C 的标准化方向。来自30多家单位的57位与会者参加了本次会议。

会议由提前预录的讲者报告以及线上实时讨论两部分构成。预录报告包括：

* 快应用的演进之路

* 小程序运行时架构和联盟发展经验

* 从多端框架Taro的视角看小程序规范

* 小程序跨平台技术标准设计

* 汽车上的MiniApps

线上讨论环节侧重交流了 MiniApps 生态、技术架构、跨平台框架、新场景的应用与标准化，以及 MiniApps 工作组现有规范的开发进度。各讨论环节概述如下：

MiniApps 生态

董永清（小米）谈到了国内智能手机和开发者生态现状，以及快应用（QuickApp）这种 MiniApps 形式解决了哪些问题。

张腾元（百度）介绍了传统 HTML5 应用程序和原生应用程序的缺点，以及 MiniApps 如何在两者之间寻求平衡。

MiniApps 技术架构

董永清（小米）介绍了如何开发、调试和分发快应用。

张腾元（百度）分享了 MiniApps 的开发方式以及 MiniApps 平台如何获取、加载和运行 MiniApps；同时还谈到了百度智能小程序的技术架构和性能优化。

胡雄伟（京东）介绍了京东小程序的体系结构以及开发/发布过程；讨论了如何使用 Shadow DOM 来实现组件、如何进行布局、如何确保用户信息的安全性，并介绍了京东小程序运行时的设计。

跨平台框架

陈嘉健（京东）介绍了当前各种 MiniApps 平台的背景和趋势，开发跨平台 MiniApps 时遇到的常见问题以及 Taro 是如何解决这些问题的。

崔红保（数字天堂）谈到了 MiniApps 平台的现状以及 MiniApps 标准化和国际化的重要性。

因为当前的主流 MiniApps 平台不支持 DOM 操作，与会者还讨论了支持 DOM 操作的必要性。

新场景的应用

安勍（阿里巴巴）概述了 MiniApps 的不同应用场景，包括移动电话、物联网、汽车等，并着重介绍了 MiniApp 在汽车上的优势、使用场景和潜在的标准化机会。

MiniApps 标准化

张永靖（华为）介绍了 W3C MiniApps 工作组中的标准开发现状，以及 MiniApps 生态社区组正在孵化的新方向。他同时邀请与会者加入到围绕 MiniApps 的讨论中，共同推动 MiniApps 的标准化进程。

* 加入 MiniApps 工作组（向会员及特邀专家开放）

* 加入 MiniApps 生态社区组（向公众开放）

MiniApps 标准工作组将继续完善正在开发中的规范，同时征求广泛的审阅意见。MiniApps 生态社区组将与 W3C 其他小组展开合作，以不断孵化新的标准化需求及方向。MiniApps 工作组主席呼吁建立 MiniApps 中日韩特别任务小组，以便中日韩社区后续能够维持交流并实时跟进相关进度。更多内容，参见本次会议纪要。

[以下内容同时发布在“W3C资讯”微信公众号] CSS 的开发大致始于25年前，当时最初的设想是为偶尔带有图片的单列文本提供一些简单好用的样式。事实证明该技术十分受欢迎，它不但足够灵活而且使用范围也可以更广。 也是从那时起，我们开始不断地为 CSS 添加新功能。 现在的 CSS 已经可以应对多列、垂直文本、斜线文本、图形用户界面的布局、图像操作、动画、按键及鼠标交互等各类需求。

从1996年 CSS 被首次标准化以来，操作系统已经有十几个版本甚至更多，浏览器也经历了几十个版本的更迭。不少浏览器如今已经消逝，新的浏览器又不断出现。 CSS 也随之成长，但至今依然被称为 CSS。

有人认为存在着几个营销方面的问题。 W3C 从未大张旗鼓地隆重宣布 “CSS X” 已经具备的全部强大新功能。印象中 CSS 总在不定期地一点点增加新特性，可能很多人都未曾留意到。许多 Web 开发者也因时间或兴趣原因，不能实时关注 W3C 或各类软件制造商去了解 CSS 的新特性，他们可能是之后才偶然地留意到。对于想要推销自己的 Web 开发者来说也有问题：他们在简历中写些什么？ 倘若写 “CSS专家” 其实很可能意味着十年前的 CSS。 

在我们探讨是否有应对方案之前，让我们先来看看 CSS 的版本历史。

The original goal for CSS was to create a technology that provided good typography for simple documents.

正如上面提到的，1995年左右对 CSS 的最初设想是创建一项技术，为 Web 上的简单文档（例如 HTML 格式）提供好用的样式。尽管十分简单，但是与传统的文档布局相比，它对早期的 Web 浏览器来说还是一个挑战。 因此，我们在1996年率先对一小部分子集进行了标准化，并将其命名为第一版（level 1）。完整的 CSS 于两年后问世，即第二版（level 2）。

CSS 第二版实际上仍未达到最初的设想，这主要是由于浏览器遇到的困难比预期的要多（起初的主要版本甚至没有数据结构来存储文档树。而且由于担心破坏重要的网站，它们有着无法修复的 bug）。 然而无论如何 CSS 仍然很受欢迎，人们要求添加更多的特性。结果表明，语法和级联与继承系统可以支持更多的版式功能，且不会产生太多问题。

但 CSS 第二版规范已经是一个相当庞大的文档了，它分布在20多个 HTML 文件中。尽管有些新功能很简单，同时也有些功能似乎还需要更多研究。基于这些原因，工作组决定将 CSS 分解，将其转化为包含一系列更小规范的合集，并称它们为 “模块（module）”。每个模块各自包含一小部分关联属性或其他特性（selectors、@-rules等），且尽可能不依赖于其他模块。这意味着各模块可以按其自己的速度发展。此外，每个模块都足够小到可以放在一个 HTML 文件中，这使编辑和发布变得更加容易。

The full set of modules of CSS now includes everything from modules that are still level 1 to modules that are already level 5.

如此一来，CSS 被划分成了 “选择器”、“背景和边框”、“字体” 等模块。随着时间的推移，又添加了 “书写模式”、“网格”、“转换” 等新模块。1998年发布的模块在包含第二版（level 2）功能的同时添加了更多新功能，因此该模块被命名为第三版（level 3）。只包含新功能的模块则被命名为第一版（level 1），来表示它们不是任何规范的超集。久而久之，一些模块得到标准化，然后被扩展添加新特性，之后又再被标准化，因此完整的 CSS 模块集（包括已经标准化的和正在开发中的）涵盖了从现在仍是第一版到至今已经是第五版的所有模块。

换言之，整体的 CSS 不再划分 levels。它是一系列规范（模块）的集合，每个模块拥有各自的版本并随着新功能的添加而获得新版本。在任何时候，当前整体的 CSS 都被定义为所有稳定模块的集合。例如，去年12月 “CSS 写作模式第三版” 经历候选推荐标准（CR）最终成为 W3C 正式推荐标准（REC）。在那一刻 CSS 隐式地改变了：它不再是由该模块在 CR 阶段时定义的那样，而是由最新发布的 REC 所定义。但是，没有任何新发布的规范被称为 “CSS”。

这对工作组来说是很好的模式，他们可以随时发布 CSS 新功能，而无需等到不相关的性能就绪。这也适用于规范实施者，他们只需要知道 CSS 由哪些模块组成，且其中哪些模块已经是稳定可被实现的（工作组以 CSS 快照的形式提供这些信息，快照文档每隔一年左右更新一次；工作组页面也列出了小组当前工作）。

The best known sources of implementation status are probably MDN and Can I Use.

这是否适用于使用 CSS 编写样式表的人？工作组很久以前就决定向规范实现者（例如浏览器和软件开发商）提供准确且有用的信息。工作组不会有足够的资源向用户提供同等级别的信息，它没有研究 CSS 的某部分得到了多大范围的实现以及可用于哪些目的。

工作组更关注一项规范是否是可实现的。通常情况下，如果两家独立的软件厂商成功地实现了一项特性，那么就足以证明该特性是可行的。一般围绕一份规范会有两个以上的独立实现，有时也需要一段时间其他软件厂商才会考虑实现该特性。与大多工作组相同，CSS 工作组在规范发布后不会主动跟踪规范的实现情况。幸运的是有其他人在做着这项工作，其中广为人知平台可能是 MDN 和 Can I Use，它们跟踪规范在几个主要浏览器中的实现状态。此外，最好的情况来源是实现了该规范的软件产品本身的文档。

‘A tremendous number of books, courses, and conferences were dedicated to CSS3.’

回到为开发人员定义整体 CSS 版本（version）的问题：以何种方式定义才更有用？新版本应该多久定义一次？谁来定义？

CSS 有诸多用途。对移动应用程序和 Web 页面来说可用的属性集是不同的。倘若你是一个用 CSS 布局书籍的出版商，那么可用的属性则又不同。也许应该有不同系列的 CSS 版本用于不同的目的。

要想切实可用，在定义一版 CSS 时，它应该同时得到现实合理的实现，这样开发人员才有必要开始学习这一版本。这反过来又会激励其他软件厂商去实现它。那么“合理的实现”的衡量标准又是什么？

人们认为应该定期发布新版本，但又不希望太过频繁，因为没时间阅读太多的通知消息。人们想要将新版本编辑成书，或是开发相关的报告和课程，这些都需要时间。引用 Chris Coyier 的话：“正如 Jen Simmons 所写，已经有大量专门介绍 CSS3 的书籍、课程和会议”，然而关于什么是 CSS3 还没有定义，工作组显然也从未定义过。

新版本之间的间隔也不应太久，因为如果新特性几年都没被收录，那也将是一种浪费。

至于谁可以定义一个整体的 CSS 版本？CSS 工作组本身似乎很难有时间。Fantasai 建议工作组充当发行者的角色，同时可以有这样一个委员会，成员由 Web 开发者所在的各公司推荐，委员会通过定期会议来决定是否应该开发新版本，以及新版本应该收录什么。近期成立的 CSS4 社区组或许是推动成立这样一个委员会的渠道。

按照 Peter-Paul Koch 的说法，甚至不需要对 “CSS X” 给出精确的定义。大概每三年选取一些在此期间添加的新模块，并将它们依次写入相应的 “CSS 4”、“CSS 5” 等版本中。他还认为 CSS X 可以是其中两个新模块，再加上先前版本中的所有内容，以及一组松散定义的其他模块的集合。

更多内容，参见：
* @w3cdevs 介绍了关于 CSS 版本的历史
* Rachel Andrew 在《Smashing》杂志上关于 CSS 版本的总结文章
* 所有的 CSS 模块列表
 

[以上内容译自 CSS 创始人之一 Bert Bos 的博客文章，原文在这里]

W3C 与 Mozilla MDN 团队以及浏览器厂商合作设计推出了一项征集 Web 开发者和设计人员需求的活动。我们诚邀开发者社区利用十几分钟的时间填写本次《调查问卷》。

本次调查的目标之一是更好地了解开发人员认为基于浏览器的 Web 平台所存在的缺陷，识别推动平台发展在技术和实现方面（例如标准）的优先级。MDN 将公开分享这次调查和评估的结果，我们希望调查结果能为 W3C 的标准化路线输入意见。此外，Mozilla、Google、Microsoft、Samsung 计划将该项调查结果作为各自功能开发优先级的参考，其他浏览器厂商也可能会采用本次调查结果。

MDN 是由 Mozilla 维护的为 Web 开发者提供技术文档可靠来源的平台，致力于提供中立的 HTML、CSS、JavaScript 以及 Web APIs 文档，确保它是基于标准的 Web 开发的首选参考。W3C 作为 MDN 产品咨询委员会成员，为其提供中立的咨询意见。

更多内容，请参阅来自 W3C 团队 Marie-Claire Forgue 的博客文章。

2017年10月18日，W3C宣布加入Mozilla开发者网络（Mozilla Developer Networks，MDN）合作，与Mozilla、微软、谷歌、三星一起，共同支持MDN Web 文档（MDN Web Docs）项目。MDN提供了跨浏览器的Web标准的各类文档，可以帮助Web开发者学习和共享有关开放Web平台的技术和信息。

MDN是一个由 Mozilla 发起的Web开发者文档门户（documentation portal），其宗旨是提供关于 HTML、CSS、JavaScript及各类Web API的无偏见的、浏览器中立的技术文档。

要构建基于标准的开放Web平台，一个重要的前提是在这些标准能够被广大开发者接受和采纳。作为一名开发者，MDN能够提供关于Web的大量有价值的资源。我们欢迎广大 Web开发者能够为构建未来的Web平台贡献力量，帮助Web标准及其技术文档共同发展。

更多内容，请参阅W3C Blog: W3C To Work With MDN on Web Platform Documentation，及W3C的其他官方博客文章。

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。未来，我们将建立 HTML 规范的持续发布机制，可以通过 Github pulse 了解新的进展，并在 Twitter 上关注 @HTML_commits 及 @HTMLWG。

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

测试：W3C的每个工作组都需要说服 Tim Berners Lee 所制定的标准是“足够清晰、完整，且满足市场需要，并能确保标准中的每个技术特性能够独立的、可互操作的实现”。在HTML 5.0的制定过程中，我们启动的自动测试系统 Webapps test harness。但为了达到标准的质量目标，我们希望接纳更多能够展示互操作性的测试用例，无论这些测试用例能否被自动测试系统自动执行。

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

翻译有删节，详情请参阅 英文原文 W3C Blog: Woring on HTML 5.1。

Charles McCathie Nevile在W3C博客上撰写题为“HTML：下一步是什么（HTML：What's Next）”的文章，内容翻译如下：

从去年末开始，Web 平台工作组承担起发布 W3C HTML 规范的责任，以及一系列的其它核心标准。我们现在进展如何、下一步计划是什么呢？

简单来说，故事就是，我们正朝着在今年稍后一点发布 HTML5.1 正式推荐标准的目标前进。目标为提供一个更符合实际的规范，通过收纳已被广泛实现的元素以及删除没有得到实现的内容。

我们也希望更多的开发者和组织参与其中，以保障 HTML 的发展继续反映着更广大开发群体的需求和目标。

这过程的重要一步是，编辑们（Arron Eicholz, Steve Faulkner 和 Travis Leithead）已在 GitHub 上发布了最新的编辑草稿，并成功运用 bikeshed 来生成文档以让日后的参与者更有效率地编辑。当然，不一样的编辑需要不同程度的投入...

修正一个错别字，或澄清一些文字让其更容易被理解，是比较轻松的开始贡献的方式，有助于开始熟悉此规范的源代码和 github 工具，从而完善 HTML。这个程度的编辑总是只须极少的讨论就被轻易接受。

同时，我们也欢迎新想法——理想状况是你的 pull request，但有时提起一个 issue更恰如其分——对那些还不具备标准化条件的特性，例如那些没有得到广泛实现的特性。

自然，新特性的提案需要最多的投入。在 HTML 规范纳入一个重大的属性提案前，须有足够的证据支持该属性已被广泛实现——被浏览器、电子书、内容发布者、管理系统开发商或者框架开发者都是关键涉众。Web 平台孵化组是一个特意设计为此流程提供无偿协助的社区，虽然并不要求必须经过孵化组来实现。实际上，picture 元素是在它自己的社区组发展的，这也是一个如何成功提出新属性的好例子。

最后，去年曾有关于 HTML 模块化的长时间的讨论。但这不仅仅是把规范简单分成几份——模块化要求很多深层次的重构才能真正产生收益。我们期待开始用这种方式来发展新的规范，但现在我们还是更关注改善现有规范的质量。

工作组现正朝着其目标稳步前进，HTML，以及计划里的其它规范。W3C 很大部份的文档发布现正逐步获得各大组织所提供 Royalty-Free 专利许可的承诺，对一些拥有众多专利的大公司此许可或者需要更多的时间。同时，Art Barstow，Web 应用工作组多年的联合主席、亦是本工作组的一位始任联合主席，因其它的职责不得不提出离任。虽然 chaals 从 Web 应用工作组继任本组的联合主席，以及得到新主席 Adrian Bateman 和 Léonie Watson 加入支持，我们仍然怀念 Art 无价的贡献付出，以及 Art 本人。

因此，虽然我们还需要一点时间来继续此使命，我们现在已有自信 HTML5.1 能在今年按计划交付，同时也将持续努力为来年发布及一步优化的 HTML 正式推荐标准（5.2？我们还没有开始为选择版本号烦恼...）创造先机。

今天我们发布了 HTML5.1 的一版正式工作草案。我们也有望很快按固定的频率持续发布工作草稿。

“公开工作草稿”是我们持续进行更新的编辑草稿的快照版本。它们将被用作可被审阅的里程碑版本。它们也拥有在 W3C 专利政策下对 royalty-free 专利许可所做出的 IPR 承诺。

更多内容，请参阅博客原文，中文翻译。感谢吴小倩的翻译。 

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中国网站参与互动讨论。   

2014年7月4日消息，W3C将参与2014年10月23-25日在美国旧金山举行的 浏览器中的图书：推进开放Web标准与数字出版（Books in Browsers: Advancing Open Web Standards and Digital Publishing）活动。W3C的数字出版标准计划（Digital Publishing Activity）正致力于让开放Web平台更好的适应出版行业的需求，并在Web技术社区与数字出版相关的技术社区之间建立交流与沟通的桥梁。此次活动引起了W3C的巨大兴趣。

浏览器中的图书（Books in Browser）是一个由新一代互联网出版公司组成的高峰论坛，主要关注如何为开发者和设计人员提供在线图书、表达、艺术等方面的发布工具。

此次活动将于2014年10月23-25日在美国加利福尼亚州旧金山市的Gray Area Foundation for the Arts举行，活动由Hypothes.is项目及法兰克福图书节（Frankfurt Book Fair）共同承办。W3C将积极支持该活动的举行。 欢迎您于2014年7月28日前提交您的分享内容，具体参见活动主页。

更多信息，请参阅：

- W3C的数字出版标准计划（Digital Publishing Activity）

- W3C Blog:  Books in Browsers event in San Francisco, 23-25 October

更多博客文章，请参阅W3C Blog（中文）。欢迎您使用W3C官方博客及W3C中国网站参与互动讨论。  

W3C的Bernard Gidon 8月9日在W3C官方博客撰文，介绍了汽车与Web平台商务组 (Automobile and Web Platform Business Group) 的新进展。

该商务组的成员QNX已经在结合Genivi, Tizen和Webinos等建议的基础上，将其API的草案提交给小组讨论，小组开始工作程序，预计在2013年12月形成统一各方意见的第一版标准草案。小组也正在讨论确定下一次技术研讨会 (f2f meeting)的时间安排。我们欢迎您关注并参与驱动汽车技术变革的机会，加入W3C的汽车与Web平台商务组。

查看博客文章的英文全文，请参阅W3C Blog: News from the Automotive and Web Platform Business Group。

7月16日，W3C的Marie-Claire Forgue撰写博客文章，总结了今年6月8日在日本东京举行的开发者交流会（Developer Meetup）。本次活动由日本游戏公司GREE Inc主办，大约300人参加了此次交流会。

更多信息，请参阅W3C Blog: Tokyo Developer Meetup [belated report] 。

更多W3C博客文章，请参阅W3C博客文章新闻页。 

W3C的汽车和Web平台Business Group于2013年5月29日在日本东京举行研讨会，超过30个汽车行业相关的成员参与会议，包括汽车制造商、汽车设备供应商、软硬件提供商、电信运营商及学术界、政府和W3C人士。KDDI、Access、Obigo及Intel在会上介绍了在汽车领域使用HTML5的展示，Tizen, Webinos, GENIVI和QNX等分别提出了基于HTML5的车辆API建议。LGE展示了通过API获得部分OBD-II数据。关于讨论会的更多信息请参阅会议总结。

2012年11月，W3C在意大利罗马举行了W3C Web与汽车研讨会（Web and Automotive Workshop），会议报告于2012年12月发布，探讨了Web技术在汽车和车联网应用中的机会和挑战，一致认为HTML5是一个构建车联网应用的具有竞争性的基础。 2013年2月21日，W3C与汽车工业届联合成立汽车和Web平台（Automotive and Web Platform）的Business Group，推动在汽车工业中加速Web技术的应用。

Business Group和Community Group都是W3C收集行业标准化需求的一种机制。参与Business Group的成员不局限于W3C会员。