不用说，我个人网站上的观点都是我的个人观点（真有趣）。没有任何我客户的观点，更不要说MathJax团队了。我觉得它们对任何人任何事而言应该都没有特别的帮助，可能特别的部分除外，但可能会对鼓励进行更开放更现实的讨论有点作用。

本文的要点

MathML是一个失败的网络标准。^*

我们可以做的更好，我们应该做的更好。

MathML-in-HTML5正在做这些。

^*有些人更倾向于认为是“浏览器标准”，因为它是“一个在浏览器中原生实现的网络标准”，而一些网络标准并不依赖浏览器的实现。同时是在浏览器中“原生”支持，而不是通过传送到浏览器中的网络组件进行支持。

MathML是一个已经失败的web标准

MathML是否是一个优良的XML语言已经无关紧要，就我个人而言，我认为这个语言是很好的，它显然也是一个成功对外发布的XML语言，并服务于标准中一个重要的角色，例如JATS和BITS。

问题是：MathML已经在WEB失败了。

幸运的是，许多技术已经成功并且当今MathML已经不再是必需的，但也不在满足于WEB上的函数，我们有很多整体解决方案，而不是一个。我们应该承认这些并向前发展更新型化更小型化的标准在实际中帮助开发者。

以下有几点原因让我多说两句。

1、MathML无论在规范层面上还是实现层面上都还没有被浏览器厂商明确支持。

你可能很容易的认为它们是用来（办公！chromevox？（是个插件？）工具程式）但是浏览器厂商实际上没有。一部分在Gecko和Webkit上实现的MathML完全是志愿者的工作，基本上没有薪水，无人监管，没有责任。

没有一个浏览器厂商表示在代码上去规范，没有一个浏览器方面开发者在MathML出现,18年后，甚至没有一个浏览器厂商愿意献出一小部分的开发人员致力于MathML开发。

这应该是本篇故事结束的地方，说真的，悲哀的是什么都没有。MathML在XML的成功保住了，不是WEB上的利益产物。

MathML是一个欠佳的WEB标准，未来迁移到HTML5会有更好的发展。

2、浏览器对MathML实现是另辟蹊径。

如果你经常看公开的爬虫数据，你会注意到很难找到MathML的免费的案例。如果你目光长远些，你将很难找到别人提供的依赖本地实现的demo；甚至在Gecko和WebKit人们经常使用MathML-to-HTML5转换器。另一个指标，尽管在过去两年对MathML实现正在慢慢的变味，人们也没有去抱怨（我的意思WebKit停止 drawing surds（在safari8中尝试）但是显然没人去关注即便是文件bug）。实际上开发人员的难题是不能认真的开发与MathML相关的高级版本。（比如，Gecko已经下架或者不完整的支持基本API，如风格，数据，MathML元素事件处理程序）。

3、MathML未能提供有用的语义内容

好吧，说实话，我不知道。问题是：它几乎不可能产生有用的内容（大量手工劳动除外）。据我所知，没有一个单线程的有效数字编码MathML内容聚集，这主要是短暂的研究项目和一个手工制作项目。没关系，毕竟我们需要继续研究，但对于web来说还不是一个标准。

4.前端开发人员认为MathML表现出的失败是因为它应该提供一套可用的CSS特征，而没有必要约束MathML元素的设计特征。

现在<mstyle>, <mspace>, <mpadded>, <mphantom>, <menclose>, <mfenced>, <mtable>, <mstack>对开发者而言可能听起来会很有趣，但是它是一个严重的问题。该网站已经创建了一个有效的分离关注点。MathML是和本身的方法是互相矛盾的。

5.MathML的失败是因为它没有充分的布局详细说明。
 

假定一个MathML实现者可能知道或者关注它的复杂性和传统性布局，你怎么画一个根号？没有明确的说明，你如何去画一个分数符号？也没有明确说明。怎么分隔开数字？更没有明确说明。但这也没错，可爱的实现着们，你应该支持更加晦涩难懂的数学布局特点，比如极限，行家的字典，微小的间距，直列布局的差异和显示风格等等，你知道它们是多么重要，对吗？而且确保实现5个不同的垂直堆叠，因为，原因——kthx, xxo.](笑而不语)
 

6、MathML的表现失败是因为数学式所需的CSS布局是缓慢的实现所有的布局特征，这样会让它过时。

如今，许多工具容许你使用CSS渲染数学运算，虽然很乱但是无处不在（好吧，亲爱的IE7使用者，不包括你，我很抱歉）。当时MathML的实现显著的提高了WEB布局特色。

7、MathML的表现失败在于未能提供足够的语义。

尼尔·索弗创造性的编写了MathPlayer软件，让MathML的数学运算表现方面被大多人所理解和接受。更加准确的说OCR意味着所有的图文实际是可以接受的。

