New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 476 users

Comments by non-members will not trigger notification emails to users who starred this issue.

Issue metadata

Status: WontFix
Owner: ----
Closed: Dec 2016
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Launch-OWP
Launch-Accessibility: NotReviewed
Launch-Exp-Leadership: ----
Launch-Leadership: ----
Launch-Legal: NotReviewed
Launch-M-Approved: ----
Launch-M-Target: ----
Launch-Privacy: NotReviewed
Launch-Security: NotReviewed
Launch-Test: NotReviewed
Launch-UI: NotReviewed

issue 594157

Sign in to add a comment

Issue 152430: Enabling support for MathML

Reported by, Sep 26 2012 Project Member

Issue description

*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.
Showing comments 31 - 130 of 130 Older

Comment 31 by, 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.

Comment 32 by, Feb 6 2013

Labels: -Mstone-24 Mstone-X
Owner: ----
Status: Available
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:

Comment 33 by, Feb 6 2013

@meh Will there be a chrome flag for the more adventurous?

Comment 34 by, 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?

Comment 35 by, 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.

Comment 36 by Deleted ...@, Feb 6 2013

It would be a major step backwards to drop support for Math ML.  It needs to be there!

Comment 37 by Deleted ...@, Feb 6 2013

Huh, MathML going AWAY in Chrome? Sounds like a bad idea.
What is the trade-off here?

Comment 38 by, 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.

Comment 39 by, 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

Comment 40 by, Feb 6 2013

Labels: Restrict-AddIssueComment-EditIssue
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.

Comment 41 by, Feb 19 2013

 Issue 176698  has been merged into this issue.

Comment 42 by, Mar 9 2013

Project Member
Labels: -OWP-DesignReview-No OWP-Design-No

Comment 43 by, 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.

Comment 44 by, Oct 30 2013

Labels: -Restrict-AddIssueComment-EditIssue

Comment 45 by, Oct 30 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.

Comment 46 by, Oct 30 2013

Comment 47 by, Oct 30 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.

Comment 48 by, Oct 30 2013

// I do wonder how you changed your mind so radically in 9 months.

Comment 49 by Deleted ...@, Oct 30 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.

Comment 50 by, Oct 30 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.

Comment 51 by, Oct 30 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.

Comment 52 by, Oct 30 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.

Comment 53 by, Oct 30 2013

MathJax renders SVGs much slower than it does HTML + CSS for me in Firefox.

Comment 54 by Deleted ...@, Oct 30 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.

Comment 55 by, Oct 30 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.

Comment 56 by, Oct 30 2013

#46, I don't think the nay-saying protagonist in that other discussion has come anywhere near making his case.

Comment 57 by, 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.

Comment 58 by, 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

Comment 59 by, 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)

Comment 60 by, Oct 30 2013

this sucks.

Comment 61 by, 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?

Comment 62 by, Oct 30 2013

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.

Comment 63 by, 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!

Comment 64 by, Oct 30 2013

Being a student of Math and a fan of Chromium/Chrome it breaks my heart
that the two cannot come together :(.

Comment 65 by, 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

Comment 66 by, 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?

Comment 67 by, 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).

Comment 68 by, Oct 30 2013

@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.

Comment 69 by, 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.

Comment 70 by, 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.

Comment 71 by, 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.

Comment 72 by Deleted ...@, 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.

Comment 73 by, 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.

Comment 74 by, 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?

Comment 75 by, 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.

Comment 76 by, Oct 30 2013 - 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.

Comment 77 by, Oct 30 2013

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.

Comment 78 by, Oct 31 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?

Comment 79 by, Oct 31 2013


Comment 80 by, Oct 31 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.

Comment 81 by, 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...

Comment 82 by, 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.

Comment 83 by, 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.

Comment 84 by, 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?

Comment 85 by, Nov 5 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).

Comment 86 by, 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

Comment 87 by, Nov 7 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.

Comment 88 by, 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.

Comment 89 by, 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.

Comment 90 by, 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).

Comment 91 by, 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.

Comment 92 by, 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.

Comment 93 by, Jan 13 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.

Comment 94 by, 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:

Comment 95 by, 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).

Comment 96 by, 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?

Comment 97 by, 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

Comment 98 by Deleted ...@, Aug 11 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.

Comment 99 by, 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.

Comment 100 by, Sep 16 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.

Comment 101 Deleted

Comment 102 by, Oct 27 2014

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.

Comment 103 by, Oct 28 2014

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)

Comment 104 by Deleted ...@, Dec 18 2014

I've written a C library years ago that can render a subset of MathML. I've since abandoned it due to lack of interest from users. You can see the screenshots here:

Please provide some feedback regarding the quality of the rendering.

If Google is interested to adopt it, I'm willing to continue improving it, including support for OpenType Math Tables.

Comment 105 by, Jun 1 2015

It Would Be Great If Google Chrome Supported MathML

Comment 106 by, Jun 23 2015

MathML is now an ISO/IEC standard:

Time to get to the 21st century Google!

Comment 107 by, Oct 2 2015

As a former educator and a data scientist who writes documentation for the web, Chrome's lack of support for MathML is simply unbelievable. It's been a standard for over a decade and has been ISO/IEC standard for 3 months. Firefox/Safari/Opera all have supported MathML for years.

Chrome is the same camp as IE. IE! Google, do you really want your browser to be the next IE6 of the web? A ubiquitous, problematic browser that forces developers to add shims and workarounds?

