My favorites | Sign in
Project Home Downloads Wiki Issues Code Search
New issue   Search
  Advanced search   Search tips   Subscriptions
Issue 152430: Enabling support for MathML
355 people starred this issue.
Comments by non-members will not trigger notification emails to users who starred this issue.
Back to list
Project Member Reported by, Sep 26, 2012
*High-level description of the change (1-2 sentences):*
MathML is a markup language that can be used inline in HTML documents to give visual appearance to mathematical content. Similar to Latex.

*Listing of additions/modifications/changes to API surface (bullet
- Exposure of all MathML elements and rendering features.

Additional context (fill in as much as you can, or link to a prior API
launch bug with the context):
*Link to relevant webkit or crbug:*
Master bug about MathML:
Bug to enable MathML:

*Link to relevant public standards discussion:*

*Support in other browsers (current and expected):*
Internet Explorer: No support, future unknown.
Firefox: Supported.
Safari: Supported.
Opera: Partial support.

Make sure to fill in any labels with a -?. Feel free to leave other labels
at the defaults.

Oct 17, 2012
(No comment was entered for this change.)
Labels: OS-Windows OS-Linux OS-Mac OS-Chrome
Oct 17, 2012
Anyone wishing to check if this is enabled can simply load:

If the right hand side looks anything like the left, then MathML is enabled. :)
Oct 17, 2012
(No comment was entered for this change.)
Labels: -OS-Windows -OS-Linux -OS-Mac -OS-Chrome OS-All
Oct 25, 2012
 Issue 6606  has been merged into this issue.
Oct 25, 2012
Following up on comment #2 - that page goes straight to AwSnap on Canary.
Oct 25, 2012
There was a mathml crasher yesterday.  I think it should be fixed in tomorrow's Canary.
Oct 25, 2012
That page works fine for me on a Mac. Can someone verify comment 5 on Windows or linux? groby, what is your platform? Can you do "About Chrome" and tell us its build #?
Oct 25, 2012
I also see the same AwSnap page on Canary the very first time I viewed the page and every 3-5 refreshes afterward. 

I am on OS X 10.8.2 and Canary 24.0.1307.0.

The only thing I see in my system.log for Canary looks harmless:
Oct 25 15:59:40 plowsh.local Google Chrome Canary[91620]: -_continuousScroll is deprecated for NSScrollWheel. Please use -hasPreciseScrollingDeltas.
Oct 25 15:59:40 plowsh.local Google Chrome Canary[91620]: -deviceDeltaX is deprecated for NSScrollWheel. Please use -scrollingDeltaX.
Oct 25 15:59:40 plowsh.local Google Chrome Canary[91620]: -deviceDeltaY is deprecated for NSScrollWheel. Please use -scrollingDeltaY.

I'm happy to see work happening on the MathML stuff. If there's anything else I can do to help you debug, please ask.
Oct 25, 2012
Thanks to both of you! It looks like Eric was right as usual, this should be fixed in tomorrow's Canary. Please let us know if not!
Oct 26, 2012
Per David's request, I just checked out today's Canary build (24.0.1308.0) and the same crash is still occurring.
Oct 26, 2012
Tried repeatedly on 24.0.1308.0 (on OSX 10.6.8). Got one crash in about 15 attempts - report ID is 729ab91bccf6f91b
Oct 28, 2012
Thanks again to both (all) of you. The crash report id was very helpful. I'm pretty sure we've fixed this now in webkit r132737, but not in time for Sunday's Chrome Canary 24.0.1310.0 - see <>. After webkit r132737 we'd love any more reports on flaky crashers that our tests don't catch, or bad formatting/layout errors. Chrome 24 freezes early this week for new features, but we can keep adding fixes for MathML for a while because it's new, and we appear to have fixed all the security issues.

Finally, note that this is just a first release. The currently supported tags and attributes are listed at [1] or MDN [2]. mmultiscripts, the operator dictionary, Content MathML, and various stylistic attributes are still missing, for instance. However, you can see MathML's basic speed (though we haven't tuned for that yet), integration with CSS and HTML and JavaScript, etc.

A lot of people have worked very hard to solidify WebKit MathML support so far, and work is continuing. I do believe that in the next few years, literally hundreds of millions of students, scientists, and engineers will want to view mathematics on the web. Along with Firefox and MathJax and others, hopefully we can help make MathML common on the web soon!

Oct 29, 2012
The silly release bots want me to close this.  MathML is on for 24.  We'll deal with any MathML bugs in
Status: Fixed
Dec 12, 2012
We have pulled this on the WebKit branch:

Abhishek or Eric, do we plan to re-launch it in M25?
Max: It's been announced in the blog post, but won't be in M24 stable. Any idea on how we should communicate this? Maybe we should update the blog post with a notice.
Status: Available
Labels: -Mstone-24 Mstone-25
Dec 12, 2012
Yes Peter, we do plan to reenable it in m25. Dave is no longer maintaining MathML and we have Julien opt for atleast fixing many bugs in the mean time [we have atleast 1 security bug open]. We should tell the RM to fix the blog entry.
Dec 12, 2012
Good catch, Peter. Yes, let's update the m24 beta blog post. I'm wondering if we should publish another post when beta hits stable too. I'll explore the best course of action here.
Dec 12, 2012
The situation is not clear cut on whether we will disable it for M24. I requested that we disable it preemptively as one security bug looked like it would take a lot of time to fix and I thought the release was very soon. We have at least one fix on the bug which makes me think we may re-enable it for the release.
I would rather hold on any announcement until next week when we would have a better visibility on the matter.
Dec 12, 2012
Got it. We'll hold off on any announcements until we're sure. Please keep us posted.
Dec 14, 2012
And MathML is saved for M24 ->

