我们今天所熟知和喜爱的 SVG 是“SVG 1.1 第二版”。 SVG 2 处于 W3C 的编辑草案状态，它有很大的风险永远无法通过这一阶段，因为它的章程可能在达到推荐状态之前无法续签。
Tavmjong Bah 关于原因的一部分
虽然令人震惊且出乎意料，但这并非空穴来风。 工作组的积极参与人数已降至少数几个人，没有一个人代表任何浏览器供应商。 事实上，最后两次“面对面”会议的参与者只有三名常驻成员，其中一人来自佳能（将在年底退出 W3C 会员资格），另外两人是受邀专家，他们正在无偿工作。
和 Tavmjong 一样，我最近也与 Doug Schepers 谈论了 SVG 2。 他向我介绍了大部分主要的新功能。 这是一个不错的页面，其中列出了这些功能以及它们的状态。 我对此的看法是
- 对于普通网页开发者来说，并没有太多杀手级功能，因此我对人们普遍兴趣减退并不感到意外。
- 一些实际上属于 SVG 2 的非常实用的功能已经获得了相当好的支持（例如
non-scaling-stroke）。 - 我通常对事情持怀疑态度。 SVG 2 的功能有可能解锁我目前无法理解的惊人事物。
有一些功能相当明显地非常有用。 其中之一是：z-index。 目前，除了源代码顺序之外，没有其他方法可以控制 SVG 元素的堆叠顺序。 SVG 2 支持 z-index，它将直接生效，这将非常有用。 还没有浏览器支持它，它被认为“有风险”。
三方舞蹈
通常，我认为网络上的新功能是三方之间的舞蹈，分别是
- 开发者。 他们使用这些功能。 他们是想要什么的声音。 他们是衡量什么真正被使用的标准。
- 浏览器。 他们实现这些功能。 他们是守门人。 他们有自己对什么需要的想法。 他们是企业。
- 规范。 它们记录了功能应该如何工作。 浏览器查看它们以了解如何实现功能，因为实现功能的互操作性存在激励机制。 他们是中间人。 他们也有自己对什么需要的想法。
他们中的任何一方都可以施加力量并推动功能发展，尽管最终每个人都必须同意。 开发者可以非常大声地表达他们的需求，这可能会激发浏览器想要为他们提供服务，或者规范作者介入并定义如何工作。 规范作者可能非常渴望完善和发展语言及其 API 并自行推动事物发展。 浏览器可能会强烈地认为他们的客户想要某样东西（或者提供某样东西对业务有利），并率先进行早期实现。
也存在大量的交叉。 浏览器供应商的人可以担任规范人员。 开发者遍布各地。
SVG 2 感觉主要是一项规范驱动的努力。 开发者现在对 SVG 非常感兴趣，但可能没有太多关于 SVG 缺陷的呼声。 我发现开发者大多只是在努力理解已经存在的东西。 但这种新发现的热情可能是推动长期参与 SVG 规范的人继续推进 SVG 2 的原因。
作为一项规范驱动的努力，它需要激发其他各方采取行动。 这部分目前进展不顺。 从开发者的角度来看，我认为这是缺乏杀手级功能。 从浏览器的角度来看，Bah 再次表示
只有两种重要的浏览器实现：Blink（Chrome/Opera）和 Gecko（Firefox）。 在这些浏览器中，只有 Blink 拥有快速完整实现新功能的资源，尽管 Gecko 已实现更多 SVG 2 功能。 Chrome 在浏览器市场份额中占据主导地位（几乎 75%）。 Google 有一个习惯，即单方面从 Blink 中删除它不喜欢的功能，基本上决定从规范中删除这些功能。
另外两个重要的浏览器实现，WebKit（Safari）和 Edge，更多的是跟随者，而不是领导者，并且其市场份额相对较小（分别为 5% 和 4%）。 例如，微软明确表示，在规范成为候选推荐规范之前，他们甚至不会考虑 SVG 2。
读：Blink 想做什么就做什么；Gecko 速度很慢；Edge 不会碰它；WebKit 会静观其变。
情况更糟。
三方 四方舞蹈
对于 SVG 2 来说，还有一个重要的第四方参与者：软件。
据我估计，网络上使用的大多数 SVG 并非由开发者直接创作，而是由软件输出的。 Inkscape、Adobe Illustrator、Sketch、Affinity Designer…… 有许多软件可以导出 SVG。
让我们再举一个 SVG 2 功能，即 b 或 B 命令，它是路径语法的一部分。 看起来它可以通过允许您更改后续路径命令的轨迹角度来实现更高效的路径输出。
这很好，但为什么像 Adobe 这样的公司会触碰它？ 如果他们实现它，他们就有风险输出任何浏览器都不支持的 SVG，这毫无用处，而且肯定会激怒客户。 他们几乎肯定需要等到浏览器支持非常稳定之后才能着手处理类似的事情。 这就开始了恶性循环：为什么浏览器会实现还没有人准备好利用的东西？
因此，即使规范达到了某种完成状态，并且浏览器也采纳了它，我们仍然受制于软件也需要利用它。
直觉
在不知道更多信息的情况下，我倾向于同意浏览器供应商的观点。 Bah 报告
浏览器供应商的普遍共识是，SVG 2 应该完成，但应该限制为修复 SVG 1.1 第二版中的问题以及一些精心挑选的新功能（例如“paint-order”），这些功能已经由多个浏览器实现。 新功能（网格、阴影等）应该删除。
听起来删除新功能非常痛苦，但这可能是为了让它通过山口而不得不从货车上扔掉的宝藏。
据我有限的了解，一个主要的、令人兴奋的功能是网格渐变。 能够在 SVG 中创建沉浸式和阴影效果的想法，为响应式和高性能的网页开发打开了大量可能性。
我只想要一个 flippin’
stroke-alignment属性/特性。内外/居中描边是一个常见的请求（因为它在 Illustrator & Sketch & 其他地方得到支持，而且因为它非常有用）。
SVG 存在一个粗略的提案，但当我们 Inkscape 的代表实际尝试实现它时，他发现存在许多未定义的边缘情况。 在没有人承诺花时间弄清楚现有软件如何处理它，以及没有浏览器承诺如果包含新功能就会实现它之前，人们担心这会拖延 SVG 2 的采用。
该特性（以及其他一些特性）被搁置一旁，将在单独的描边特性模块中进行研究 (此处为粗略草案，其中包含边缘情况问题的详细信息)。 同样，还存在其他“SVG 第 3 级”模块规范草案，其中将包含未被纳入 SVG 2 的其他有趣功能。
不幸的是，由于浏览器现在放弃了 SVG 2 功能，例如网格渐变和 z-index（我们认为它们已得到广泛支持），因此新的图形功能何时（如果曾经）会被研究尚不确定。
现在有一个提议的规范，旨在将文本描边纳入 CSS，并使用所有现有的 SVG 描边特性。 如果
stroke-alignment能够实现，它可能会通过这项工作实现。太可惜了。 在 SVG 成为所有类型使用场景的真正现代化、可维护工具之前，还有很多工作要做。
是的，z-index 会非常受欢迎；但我发现现在可以通过 CSS 对多个属性进行样式化 - 并进行动画！ - 例如
x或r，甚至路径的d。 我们终于可以摆脱用于过滤器和动画的笨拙的 XML 语法（实际上，它就像在 HTML 中使用font元素一样）。 我们可以拥有网格渐变。 我们可以拥有与 CSS 和 JavaScript 的更好集成。我们真的必须等待并希望 Google 能够完成这些工作吗？
关于软件供应商不想输出可能无法正常工作的功能的评论。
Adobe（和其他供应商）长期以来一直乐于包含新功能，并提供多种输出选项。
如果您曾经从几乎任何 Adobe 软件导出或保存任何内容，您一定注意到总是会弹出选项询问您是否希望它兼容或使用最新功能，或者您希望将它保存为哪个版本的 Illustrator 文件，或者在 SVG 的情况下，您想要哪个版本的 SVG 文件以及要支持哪些功能。
我认为很明显，如果这种趋势开始出现，Adobe（或其他软件供应商）会确保他们不会被抛在后面。
这对于 Inkscape 开发人员来说可能是“令人震惊的”，但对于 Web 开发人员来说是个好消息。
SVG 中最有用的部分已经被转移到 CSS 中，并且正在由浏览器供应商实现或正在实现（动画、字体、剪切路径、蒙版、滤镜、转换、渐变等）。
我的猜测是，浏览器供应商现在计划杀死 SVG 2，并直接在 HTML 规范中添加一组最小的矢量元素。类似于 Android 中的 / VectorDrawable 的东西将满足大多数 Web 开发人员的需求。
带回 SMIL
请研究一下网格渐变，然后告诉我没有杀手级功能。所有严肃的插画师都在他们的图形工具中使用它们，然后导出的 SVG 充满了位图，从而使它变得非常臃肿。对 SVG 2 的缺乏兴趣很大程度上是由于无知，而不是规范中缺乏杀手级功能。
经过这么多年，仍然有这么多人不知道 SVG 与任何其他替代方案相比的强大功能，这让我真的很震惊。尤其是那些简化 SVG 制作快速、响应式（可缩放）和可访问性的功能。
还有一个主要的类别没有提到，也不应该被遗忘——Web 软件供应商和程序员，他们拥有工具和/或代码来简化 SVG 的动态生成，以及支持动态交互......Google Charts 就是其中一个例子。是的......设计 SVG 内容的设计师会影响“桌面”软件供应商支持的功能（例如网格渐变），但我认为更大的问题是接触到更广泛的受众，让他们都意识到......并让他们都兴奋......关于应该（可能将）对他们很重要的功能的潜力。
首先，描边对齐、z-index 绝对是杀手级功能。在没有它们的情况下，处理动态堆栈顺序非常困难。它们不仅仅是锦上添花。它们可能非常难以绕过。网格渐变是一个非常不错的功能。如果没有它们，SVG 看起来像 MacPaint。随着时间的推移，它会看起来越来越过时。SVG1 中的文本流对于任何处理过它的人来说也是一场噩梦。带有文本的 ForeignObjects 无法按预期工作，任何地方都无法工作。
首先，我们只需要每个功能一个有效的炫酷演示，在一个浏览器中运行。那些说“为什么这个带有网格渐变的出色数据可视化在您的浏览器中无法正常工作？”的错误票据具有合法的羞辱力。在我遥远的估计中，Blink 团队在关闭 SVG 票据方面做得很好，尤其是自 Opera 加入以来。
更一般地说，我很沮丧的是，似乎没有一个可靠的策略来以向后兼容的方式添加功能。将 SVG 解析器切换为使用 HTML5 解析器似乎在这里打开了可能性。无法识别的元素和属性可以简单地被忽略，而不会抛出解析错误。必须有一种方法来构建 SVG 以便能够进行基本的渐进增强，否则新功能将变得不可能添加。HTML 很久以前就基本上解决了这种锁定问题。
最后，我认为记住 SVG1 是一个疯狂的圣诞树规范，包含许多需要十年时间才能实现良好互操作性的东西，这一点很有用。我们被当前良好一致性环境所宠坏。很长一段时间，只有 Opera 拥有真正优秀的实现。但我们今天拥有如此强大的东西，部分原因是最初的规范编写者在进行有远见的思考。看到这种未来主义方向的精髓逐渐消失，有点令人难过。继续梦想，人们！
好吧，真是糟糕。
使用元素
我对“Gecko 实现了更多 SVG2”是如何变成“Gecko 实现速度慢”的总结感到有点困惑。
Marco Carosi 写道