MathML may not be an issue of concern to the general web-viewing public, but to those of us who use it daily, the Chrome team's indifference is a black eye to Google's brand.

Comment 108 by, Oct 25 2015

I had to go research this extensively because I couldn't believe it, Chrome has no support for MathML! 

Very very odd! I am ready to donate to Google so they can hire someone to fix the "security" issues with MathML!

Comment 109 by, Nov 25 2015

As editor of the weekly "Varsity Math" column in the Wall Street Journal, I can say that the lack of Chrome support for MathML has certainly caused us difficulty, and slow page loading, in publishing that column.  The National Museum of Mathematics would be able to improve its web outreach if Chrome supported MathML.  If those responsible for the roadmap for Chrome read this issue tracker, please put MathML back on that roadmap.  Thank you.

Comment 110 by, Nov 26 2015

Chrome team, you should be ashamed of yourself. Can someone please justify this decision to not put any effort on this feature for 3 years?

Even when effort was given, you didn't even pay the people that worked on mathml...

MathJax has done a great job, but as a mathjax team member has said multiple times, MathJax **can't** provide the real solution. Polyfilling is just not fast enough. Want to make a WYSIWYG math editor using mathjax? Forget it. Want to ever send an html email with math notation, a screenshot is your best bet right now. 

"The book of nature is written in the language of mathematics." -- Galileo 

Yes, Web components, Shadow Dom, Html Imports, Polymer, is also very exciting, I understand that you put a lot of effort there. But prioritizing this above supporting the language of mathematics to be written natively on one of the currently most popular communication software, is just a bloody shame!

Euclid, Pythagoras, Newton, Leibniz, Fibonacci, Turing, Descartes, Riemann, Gauss, Euler and Leonardo da Vinci,  would all turn in their graves, hearing about the priority you guys are given to the language of mathematics...

Comment 111 by, Nov 27 2015

 Issue 561866  has been merged into this issue.

Comment 112 by, Jan 2 2016

Hopefully these concerns will be updated by the Chrome team. Please consider adding MathML!!

Comment 113 by, Jan 13 2016

I do not know why people use Chrome. Just use Firefox. I am sick of this useless attitude of Google people and whoever contributes to this project. I have to put a notice on my site about MathML compatibility just because of this. Those who want to visit my site they must use a MathML browser. I do not care for users of chrome. So who is the looser? Chrome team.

Comment 114 by, Apr 5 2016

Please add support for MathML. Being able to accurately represent formulas on the web is critical to explanation and understanding of mathematical concepts especially in distance and high-tech learning environments, which are becoming more and more prevalent. Thanks.

Comment 115 by, May 2 2016

Please pardon this plus one equivalent, but this issue is becoming increasingly important to those of us in math and science education. Chrome just surpassed IE as the most widely used browser by some measures. FireFox is a deeply distant third at best. My students primary means of access to the Internet is increasingly via Chrome on Android cell phones using the college wifi. The low household incomes in the nation in which I work in means students do not usually have phones that have space for two full fledged browsers. Nor is the iPhone and Safari an affordable option. I hand code MathML in course materials, having MathML natively implemented in Chrome is a learning need of my students here.

Comment 116 by, May 3 2016


I very good chrome extension from

Free to use and very performant.

Ionel Alexandru

Comment 117 by, May 6 2016

This is height of bizarreness, a company that can build a driver less car can't implement MathML in browser. Go figure.

Comment 118 by, May 27 2016

Blocking: 463348

Comment 119 by, Jul 30 2016

I can not fathom how a company that can afford to fill their headquarters with rubber ducks because they thought it would be funny can't afford to hire the coders needed to make MathML work.

MathML is part of the HTML5 standard. And no, downloading a JavaScript widget isn't an appropriate solution, that causes problems when viewing off-line or when there are accessibility issues.

Google, do the right thing and support the standard.

Comment 120 by, Aug 10 2016

Components: Blink
Labels: -mstone-X

Comment 121 Deleted

Comment 122 by, Aug 16 2016

Components: -Blink Blink>CSS Blink>DOM Blink>Layout
Labels: -Pri-2 Launch-Accessibility-NotReviewed Launch-Legal-NotReviewed Launch-Privacy-NotReviewed Launch-Security-NotReviewed Launch-Test-NotReviewed Launch-UI-NotReviewed Pri-3
Adding components affected by this feature.

Comment 123 by, Nov 10 2016

Google, please make an effort to fix this.

Comment 124 by, Nov 12 2016

Google pls enable Mathml support in Chrome. This is HTML 5 standard...

Comment 125 by, Dec 7 2016

pls enable Mathml support in Chrome. This is HTML 5 standard

Comment 126 by, Dec 12 2016

Status: WontFix (was: Available)
Everyone, this is a launch tracking issue for Chromium's internal process.  This is not a feature request issue.

Please add a comment on Issue 6606 if you'd like to say something, or check a star on it. Checking a star on the issue would be recognized as a vote for a feature request.

Comment 127 by, Dec 12 2016

Blocking: -463348

Comment 128 by, Dec 12 2016

If Chrome does not intend to support MathML, it should at least provide information how to handle pages with math. For instance, there is a "Math Anywhere" plugin.

However, it sounds strange to me that there are about 50000 issues on SVG (Section 4.7.15 in the HTML5 standard [1]) and the one issue regarding MathML Section 4.7.14 in the same standard is closed as a feature request.


Comment 129 by, Mar 28 2017


Comment 130 by, Nov 27

Labels: allpublic
Showing comments 31 - 130 of 130 Older

Sign in to add a comment