Please add some extra thanks to Dave Barton for his awesome job in the release notes.
Labels: -Mstone-25 Mstone-24
Dec 14, 2012
Sweet! Will do.
Status: Fixed
Dec 14, 2012
Personally, I would like to thank original volunteers Alex Milowski and François Sausset, volunteer experts David Carlisle and Frédéric Wang, super reviewers Eric Seidel and Julien Chaffraix, and really the whole WebKit team. For the release notes, I refer you to the links in comment 13 above. Finally, I think in comment 16 "many" should perhaps be "any", at least for security bugs. :) Best wishes, Dave Barton
Dec 20, 2012
Does anyone know if MathML is also going to be enabled in the next release of Android Browser?

BTW, I'd like to mention this related issue that I opened last summer:
Dec 20, 2012
The Android browser is out of scope for the Chromium project.  Chrome for Android, however, will pick up on this feature once it releases a version based on or after Chrome 24.
Jan 10, 2013
Im on Beta 24.0.1312.52 and although it renders certain mathML figures correctly, it doesn't render them all correctly.  Go to and you will see that #2,19, 20, 22 and 28 (kinda) fail.
Jan 10, 2013
Please file specific mathml issues on, ideally with reduced test cases.
Jan 10, 2013
Note that most of the failures in the mozilla torture test page are due to horizontal stretching and mmultiscripts/mprescripts. These  are not implemented at all at present which I think is fine for a first release: they have specific bugs,  bug 72828   and  bug 99618  which were reported by the main developer.
Jan 11, 2013
In order to display math correctly, I hope STIX fonts can be bundled within Chrome, since many OS don't have them by default (and OS X has an older version of it). 
Jan 11, 2013
Well, then open a new bug for it. This here was just about MathML, not all that is necessary for math rendering.
Jan 13, 2013
Concerning math fonts there's now  bug 169662 , another stepping stone for those "literally hundreds of millions of students, scientists, and engineers [that] will want to view mathematics on the web."
Anyone interested please star.
Feb 5, 2013
Note that MathML has had to be turned off because the code is not yet production ready.
We hope to turn it on in some future release. We plan to announce this in the Chrome 25 release notes.

See also:
Status: Available
Owner: ---
Labels: -Mstone-24 Mstone-X
Feb 5, 2013
@meh Will there be a chrome flag for the more adventurous?
Feb 6, 2013
Checked in the latest Chromium Canary on Windows, couldn't find a flag that
would enable MathML. Tried by enabling WebKit experimental flag, but MathML
wasn't working.