现实情况是，几十时高中数学你也需要高质量的MathML展现（这本身就很稀有）结合强大的（但是无法避免会失败）启发式算法提取有意义的语义信息，在短期趋势内饰可以接受的但是对WEB上的数学语义来说不是真正的解决办法。

8.  MathML 的细则没有被活跃地开发.
 

MathML 在最近十年都不那么活跃。在工业化的XML世界里，MathML 是成功的，而人们想要更多的功能，但改进却迟迟没有到来。它看起来没有人想要去危及其在 web 上通过。 MathML 成为一个 web 标准对用户来说是负面的，那些用户使用它是因为 MathML 被困在了维护模式。

你知道 MathWG 的 charter 在这个月就要到期吗？你会注意到如果不是续签，WG 还会存在吗？你会注意到如果 WebKit 和 Gecko 被扯掉，他们的 MathML 明天会实现吗？我真不知道大多数人会怎么做。

下一步需要做什么。

A）MathML需要从HTML5中剔除。

我见过的许多人，都错误的认为浏览器制造商曾经公开表示在HTML5的一套标准里边实现它们，但是他们没有（即使HTML5是作为一个“规则”努力争取过）。

我认为MathML既然只是一套标准，认为没有用处的人的论据（它只是一个标准）将继续阻止替代产品的发展，能够在实际工作中帮助解决WEB上的数学运算问题。

在这一点上，一直以来在WEB上MathML有效的阻止数学运算的准确度，这大大的伤害了每一个人，我们需要从HTML5中剔除掉它来为更好的标准的产生腾出地方。

B）数学布局应该在CSS和SVG中实现，我们应该做的更好更简单。

在服务器上，它可能生成HTML + CSS和SVG渲染任何MathML内容，你要注意，不需要客户端JS（完全可以）。由此产生的标记是很容易证实的，在一些情况下是很困难去实现的，但是使用HTML和CSS人员知道如何解决。这让我们的标准做的像flexbox和css网格；这是值得继续改进的标准并实现而不是等着Godot。

编写一个自己的数学渲染工具也是很难实现的。但是我们需要更多创造性的想法，编写一个在CSS和SVG里的数学渲染器比编写一个RWD框架或者一个一个矢量图形库应该更简单些。

我们不需要MathML渲染的东西即使许多项目（像是MathMLJax）使用它作为一个内部格式。MathML作为一个WEB标准失败之处在于它损害了web自身，因为它阻断了关于提高现有标准来帮助现有的数学工具的承诺，最终“MathML会解决一切问题的讨论（TM）“。

我没看到一个本地的 MathML 方法能帮助填满这所有的坑。现有存在的渲染解决方案实现的需求与 MathML 实现的需求差别不大。我们不需要在指定情况下制定布局的特征与 MathML 元素，我们需要灵活的 CSS 特性集成到现有的 CSS 。最重要的是，现有解决方案可以迭代局部的改进，以确保这些改进促进更广泛的网络布局，而不仅仅是需要一个特定的数学标记语言。

我们不需要一个真正的数学规划方法，我们需要的是创新和灵活性，为开发人员提供的新方法解决布局问题，并在 web 上表达数学思想。

我们需要让 CSSWG / Houdini TF 等等找出解决方案，这能帮助那些开发者实际解决在 web 上的数学问题。

提出一个大概得想法——从一个MathJax的观点出发，现在有三个方面在CSS里很难实现的技术（很可能对普遍的使用数学布局工具网站来说也是一样）：

• 垂直叠加（虽然flexbox可能已经足以修复，CSS的Ruby模块的协同性看着也很有趣）

• 有弹性的字符集和附件（这是一个大问题——但是它们真的仅仅只是一个幻想中的边框）

• 密封的字符边界框（数学布局比大多数形式的文字有更严格的印刷字体的要求，但即使是现有的技术是有问题的）
   

有弹性的东西是迄今为止最大的布局问题，如果仅仅是因为他们曾经Ojan Vafai一样叫数学规划与CSS布局根本不相容的。正如我尊重他的专业知识，这是不可能的答案。这似乎是不可能的，我们不可以逐步减少现有的渲染解决方案的复杂性；在任何情况下，它同MathML没有什么可以做的。

C)我们需要一种新的方法来揭露语义。
 

布局实际上是解决（或至少实现的），我们真的需要解决的语义。Presentation MathML是不够的，内容是不相关的语言。

在我们需要看网页处理语义的今天–ARIA标签和HTML的作用也及其微弱，RDFa（资源描述框架）ARIA是一个迫在眉睫的问题因为它目前关系的数学完全呈现MathML元素（未）而不是在网络提供一种丰富的数学呈现。

我们还需要超越数学的语义，在其应用程序，例如，数学符号的物理（单位等），化学（同位素，反应等）和生物学（树，图等）。我们需要找到方法来揭露这些信息，以辅助技术，搜索和其他工具。