Will there be a flag added?
Feb 6, 2013
Unfortunately MathML was implemented in WebKit as a build-time flag only (#ifdef). There is no runtime flag for MathML at the moment but adding one is a good idea if you want to file a bug about it.
Feb 6, 2013
It would be a major step backwards to drop support for Math ML.  It needs to be there!
Feb 6, 2013
Huh, MathML going AWAY in Chrome? Sounds like a bad idea.
What is the trade-off here?
Feb 6, 2013
#32: "not production ready"?  It's not yet perfect, mainly because things like mmultiscripts are not presently handled, but it's good enough to stay there.  Without it Chrome will totally fail on some current text/html content.  Taking it out would be a giant step backward. It deserves to have somebody paid to maintain and improve it.
Feb 6, 2013
In fact, I now see that MathML support is gone in the Ubuntu package google-chrome-beta.  Just so that everyone understands the mess that has been created by this regression, I'm attaching a screenshot.
82.8 KB   View   Download
Feb 6, 2013
To summarize the current status of this bug: We'd like to enable MathML in Chrome, but the WebKit code still needs further improvements before we can ship it.

Closing this bug to "me too" comments.  If you'd like to contact a Chromium project member about this, especially if you're a developer interested in working on improving the code, feel free to email me directly.
Labels: Restrict-AddIssueComment-EditIssue
Feb 19, 2013
 Issue 176698  has been merged into this issue.
Mar 9, 2013
(No comment was entered for this change.)
Labels: -OWP-DesignReview-No OWP-Design-No
Oct 29, 2013
comment #40 is out of date. MathML is not something that we want at this time. We believe the needs of MathML can be sufficiently met by libraries like MathJax and doesn't need to be more directly supported by the platform. In areas where libraries like MathJax are not good enough, we'd love to hear feedback about what APIs we would need to expose so that MathJax, et al, can create an awesome MathML implementation.
Oct 29, 2013
(No comment was entered for this change.)
Labels: -Restrict-AddIssueComment-EditIssue
Oct 29, 2013
The problem with MathJax and other JavaScript libraries is the JavaScript part. It’s not fun to have page reflows on a slow connection, and not everybody necessarily has JavaScript enabled besides.
Oct 29, 2013
It is not only the speed issue that make JavaScript far less than an ideal solution. In page JavaScript references do not stay with the content so for example snippets of a MathJax enabled blog as shown in Google+ fail to render as will any other use of document fragments.
Oct 29, 2013
// I do wonder how you changed your mind so radically in 9 months.
Oct 29, 2013
We run a large academic journal site which includes occasional math. The challenge for us with MathJax is that we either: (1) include math on every page on our site, or (2) build a math detector that includes MathJax only when we need it.  Neither solution is completely ideal.  We're going with (1), but it does mean extra javascript downloads and processing on all our pages, even though most don't actually have math on them.  Caching helps, of course, but first-page views for every user are affected.
Oct 29, 2013
I'm *really* disappointed to hear this. MathJax isn't a good solution for a number of reasons.  First, as noted above, it's slow.  In a math heavy page, it can take some time for everything to be rendered.  Second, MathJax, including the required fonts, is a huge dependency that needs to be communicated over the net.  Third, if you want to view a page that includes math when you're offline, you're out of luck.  It is true that MathML is not pleasant to write, but that's not a big issue, since there are good tools for converting TeX math to MathML. TeX inside HTML is problematic anyway, because of differences in escaping rules.  This is really a big issue for those who hope to use HTML for serious academic writing.

Oct 29, 2013
I really don't understand the reasoning of the Chrome dev team. Clearly we are very far from purist reasoning - in the end of the day MathML is part of the HTML5 specification and should hence be supported by any HTML5-capable browser. And it's not like MathML is "defective by design" and gives you no choice but to abandon it - adoption is way up with Firefox and MathJaX support and the new introduction to EPUB3.

Practical circumstances can motivate delaying Chrome support, or motivate providing it incrementally in an ongoing development effort. But practical arguments such as "a javascript library exists that renders parts of the MathML specification as CSS", can not motivate entirely abandoning Chrome support for MathML.

After all, MathJaX does not come bundled with Chrome and MathML-enabled pages that do not explicitly load MathJaX continue to remain broken for Chrome users (while still valid (X)HTML5). If you are claiming that the Chrome team intends to activate MathJaX on all web pages instead of native MathML support, that would be a more understandable, yet still rather silly, course of action.

Declaring that Chrome shouldn't support MathML because you could in principle find a JavaScript library instead, is not in any way a meaningful justification (why bother implementing any of HTML5? You could just let some JavaScript library render your SVG via CSS or compile it down to a PNG, and so forth for the other features that don't need security considerations).

Chrome goes out of its way to provide a native PDF-viewer. At the same time, the ISO 32000-2 specification is expected to have support for MathML tagging of formulas in PDF documents. Math publishing is moving forward with MathML as its foundation. The reluctance for Chrome MathML support keeps striking me as counter-intuitive.
Oct 29, 2013
Use SVG only for MathJax and you should see significant speed improvements.

MathML in Chrome would be nice, but I hardly see it as necessary. I don't condone their position, but I don't think it needs to be priority either.
Oct 29, 2013
MathJax renders SVGs much slower than it does HTML + CSS for me in Firefox.
Oct 29, 2013
If Mathjax is a better alternative than MathMl, then may be the Mathjax js, fonts and other dependencies of Mathjax should be included with chrome to minimize load times and make it more efficient.
Oct 29, 2013
Only that it is not a better alternative, as the good folks at MathJax publically state....

To quote Henri Sivonen:

> It's valuable to be able to publish math on the Web in a way that:
>  1) does not require sending a JS-based renderer along with the data
>  2) participates in line-breaking and reflow
> 3) integrates with the patterns of the platform (DOM, Selectors)
> 4) can be copied and pasted as math (as opposed to an image)
>  5) already works in 2 out of the 4 major Web engines [...]

I personally would add
6) that enable rich, math-specific interactions that make math alive and turn math documents into math-aware applications analogously to gmail google docs for regular documents.

These are not or only partially supported by MathJax.

I guess we have to ask ourselves what the reasons for leaving out native MathML support in chrome, and the only argument that I see holds any water is "Math is not a market for us". This I see as a legitimate argument, but I think with the increasing adoption of MathML in EPUB3, in Math Websites,  blogs, ... which is made possible by the transition technology MathJax, I believe that this is a rather short-sighted argument. I for one do not make chrome my default browser the for one reason that it is deficient on MathML support, and the slowdown of using MathJax outweighs the speed increases I get from faster JS support in chrome. I guess that we will see this more in the future.
> then may be the Mathjax js, fonts and other dependencies of Mathjax should be included with chrome to minimize load times and make it more efficient.
Indeed, if chome buys into the argument "Math is not a market" then shipping MathJax as a part of chrome is the best stop-gap.

Oct 30, 2013
#46, I don't think the nay-saying protagonist in that other discussion has come anywhere near making his case.
Oct 30, 2013
I think it would be good to ask the MathJax developers about that. I think they would be able to fix this bug without integrating MathJax to chrome. 
Oct 30, 2013
Ironically, on the MathJax mailing list, we've recently been discussing a problem with MathJax in Chrome that causes some pages to consistently fail in rendering the math.  Davide Cervone, the author of MathJax, narrowed things down to cases where an object returns itself when a property is accessed (instead of the value of the property) in certain situations:!topic/mathjax-users/CWGx1koV3SU
Oct 30, 2013
First, thanks for opening comments again on this issue. It is in the top 30 by votes and it seems reasonable to listen users rather than just ignoring any feedback.

I'm not sure why people are surprised by this statement since this was the position Ojan gave on his blog after MathML was disabled. And I still continue to interpret the "at this time" as "we do not plan to support native MathML any time soon and we prefer to rely exclusively on MathJax for now" that is they will reconsider that decision in the very long term. Or perhaps I'm wrong and Chrome people just do not want to support MathML natively at all in the future? (MathJax integrated in Chrome as Web Components or something is *not* native support and has essentially the same issues)

The only difference since February is that Google's "security concerns" have been fixed in WebKit and so this argument to refuse MathML is no longer valid. However, Ojan's statement on his blog that WebKit's MathML rendering is not good enough compared to MathJax is still valid. Actually, I was surprised when Peter Kasting commented on my blog that they would accept a patch to re-land WebKit MathML now that the "security concerns" are fixed.

Here is how I personally see the future:

* Moritz Schubotz and others have recently done a great job to integrate MathJax server-side in Wikipedia. This will soon provide alternative options for anonymous users like SVG rendering (same as the old raw image but with better rendering quality) or native MathML rendering for browsers that support it. Once MathJax 2.3 is released, I will help Moritz to finish a better integration of MathJax client-side (for example to get HTML-CSS rendering or extended user interface) although this option will still be much slower. This will show a concrete example where native MathML is a big advantage and will contradict the fallacious argument that "native MathML is not used on large Website so not worth implementing". 

* After that, I'll try to find funds to spend more time on native MathML developments (Gecko and WebKit). I'm aware that there is a lot of work to do on WebKit MathML that can not be done by volunteers or part-time developers only. However there are core WebKit developers interested in helping and I wish other people could provide (not necessarily technical) support too. I'll give more info about that next month.

* In the long term, once WebKit has reached a decent MathML quality and/or when we have a professional organization for native MathML developments, then we might consider maintaining a fork of Chrome with MathML support: To be honest, I think at the moment it is best for Chrome users to just switch to Firefox (with the appropriate math fonts installed).

* In a very very long term, Chromium developers might change their mind and integrate WebKit MathML back in Chrome (and drop MathJax-in-Chrome if they tried that in the meantime)
Oct 30, 2013
this sucks.
Oct 30, 2013
In 2010 I gave a talk, where I wanted to mention, that Firefox and Opera have MathML support, and only WebKit browsers lacked it (Trident doesn’t count here). Right before the talk WebKit contributor Nikolas Zimmermann pointed me to the changeset, that _enabled_ it in WebKit and the crowd went Yay!

And now, three years later, that not only you just don't switch the flip to enable it, but also drag Opera with you in not supporting maths on the web? That’s a crappy move.

Opera devs: You had decent MathML rendering. Pour that knowledge in Blink, please?
Oct 30, 2013
#62 beni.cherniavsky
A use case that particularly suffers from lack of MathML is email :-(
How do you send somebody an email with formulas such that he can see them nicely?

 * Linking MathJax is out since email clients block javascript (even if they didn't,
   offline reading is desired and embedding all of MathJax is out of the question).

 * Representing math with images is has quality and size mismatch issues; SVG is 
   the only hope.  But email clients tend to hide images by default, and SVG support
   is particularly spotty.

 * Sender-side conversion to HTML+CSS is possible, and perhaps the best option now.
   But it cannot achieve good quality across readers — the reason MathJax needs
   to run on the client is that placement & sizing must be adjusted to specific

In the long term, the only sane approach is MathML.  It's passive, safe (bugs aside), fast and can be rendered offline.
If most browsers would support MathML, it would be easy to allow it in webmail clients, which I hope would then encourage desktop clients to support it.

(It's true that webmail sites could skip ahead and use MathJax now, but that's unlikely.  Would e.g. Gmail team accept the extra weight — and security review surface — to support a part of html that isn't even well supported by Chrome?)


BTW, security is another reason this is sad.
Sites may be loath to execute mathjax on all their pages (at least without a security evaluation).  E.g. Github wikis used mathjax, but later disabled them "due to security concerns" [].

In the grand scheme of things it seems better to securely implement MathML in browsers vs every site having to trust a huge JS library.
Oct 30, 2013
I am *very* disappointed when I read #43.

Math is THE universal language, understood by every nation on this world and used to describe and analyse our world in physics, chemistry, biology and even economics.

Let me compare the situation to hypothetical one:
In my native language, german, we have 'Umlaute': ä ö ü.
Two main browers included them already in their charset. All others still have to read something like \ae \oe \ue in their browser. To avoid this, some clever folks have come with a program, that searches for every \ae an replaces it with a tiny image of 'ä' and so on. This only works when being online.

And now the suggestion is: No, we don`t implement the 'Umlaute', as the standard suggests, we make the replacement program faster. NO WAY!
Oct 30, 2013
Being a student of Math and a fan of Chromium/Chrome it breaks my heart
that the two cannot come together :(.
Oct 30, 2013
Dear all

I think it is a mistake Google to turn its back to scientific community.

Google is here leaving its roots.

This will hurt the Chrome OS strategy toward education institutions.

It should send a very negative message to so many "sponsors" of Google.

My advice is that this decision has to go to the board and to Mister Sundar Pichai.

All the best

Oct 30, 2013
I agree with the comments above. 

Math is the centerpiece of everything. All major innovations: Physics, Biology, Computer Science, Economics etc. use Math as the universal language. Its important that browsers understand Math natively rather than some through some JavaScript shim like MathJax. Just like search engines and machine learning programs understand words today, they will understand math in the future. For pervasive support of math around us, our browsers should be able to display math natively rather than go through hoops and use an external library.

For heavens sake Chrome supports PDF, Unicode out of the box. Wouldn't seeing math equations without using an external library be appropriate?

Oct 30, 2013
One serious problem I have with mathJax is integrating it in a wysiwyg editor like TinyMCE. I don't mean wysiwyg-editing the formula, just being able to show it in the editor window and e.g. click on it to edit it's code. The issue is - mathJax is terribly hacky, changing a lot of DOM. So you have to call mathJax outside the editor window in an invisible placeholder and move it - this unfortunately also breaks loads of stuff and noone has been able to create a plugin for an apparently very simple functionality. All working solutions I know load server-generated images instead. Googling tinymce+mathjax gives you mostly questions and some very buggy, unusable solutions - a lot of people have tried and failed, it's a common use case.

In general, using mathJax for anything other than displaying static math in well-defined, fixed environments is incredibly hard. Maybe a solution using mathJax inside the browser would be enough (so there's no DOM changing from the user's point of view and no issues with loading mathjax).
Oct 30, 2013
#68 johanneswilm
@commenter 67: Try . We have it working in a contenteditable view without resorting to images. And we are open source (AGPL). However, we need to intercept the caret to make sure it goes the right place -- something like 1100 lines just for Chomr. Firefox would require something of similar length. Feel free to study our sourcecode. Also feel free to contact us there or writing to the email list of you have more questions.
Oct 30, 2013
I should clarify that the MathML security issues were never resolved. We stopped filing new issues because we disabled that code and thus were no longer testing it. However, it was clear that our fuzzers would have continued to regularly identify new security vulnerabilities.

From the security perspective, there were simply more fundamental issues in the design and implementation. And there was no one who could commit to the larger refactoring and ongoing bug fixes that would be needed to stabilize the feature. Had we kept it, we would have been left with known dangerous code that had no reliable owners and no clear path to getting it fixed.

Oct 30, 2013
> I should clarify that the MathML security issues were never resolved. We stopped filing new issues because we disabled that code and thus were no longer testing it. However, it was clear that our fuzzers would have continued to regularly identify new security vulnerabilities. From the security perspective, there were simply more fundamental issues in the design and implementation. And there was no one who could commit to the larger refactoring and ongoing bug fixes that would be needed to stabilize the feature. Had we kept it, we would have been left with known dangerous code that had no reliable owners and no clear path to getting it fixed.

This seems pure speculation, given that these issues have been addressed by disabling MathML in Chrome and no one can tell for sure what would have happened otherwise. So I'd prefer to discuss about what is really certain: all the MathML security bugs reported by Google that I'm aware of I've been fixed in WebKit now. Certainly there are other design problems in the MathML code but that's a separate issue. When I mentioned MathJax Consortium's plan to dedicate a bit of resource to help MathML in WebKit, Chromium developers ignored my comment and just dropped the MathML code from Chrome. And when I asked on the WebKit bug entry to tell me what were exactly the vulnerabilities and/or to give test cases, none of the Chrome developers ever replied. So I think you should stop with the security argument ; it certainly made sense when you took the decision to disable MathML but at that point that's totally irrelevant. That said, I agree that WebKit MathML needs improvements and that you are free to decide what your priorities are. And users are free to complain or to switch to a better browser.
Oct 30, 2013
I have an application where math content is, for various reasons, rendered on the fly in a set of columns within an iframe.

With a few hours of experimentation, I was unable to get MathJax working correctly in this context (though I have successfully gotten it working in more standard contexts). Given the my time constraints, I ended up rendering my equations as images and moving on to my next issue.

This was a painful choice that resulted in an inferior solution. If Chrome supported MathML, I wouldn't have had to spend any time on the issue and would have obtained a superior result.

Do I like the MathML syntax? No, it is ugly and much too verbose. Nevertheless, it is a standard with fairly wide adoption; Chrome should support it.

Oct 30, 2013
MathML is positioned for good adoption as the defacto standard going forward and reading the original comment, I think we are all in agreement that a MathML processor/renderer is the right way forward. Completely understand the need to cut extraneous or superfluous features but math is fundementel  ... MathML is something that should be supported, pls reconsider carefully how Chrome may support it.
Oct 30, 2013
Would it be possible to implement MathML behind a command line flag that is disabled by default?

Then only those who know what they are doing will enable it.

I have filed  bug #174852  about it.
Oct 30, 2013
#69, given that the "security issues" you mention are unidentified in this discussion, might you at least indicate what is the category of security issue involved.  For example, are you saying that the native MathML support opens a door to writing in the file system of the platform where Chrome is running?  Is there a concern that the native MathML support might put Chrome in an infinite loop or cause Chrome to crash?  Is it worse than the feature of putting out "e=mc2" for a perfectly valid piece of html5 equivalent to "e=mc^2" in TeX?
Oct 30, 2013
For better overview I created a pro-cons list, which anyone can edit:

I'm mostly interested in MathML for a CEF (Chrome Embedded Framework) application.
Oct 30, 2013
#76 - There was no speculation on my part. I'm stating facts that are apparent with a reasonable understanding of WebKit/Blink's architecture and the nature of security vulnerabilities that can occur (e.g. The MathML code had fundamental architectural issues (e.g. modifying the render tree during layout) that are guaranteed to introduce security vulnerabilities. Until those underlying issues were fixed, our fuzzing infrastructure was just going to continue identifying new triggers for the vulnerabilities.

Assuming that those issues were resolved, there was still the concern of ongoing ownership. New vulnerabilities will be found in code of any complexity over time, either because code around it changes enough to introduce new bugs or simply that our understanding and detection methods improve such that we unearth new instances or whole new classes of vulnerabilities. That's why we don't ship code in Chrome unless we have an owner who is responsible for its long term viability. Anything less would be grossly irresponsible.

With respect to past offers of engineering assistance, the relevant bugs are restricted to protect browsers shipping the vulnerable code. However, any of the engineers working on MathML could have given you access, so I would suggest approaching them directly. Although, fixing the issues would require a significant time investment and deep knowledge of WebKit/Blink layout and rendering. To put it in context, several engineering weeks had already been spent trying to resolve the security issues before we were forced to disable the code.

Beyond that, I can't speak to why the Blink project isn't currently interested in supporting MathML (because I honestly don't know). I can only provide the facts I have regarding the very real security issues.

Oct 30, 2013
#77 beni.cherniavsky
Could you please clarify where you stand between "it's not a priority for us but we'd accept contributions of _sufficient_ quality" to "we don't want Chrome to support it, ever"?

#69 sounds like the former, understandable, but #43 came across kinda like the latter, which is a harsh position to take.
Oct 30, 2013
#76, You wrote: "The MathML code had fundamental architectural issues (e.g. modifying the render tree during layout) that are guaranteed to introduce security 

I've not seen the code. But...

We're talking about code that ships with the browser, not something like imported javascript.  The code is there for the purpose of rendering the contents inside <math> elements.  So, for example, where the markup is
"<mrow><mi>e</mi><mo>=</mo><mi>m</mi><msup><mi>c</mi><mn>2</mn></msup></mrow>", and the rendering is now coming out as "e=mc2" (all mathml elements ignored), are you saying it's a security issue that the plain rendering of cdata is modified?  Surely you must mean something else.  Could you clarify.  For example, is the code writing in dangerous ways outside of the area of the <math> element?
Oct 30, 2013
(No comment was entered for this change.)
Oct 30, 2013
@gellmu - The gist is that WebKit/Blink assumes certain invariants in how major data structures are managed in memory. As an example, one of the invariants violated by MathML is that the render tree should not be modified during the layout phase. This invariant is necessary because various components in layout store pointers to objects in the render tree, and if the tree is modified during layout those pointers can wind up referencing invalid memory locations. Typically this results in a condition known as a dangling/stale pointer vulnerability (aka. use-after-free) <>.

Stale pointer vulnerabilities are generally rated as high-severity on Chrome's scale <>. A properly built exploit of one of these vulnerabilities would allow an attacker to execute arbitrary code inside the renderer process, bypass all origin-based security restrictions, and perform escalation attacks to potentially break out of Chrome's sandbox. In an unsandboxed Chromium-based browser, the exploit would simply be able to execute arbitrary code at the full privilege of the user launching the browser.

Oct 31, 2013
@jschuh: Thanks. I am aware about the issues and agree that this made sense from a security point of view. However, we are talking about different things: you are still trying to argue about decisions that took place several months ago when you disabled MathML and you are mentioning things that could potentially have happened, overlooking the work on WebKit side since you created the Blink fork. The point here is that comment 43 says this reasoning is out of date and that a native MathML implementation is not desired by Google ; this contrasts with the official position so far that was "if a volunteer does the job to fix the issues, we might enable MathML again". Since April, I've worked a bit with Martin Robinson to fix bugs in WebKit. The two main design issues with potential stale pointer vulnerabilities, namely preferred widths depend on layout information ( and others) and render tree is modified during layout ( and others) as well as one hang that could not be found by a "mixing small DOM trees" fuzzer only (similar to have all be fixed so far. So looking to the future rather than backward, the point is how to find someone who can ensure maintenance and development of the MathML code since using volunteers as "owners" just does not seem reliable or efficient for a core feature of the layout engine. Also, given that I'm now familiar with WebKit and that a couple of WebKit engineers are interested to help improving MathML, the ideal approach is to to continue the work on WebKit and perhaps import it back later in Chromium ; rather than trying to convince Google engineers to invest seriously on native MathML...

Oct 31, 2013
As Fred has said more than once, the security issue is no longer present, so I don't know why that keeps coming up.

The question that has been obliquely raised but never answered by the Chrome team is: why don't you hire someone to work on MathML so that someone does own the code and can fix problems when they come up? 

Clearly the Chrome team feels SVG is enough of a priority to hire more than one developer to work on it. Why isn't supporting math education in schools by providing a good math browsing experience a priority? Waiting 3-5 times longer than a native implementation (which for a Wikipedia page can be over 10 seconds delay) falls far short of providing an awesomely good experience. Nor do the other problems that people have pointed out with a JS solution provide an awesomely good experience.

Comments like "We believe the needs of MathML can be sufficiently met by libraries like MathJax" show a lack of understanding of what the needs of the math community and math education are. I hope that someday someone in on the Chrome team spends the time to understand what those needs are and addresses them so that innovative math solutions can be part of Chrome.
Oct 31, 2013
Students are impatient, even at the undergraduate college level.  It is important for math to be fully on the same playing field as classical html.
Nov 2, 2013
I'm extremely disappointed to hear this. Researchers, educators and students have been waiting for a decent way to communicate on the web about technical topics for the better part of twenty years. MathML provides that.

Can we please prioritize a feature that actually has, you know, an actual social benefit?
Nov 4, 2013
Blog post snippets included in other places than the blog itself is a fair point of something lost by providing MathML through a JS-library. Although, if such a thing became sufficiently popular, you could imagine key sites like Google search results starting to include a MathML rendering library when the snippet included MathML.

The "at this time" bit in my earlier comment was mainly that I'm not saying we'll definitely never implement MathML. If we were the only browser left that didn't implement it, and there were sufficient web content that used MathML, that would certainly change the trade-offs involved. It's admittedly a chicken and egg problem.

Right now performance is our number one priority, not features. Incidentally, the SVG comparison is a good example. We, in fact, do not have even one full-time engineer working on SVG and almost all the SVG work that we've done has been around security and crash fixes. In the chicken and egg equation, there's considerably more SVG content than MathML (by a couple orders of magnitude at least).
Nov 6, 2013
#85 -- Re: "considerably more SVG content than MathML"  How are you making
this determination?  For example, are you seeing the mathml served in
application/xml+xhtml ?
Are you counting math served via mathjax (which depends on MathML though
not on native MathML rendering)?  Is the measure of svg limited to svg
markup in html (and xhtml) or does it also include imported svg objects?

There's a huge amount of math online as PDF not yet in html+mathml because
of the chicken and egg issue.  When I last checked (January of this year),
there was no html+mathml at the Los Alamos/Cornell arXiv (
(There was a big project "arXMLiv" devoted to translating the arXiv to html
with mathml -- )

Do we want our children to grow up with the impression that math is not
important enough to be in web pages?

William F Hammond
Nov 6, 2013
Re #85:

> Right now performance is our number one priority, not features.

Viewing (mentioned in, On my machine, Chrome takes 5'30" to display all the math, 4'45" after caching. The same page with native Firefox rendering takes 25". That's an order of magnitude slower in Chrome. The multiplier would be greater if the page didn't have to be served by MathJax, as 10-15 seconds is MathJax scanning the page. So Chrome is a dog for pages that use math. You can switch to using SVG. SVG is much faster in Chrome (45"), but the quality of display drops significantly and the math doesn't match the text well.

> (MathML content)
As for math content on the web... Typical markdown for math in a page uses TeX. MathJax turns this into something like MathML internally for rendering. If there is a native renderer available, MathJax will put MathML into the page. So you should be looking at instances of TeX and MathML if you want to consider the importance of MathML content. MathJax had over 55 million unique visitors a month last spring and has probably grown to over 60 million unique visitors per month in the fall. If those people all used Chrome, that would be 60 million people slowed down by Chrome's lack of native MathML support.
Nov 13, 2013
Re #85:
> Right now performance is our number one priority, not features.

Math in Wikipedia articles looks horrible on mobile, because it's rendered as images and scaled improperly, especially for inline math. However, if I switch to using MathJax for rendering it is possible to read the math, but it takes forever to actually show it. This is not what I call great performance.

I can't believe native MathML has so low priority.
Nov 13, 2013
> Although, if such a thing became sufficiently popular, you could imagine key sites like Google search results starting to include a MathML rendering library when the snippet included MathML.

> Math in Wikipedia articles looks horrible on mobile, because it's rendered as images and scaled improperly, especially for inline math. However, if I switch to using MathJax for rendering it is possible to read the math, but it takes forever to actually show it. This is not what I call great performance.

The experience with MediaWiki people to integrate MathJax was quite instructing about how maintainers of large web sites could react. Although a MediaWiki volunteer has done MathJax client-side rendering for a long time, the MediaWiki have not been quite exciting to make that option the default.

See for example for the point of view of one MediaWiki developer.

The solution that Moritz and others have recently worked on is to use server-side TeX-to-MathML and MathML-to-SVG conversions via MathJax+phantomjs ; and this can of course be cached in their data base. So e.g. browsers like Gecko will directly render the MathML and others will use the SVG fallback. This will solve some of the performance and rendering issues perceived by users in future versions of MediaWiki. 

However that makes the server-side code overly complex and we have to produce and store additional and larger images in the data base, just to work around the lack of native MathML support in browsers that don't support HTML5 very well. I'm really skeptic about the fact that popular sites like Google search results would include the Javascript snippet for MathJax or are likely to rely on complex backend converters.
Nov 13, 2013
In #86 I said: "When I last checked (January of this year), there was no html+mathml at the Los Alamos/Cornell arXiv ("

Since I said that, I have learned that arXiv has begun using html+mathml in the abstracts of its articles around mid October (2013).
Dec 2, 2013
I have opened an issue to implement MathML image & text fallback:

This will be helpful for some web sites like MDN or Wikipedia. BTW, I have also launched a crowd funding campaign for MathML, as mentioned above:

This will include improving MathML in WebKit and so might be imported in Blink later. Perhaps I may find time to build Chromium again and try to work on the image/text fallback issue if Chromium developers don't do that in the short term ; but I can't promise ; my priority is on WebKit/Gecko, right now.
Jan 12, 2014
Just as a back-up of the pros vs cons list people contributed to...

Pros of native MathML implementation:

* It's part of HTML5
* Support for line-breaking in MathML, especially dynamic line breaking as the size of the window or content changes (MathJax doesn't change line breaking when content size changes, and will likely never be able to do line-breaking on inline math).
* Ability to modify/query MathML DOM elements as with any other content (this is difficult in MathJax).
* Full integration with CSS (MathJax doesn't do this well).
* Semantic Math, not just an emulation of what it should look like visually.
* Copyable MathML (where the clipboard knows that the data is MathML and therefore can be seamlessly copied/pasted to/from applications like MS Word or Mathematica).
* Math in e-mails?
* JS does not need to be enabled.
* Faster rendering than with JS.
* Integrate math support with no effort on website/webapp.
* No extra downloading for JS library (mostly useful on first load).
* Hassle-free offline support.

Cons of native MathML implementation:

* Existing codebase may have security issues.
* Can be implemented using 3rd party JS libraries like MathJax.
* Adds more code and complication to already existing browser source code.
Jan 12, 2014
I opened issue #1748952 upon suggestion to enable support for MathML behind a runtime flag, but I was not able to post a comment on the previous issue because commenting was locked.
Apr 15, 2014
Implementation may be as easy as adding an agent stylesheet. Here's a small proof-of-concept I wrote up in CSS3:
Apr 15, 2014
> Implementation may be as easy as adding an agent stylesheet. Here's a small proof-of-concept I wrote up in CSS3:

That was already experimented in Opera Presto and I have another version here that will be used on MDN: However, I don't think you can reach high rendering quality with only CSS stylesheet. Given that one of Google's excuse to remove MathML support was the low-level quality of the C++ implementation (which was already much better than Opera's CSS one), that's really unlikely to be accepted.

Moreover, I already added a basic UA stylesheet to handle alternate content ( but Blink has some restrictions for UA stylesheets (e.g. universal rules or sibling selectors are forbidden).
Apr 15, 2014

That stylesheet looks ok - I would say that something is better than
nothing :)

Is it possible to edit my own personal user agent stylesheet so that I can
add that CSS?
Apr 15, 2014
Re #95, Tue, Apr 15, 2014

(Did the Opera experiment use CSS3?  I don't think I saw that.)

Indeed, Fred's mathml.css shows that going  to CSS3 helps quite a bit more
than CSS2.  Nice job!

This would seem to give one reason to believe that ultimately native MathML
handling can be faster than we have so far known it by relying on the
increasingly more powerful versions of CSS in conjunction with the native

Also it would be good if the cascade in CSS were factored into the native
rendering so that style sheets of this type would not clash with native
rendering in the way that we see now.

          -- Bill
Aug 10, 2014
How exactly is Chromium "An open-source project to help move the web forward" without MathML? It is an HTML5 standard.

Does Chromium have a contingency plan to support mathematical formulae hyperlinking? If Wikipedia implements it people might well drop Chromium/Chrome and go to a professional browser that supports it.
Sep 15, 2014
Here is an eager bump to this really important and high profile issue.

While Chrome and IE refuse to invest in MathML, we now have MathJaX competitors springing to life. KaTeX just started trending:

It is essentially a lightweight MathJaX clone which focuses on rendering the mathematics as quickly as possible, in order to provide better performance for math-heavy pages.

Yes, high performance is now one of the big issues being tackled. And, as mentioned earlier in this thread, that is the one obvious aspect where a native browser implementation of MathML rendering would win hands down and would offer math practitioners (from primary school students to Fields medal winners) a high quality experience.
Sep 15, 2014
I think mediawiki is going to have support for MATHML in it's visual editor
sometime soon too - I read this on their weekly tech news a few weeks ago.
Oct 15, 2014
(No comment was entered for this change.)
Oct 27 (2 days ago)
As a end user, this is frustrating to me. My university websites renders either images or MathML. The images is low resolution to save on bandwidth so clarity can be questionable. MathML does not suffer the same fate but only works on Firefox which means I have to change browsers every time I want to view a MathML site. 
Oct 28 (44 hours ago)
MathML is now official part of the HTML5 Recommendation. And so reliance on MathJax and it's shim ilk should no longer be the preferential choice, except for interoperability on older, not modern, browsers. (HTML5 4.7.14)
Sign in to add a comment

Powered by Google Project Hosting