MathML Forges On

The standard for mathematical content in publishing work flows, technical writing, and math software

20 years into the web, math and science are still second class citizens on the web. While MathML is part of HTML 5, its adoption has seen ups and downs but if you look closely you can see there is more light than shadow and a great opportunity to revolutionize educational, scientific and technical communication.

Printer in 1568-ce

Somebody once compared the first 20 years of the web to the first 100 years of the printing press. It has become my favorite perspective when thinking about web standards, the web platform and in particular browser development. 100 years after Gutenberg the novel had yet to be invented, typesetting quality was crude at best and the main products were illegally copied pamphlets. Still, the printing press had revolutionized communication and enabled social change on a massive scale.

DE-Zeitungsrollenoffsetdruck by Steschke

In the near future, all our current web technology will look like Gutenberg’s original press sitting next to an offset digital printing machine.

With faster and faster release cycles it is sometimes hard to keep in mind what is important in the long run—enabling and revolutionizing human communication.

Since I joined the MathJax team in 2012, I have gained many new perspectives on MathML, the web standard for display of mathematical content, and its role in making scientific content a first class citizen on the web. But it is rather useless to talk about MathML’s potential without knowing about the state of MathML on the web. So let’s tackle that in this post.

A little bit of history

MathML has a long and somewhat particular history among the standards that make up HTML 5. It started out as the <math> tag in the draft of HTML 3 (all the way back in 1995) but HTML 3 proved too complex for browsers to implement (we are talking Netscape and IE here). As modularization was the hope and XML was the fashion, the math tag was eventually kicked out with HTML 3.2 and turned into a separate XML language—and a year later MathML was born.

In the past decade MathML became the standard for mathematical content in publishing work flows, technical writing, and math software. Despite its success MathML remained hidden from view of the (web) community as most MathML content stayed behind paywalls, within intranets or in print. For lack of browser support, MathML entered the open web mostly as image renderings or PDFs, losing all the advantages of its markup in the process.

With HTML 5 MathML (now at version 3) was finally brought back into the fold as a regular part of HTML; no more namespaces, no more XML parsing—in HTML 5, MathML is just HTML.

(By the way, for those who know TeX/LaTeX (and maybe think it is the one true way), it is probably important to know that the MathML and LaTeX working groups overlap and that MathML, while a completely different beast, is sort of what you get when you try to fit math mode LaTeX into a DOM (this is, of course, a lie).)

Browser support

Given its odd history, it is perhaps not too surprising that the state of MathML support in browsers is a bit complicated. First off, MathML consists of two large parts, Presentation and Content MathML. No browser or JavaScript polyfill renders Content MathML (but see below for plugins). However, this is not really a problem in real life since Content MathML can be converted and embedded into Presentation MathML.


Mozilla has relied on its community to slowly move MathML in Gecko/Firefox forward. Most of the implementation has been done by unpaid volunteers (but of course code review, support and maintenance has been provided by Mozilla employees). Still, Mozilla does not seem too interested in pushing its MathML development over the finish line.

The current state of MathML in Mozilla is solid and sufficient for production use; see their overview for details. The largest part of (Presentation) MathML 3 is implemented. The big missing blocks are the “elementary math” elements (important for school-level math) as well as some of the more advanced <mtable> features and alignments (one of the trickiest parts of MathML that cannot easily be done with HTML/CSS constructs).

Gecko’s implementation re-uses HTML/CSS rendering code, which is as it should be—math is two-dimensional text, typographically speaking. There are a few Firefox Add-ons to tweak things, in particular for Content MathML and elementary math support via XSLT stylesheets.

The future outlook is much like the past. Whether the remaining MathML features are implemented will depend largely on volunteers or third parties stepping up but at least Mozilla considers the code base important.


WebKit has also relied on unpaid volunteers for its implementations. There have been basically two separate pushes (by separate volunteers) and no steady development so far. In addition, Apple developers have been spotted working on VoiceOver/accessibility related issues. WebKit has not really shown strong interest or support for the volunteer work but has at least accepted contributions. The second volunteer push was in 2012 (more on that later) and it seems the last chunk of these contributions has finally been integrated into Safari 7.

WebKit’s MathML support can only be described as partial and is not ready for professional production. However, it is enough for many enthusiast which could create a productive feedback loop. While simple mathematical expressions will render, some basic constructs are not implemented. Notably limited or missing are horizontal stretch characters, RTL, linebreaking, elementary math, and most mtable attributes; check WebKit’s status page for details. As with Firefox, WebKit’s implementation re-uses HTML/CSS rendering components.

The future outlook is somewhat bleak. There is a little bit of volunteer work going on (fixing security bugs, implementing multiscripts). The 2012 push (see Blink below) has shown that without a clearer message from WebKit companies, it is unlikely WebKit will attract new contributions.

On the bright side, a few WebKit developers review code and Safari actually uses the MathML code. While the rendering quality of WebKit is currently too low, the 80/20 point is not that far off.

Internet Explorer

Microsoft has never indicated interest in implementing MathML in Internet Explorer directly. However, in the good old days of IE monopoly (aka 2000), Design Science released its free MathPlayer plugin for IE. MathPlayer (now at version 3) still provides the most complete MathML 3 support (including Content MathML), but unfortunately only on IE 6-9.

Accordingly, the current support in IE is a bit odd: for IE<10 with MathPlayer installed, MathML support is virtually flawless. Otherwise, there is absolutely no native support.

The outlook for the future is actually worse. Microsoft has begun to kick plugins out of IE so that MathPlayer will not be able to support IE10+. Unfortunately, Microsoft is still not showing interest in adding MathML support to IE. On the other hand, Microsoft has consistently sent a member to the W3C Math Working Group and supports MathML in its Office products and handwriting recognition.


Chrome was the center of quite a bit of drama in early 2013. As mentioned above, 2012 saw the second volunteer effort to improve MathML in WebKit (which Chrome used at the time). A single volunteer re-wrote & improved most of the MathML code in WebKit with the specific goal of getting MathML activated in Chrome. He eventually succeeded and Chrome 24 enabled MathML. But, as it often goes, volunteers have to go back to making a living and the Chrome team did not take up ownership of the code. So when a security issue came up, Chrome decided to deactivate the MathML code again, rather than accept further community patches. (Those issues have since been resolved in WebKit.)

With the move to Blink, the MathML code was officially removed from Chrome’s code base. It could probably be brought back from WebKit for a while but for the time being Chrome has no support for MathML (and it does not exactly inspire third-party contributions in the future).

Opera gave up its (extremely) limited MathML support in Presto with the move to Chromium. Presto’s implementation was based on a CSS stylesheet using the CSS3 tables module designed for that purpose. Unfortunately, only Presto ever supported it and the module has since been retired.

As it turned out, stylesheets are simply too limited to implement MathML. If Opera’s switch to Chromium has one good consequence, it might be that the W3C “MathML CSS profile” (which you should never even link to) will finally be forgotten—it never worked and never will but gave casual observers plenty of wrong ideas.

Addendum. Shortly before publishing this post, a Chrome team member added a comment to issue 152430 (Enabling MathML support) stating that “MathML is not something that we want at this time”. This sounds very dramatic but won’t surprise anyone following the development over the past year. Unfortunately, the reactions on that thread are mostly noise. Personally, I believe this statement can actually be helpful and restart the conversation.

MathML Test Suite

As a point of reference, the W3C Math Working Group keeps an extensive MathML test suite. Feel free to run your favorite browser through it and compare the results.


MathML’s history makes polyfills challenging. To say the least. Most polyfills take on new APIs, e.g. web sockets, storage, shadow DOM. Accordingly, most polyfills are not held to extremely high standards, have time to grow and influence browser development and, above all, most polyfills do not to implement a whole new text rendering capability, closely interacting with existing text rendering.

Mathematical layout is different. Math is two-dimensional text and there are already high standards, deeply ingrained into education and publishing. At the same time, the need for math on the web has been urgent from the start which has led to horrifyingly stopgap but inherently wrong solutions such as image-rendering (would you render regular text as an image?).

Besides providing acceptable rendering, MathML polyfills also have to tackle several other problems. For example, fonts remain a challenge (see more below) and browsers do not offer enough APIs for accessing font metrics, calculating correct widths and heights, or signaling the download of webfonts.

Another problem for polyfills is CSS. While picking up direct (inline) styling of MathML elements is easy enough and inheritance of surrounding CSS will work if a polyfill generates HTML, the only other proper method for accessing intended styles is getComputedStyle—which is too slow for hundreds or thousands of equations.

A common misconception is that a stylesheet may be enough to implement MathML. Opera tried and failed. (If you take away only one thing from reading this, please let it be this: a stylesheet for MathML will not work. Really. Save yourself the time and everyone the trouble.)


[Disclaimer in case you missed it earlier: I am part of the MathJax team.]

MathJax is a bit more than just a MathML polyfill. The MathJax project started in 2008 as the successor to jsmath when technologies such as CSS 2.1 and webfonts were just about good enough to have (lots of clever) JavaScript solve the problem—no plugins, no font installation, just working out of the box.

MathJax implements the TeX layout algorithm, laying out subexpressions recursively with precise measurements and asynchronously providing webfonts, their font metrics and everything else needed for cross-browser support, all the way down to IE6.

MathJax is highly modular and extensible in input, output, and internal format; it currently accepts MathML, TeX and asciimath input, and creates either HTML/CSS, SVG or (tweaked) MathML output. Its MathML support covers most of Presentation MathML and there is experimental support for Content MathML. Notably missing are elementary math, RTL, and some of the advanced mtable attributes; see the MathJax documentation for details. MathJax also comes with a rich set of APIs which have enabled everything from StackExchange sites to web-based editors to interactive document formats (iPython, Sage) to ePub 3 reading systems.


jqmath is actually almost as old as MathJax but only recently separated input and output so that it now works with standard MathML input (jqmath also offers a nice serialized input language).

As a polyfill, jqmath takes a completely different approach from MathJax, trying to let browser layout engines do most of the work. It is faster than MathJax but has trouble dealing with more complex content—browsers are just not reliable enough. jqmath mostly relies on local fonts and browser support for those.

jqmath is developed by Dave Barton who is the volunteer who worked on WebKit’s MathML code in 2012. Accordingly, jqmath works especially well augmenting WebKit/Safari MathML support.


Here are two sets of samples.

What works

First, a sample of four equations that should render ok out of the box in Firefox, Safari, MathPlayer, jqmath, and MathJax. But first, let’s look at your browser’s rendering.

Here are some screenshots for comparison.

What does not work

Here is a sample of four equations where at least one won’t work out of the box in your browser (except with MathPlayer on IE). This sample contains elementary math and RTL content in the bottom row. Again, let’s first look at your browser’s rendering.

Again, here are some screenshots for comparison.


Fonts are a particular issue for mathematics, MathML and polyfills in particular. The most obvious problem is that most fonts do not contain glyphs for mathematical characters. But even when they do, many mathematical and scientific characters lie outside the Unicode BMP and only recent browser versions support non-BMP codepoints well enough.

Mathematics also needs stretchy characters (parenthesis, braces, root signs, etc.) which are built out of multiple glyphs; some of these glyphs have no Unicode codepoint and fonts store them at PUA codepoints (or even outside the Unicode range). In theory, the OpenType MATH table extension (developed but not officially released by Microsoft) could resolve these problems. However, no browser actually supports OpenType MATH tables—and like most low-level font technology, JavaScript polyfills would probably not be able to access them.

On the browser side, Gecko/Firefox supports stretchy constructions with Unicode characters in general and but for non-unicode components support is limited to STIX and Asana fonts (by hardcoding the PUA codepoints); see Mozilla’s documentation. WebKit/Safari only supports some stretchy constructions with Unicode characters. A big problem is for users to have the necessary fonts on their system. Firefox does not ship math fonts but there is s a math fonts Addon. Safari ships with the STIX fonts on OSX, but not iOS.

On the polyfill side, MathJax provides the necessary font data for its own webfonts and the STIX fonts with more font options in the upcoming release; jqmath leverages local fonts.


One of the great advantages of MathML is accessibility. Accessibility today is not just about low vision and blindness but everything from physical to learning disabilities. Most of all, it improves content for all users. With MathML, mathematical content becomes native—searchable, re-usable, copy&paste-able, and can take part in dynamic content. Simply put: it does anything we’ve come to expect from text on the web.

The state of MathML accessibility is another one of those odd aspects of its history. With so little browser support, you might not expect accessibility tools. However, the already mentioned MathPlayer plugin for IE is also the gold standard for math accessibility, providing state-of-the-art speech generation in several languages as well as Braille output, synchronized highlighting and other advanced features.

The newcomer is ChromeVox (for Chrome, ChromeOS and Android), which added math support earlier this year. Apple’s VoiceOver also recently added some support for voicing MathML in iOS7 and OSX 10.9 (Maverick). Given the state of MathML support in Safari and Chrome, this is truly “putting accessibility first”. Very recently, NVDA’s James Teh announced a prototype with MathML support.

Both MathPlayer and ChromeVox work well with MathJax. MathJax will recognize MathPlayer and hand off rendering & accessibility features. ChromeVox leverages MathJax’s APIs to make MathJax output as accessible as native MathML and in turn uses MathJax to make image renderings accessible on sites like Wikipedia, MathWorld and

If you don’t see the screencast, please follow this link to the Design Science demo page.

The future

You might be dismayed when you hear that there is little reliable browser support and little to no active development. Or you might be frustrated with the complexities of polyfilling MathML.

A different perspective is to see MathML as the comeback kid of web standards. Browser vendors may not be able to see the importance or the opportunities that lie in MathML but its community won’t give up. Where other standards have slowly withered away, MathML has not only stood its ground, it was kicked out and made it back into HTML.

There is a simple reason for this: the standard is good. Its community is robust, the development steady and the need for math simply universal in education, research and industry around the world.

The most important outlook is that we are on the brink of solving the problem of browser support. Gecko is already past the 80/20 point and with a bit of funding WebKit could get there quickly. This might, in turn, lead to Blink reconsidering and re-importing the code from WebKit. At that point a large majority of users would be covered and polyfills could start augmenting the native rendering, instead of replacing it—and develop the web forward, towards future iterations of MathML.

We do not even have to wait for browser vendors to get around to this, it can start right now.


Sign up for the O'Reilly Programming Newsletter to get weekly insight from industry insiders.
topic: Web Platform
  • PaulTopping

    Nice post, Peter! Because of the lack of native browser support for MathML, some people assume that MathML is a failure. Posts like yours help a lot to dispel that notion. I can add a little more ammunition to that fight.

    I just returned from the EDUPUB workshop in Boston where publishers and standards organizations are working on a EPUB 3 profile for educational publishing. Basically, they are talking about how best to make use of EPUB 3 standard for educational publishing in ebook form. The effort involves IDPF (publishers of the EPUB), W3C, IMS, and many others.

    During that workshop MathML was mentioned many times as important to ebook publishing and accessibility in particular. MathML is now an integral part (pun acknowledged) of most publishers production workflows. Now they are moving to a “digital first” approach where they produce content for the web and ebooks first, print second, MathML support is even more critical. Considering the importance of MathML to education, they were all anguished and puzzled at the lack of support by Apple, Google, and Microsoft. Those companies say a lot about their support for education but it seems to be only talk in the MathML area.

    Luckily, the MathJax team added their work to the Readium project’s EPUB 3 implementation. Without that, ebooks would really struggle to support MathML. Peter and the rest of the MathJax team should be congratulated for their excellent work to make this happen.

    I suspect the main reasons browser makers seem to ignore MathML is that they have a lot of other things to worry about. Also, the communities that really need MathML often do not have a channel back to these vendors that gets their attention. My hope is that posts like this get their attention.

    • Peter Krautzberger

      Thanks, Paul.

  • Pander

    There are at least six mathematical typeface which can support MathML. Please see and name also XITS (alternative to STIX) and Latin Modern (old name Computer Modern) in your article please.

    • Peter Krautzberger

      That’s correct but what I was pointing out was that rendering systems do not fully support those fonts for technical reasons (such as missing support for OpenType math tables). In particular, the popular Cambria Math (available on most Windows installations) stores some glyphs outside the Unicode range and so cannot be fully supported without math tables.

      I’ve also found that it is little known that Firefox has to resort to hardcoding PUA codepoints for STIX and Asana to support all stretchy constructions (of course this support is far better than no support!). Since the most common stretchy constructions use Unicode characters, this is not often an issue problem, but when it is, it’s usually a rather unpleasant surprise.

  • Daniel Glazman

    FWIW, BlueGriffon, Wysisyg html editor, and its sibling BlueGriffon EPUB Edition, EPUB2/EPUB3 editor, both offer MathML editing support through AsciiToMathML.

    • Peter Krautzberger

      Hi Daniel. Yes, I didn’t talk much about epub3, or its reading and authoring systems (it was getting longer and longer ;-) ). You should be able to support MathJax-TeX the same way you support Peter Jipsen’s asciimathml though.

  • Juliusz Chroboczek

    > We do not even have to wait for browser vendors to get around to this, it can start right now.

    That’s great news. After all, we’ve only been waiting for math in HTML for slightly over 15 years, it’s great we can start “right now”.

    In the meantime, both the higher education and the scientific communities have given up on HTML, and switched everything to PDF. Our user bases, after some complaining, have accepted PDF as the format of choice, coincidentally to PDF implementations getting good enough, both in browsers and tablets/readers.

    But yeah, let’s start right now.

    • Peter Krautzberger

      PDF is a great format for print and a decent format for static display but it is not really related to web standards or browser rendering engines.

      It’s a bit like comparing shipping data on hard disks to transferring data via the internet. Obviously, sometimes hard disks are better. PDF fails in terms of accessibility (where its features lack adoption) as well as re-usability, interactivity, and reproducibility (i.e. integration with data).

      PDF also severely limits the development of new forms of communicating math and science. While many of the humanities have been able to explore new forms on the web, math and science are greatly lagging behind.

      You write, “In the meantime, both the higher education and the scientific communities have given up on HTML,[...]“.

      I admit my experience leaves me with the opposing impression — print-based formats such as PDF are showing their limits rather quickly. Even ignoring phenomena such as MOOCs, projects like Sage and iPython as well as many commercial systems with web-based output find increasing adoption. And the greatest advantage is that the same technology is benefiting all levels of education and all over the world.

      But I agree: standing around waiting for somebody else to do the job won’t move math on the web forward.

      • Juliusz Chroboczek

        >> In the meantime, both the higher education and the scientific communities have given up on HTML

        > I admit my experience leaves me with the opposing impression

        I’d certainly be interested to hear more about your experience. In the meantime, please use your favourite search engine to search for “Algebra handout” or “Complex Analysis exercises” and let me know what format the first hits are in.

        • PaulTopping

          No one would dispute that there’s a lot of PDF on the web. However, virtually all the publishers and elearning companies are basing their future work on HTML5 as part of their “digital first” strategies. They will continue to produce PDF but that’s not the focus anymore. In education, MOOCs are big news and they are all HTML-based, not PDF. Everyone is committed to The Web Platform (HTML5 and its related standards; see www. Web formats outside this platform, such as PDF, Flash, and Java web applets, are gradually being left behind.

  • Richard Pipe

    A great summary of the situation Peter. MathML is the only possible way forward for education content. AZARDI Desktop uses Mozilla XUL Runner ONLY because of the quality of the MathML support and our target education customers.

    Some of your other comments on the Internet have highlighted the processing overheads of MathJax vs. native rendering. We produce books with thousands of equations and MathJax shows its system processing costs. That is why our reading systems only load one section at a time. No ePub2 load the whole book stuff.

    The lack of “elementary maths” structures is important. We have had to develop alternative strategies for core arithmetic structures and wait in anticipation to do long-arithmetic with MathML whether it is addition, subtraction, multiplication or division.

    This post is a landmark statement on MathML (pity it was on Oreilly). I will certainly be pushing it hard to our customers and anyone who will listen so they understand the various facets of implementing MathML.

    Thanks for the significant position statements, nearly all of which I agree with. I am just a little pessimistic on the uptake inspirational messages you have delivered to Microsoft, Google and Safari! MathJax may just live forever!

    • Peter Krautzberger

      Thanks, Richard. We haven’t had too many requests for elementary math which is why it hasn’t moved up in our backlog, I’m afraid.

      Regarding the browsers, all but Microsoft are open source and third parties can invest directly. MathJax has shown that the financial burden of such an investment can be shared among competitors.

  • Ben Crowell

    This is a very informative summary of the facts, but I’m baffled by your interpretation of the facts. The reality seems to be that desktop browser vendors other than Mozilla have no intention of providing ongoing, built-in support for mathml, and in fact what little support they used to provide is now showing radical regression. I’m sure they see the existence of mathjax as the perfect excuse for not pulling their own socks up. Since mathjax is the new de facto standard, I guess it’s time to start figuring out how to work around its serious shortcomings as a standard, such as the fact that it’s too slow to be suitable for ebook readers and assumes a fast internet connection, so it’s not suitable for offline use.

    • PaulTopping

      I’m not sure you meant this but what you write here makes it sound like MathJax is an alternative to MathML. Instead it is an implementation of MathML.

      I share your fear that some people might conclude that the existence and success of MathJax means that there is no need to go to the trouble of implementing it natively in browsers. However, there are lots of reasons that they’d be wrong. Your “serious shortcomings” seems to acknowledge this. However, it doesn’t assume an internet connection. It works just fine in ebook readers without needing a connection. Speed is sometimes an issue but it may be less of one in ebook readers because of its paginated content.

      The people at Apple, Microsoft, and Google that have said anything about MathML at all seem to be programmers. Their main concerns appear to be security and the concern that MathML code and fonts increase the download size of their browser. In other words, it is strictly an internal view. They do not even seem to know or care about the usefulness of MathML in the world. Marketing and product management types at these companies are the ones that need to hear about MathML. And they need to hear it from educators and publishers.

    • Peter Krautzberger

      Thanks, Ben. As I tried to point out, I think WebKit can quickly improve to the level of Gecko (which in turn could quickly complete its support) at which point Blink could re-import from WebKit (or at least react). This is a way forward.

      Both Mozilla and Apple accept the code and the advantage of open source is that third parties can actually get involved. If MathML is not a priority for Mozilla and Apple, then those that consider it a priority need to invest (and as Paul points out: speak up).

      Regarding MathJax’s shortcomings, development is onging and we plan to work on speed improvements after v2.3 is out. But the two examples you point out are not quite accurate. First, a well designed integration into an ebook reading systems should be able to eliminate speed issues (by rendering viewports instead of chapters). Second, there is no problem with using MathJax offline and shipping it in an application; it usually adds less than 1MB to an installer (~2MB unpacked). But this is getting off topic; feel free to get in touch about this.

    • Ted Wise

      MathML has _some_ level of priority at Apple. They support it (and advertise it) in limited format for iBooks and iBooks uses WebKit.

      • Peter Krautzberger

        I think that remains to be seen. If there is no active development, then it’s very likely that something will break the MathML code eventually (simply because it re-uses HTML/CSS constructs which are bound to change). Then we will we see if Apple is as committed as Mozilla who, in a similar situation back in 2007, spent serious developer time on re-activating MathML.

  • Alex Milowski

    Very nice post that summarizes the “state of the MathML universe.”

    In the original push, it was Sausset François and myself working on the code that I started in late 2009. My original goal was to get something useful enough to get it turned on with the idea that once it was turned on others would follow and contribute. That did happen [1] and then I had to move on to other work.

    I found the folks at Apple very helpful at a certain point. It really felt very frustrating at times trying to understand on my own how to build a complex renderer for MathML within the WebKit framework and within their development process. Nevertheless, the WebKit community can be very helpful and friendly.

    Apple did spend QA time and fix a number of issues so they could ship it in Safari and have continued in that same mode since then. I think we should be happy they are partially engaged on MathML. I do wish they’d dedicate some resources like they did for SVG to get it complete enough to be used professionally.

    What we need is one or two well-funded developers for about a year to get this off the ground. To this end, I think we need to rally the various users (publishers and WebKit technology users) and crowd-source the funding. We have enough technical experts that could easily provide guidance to a couple of dedicated engineers to get this done.

    I wish I had the time back in 2010 / 2011 to continue the development but I didn’t.


    • PaulTopping

      While I applaud the work of you and others on MathML in WebKit and in other browsers, I do believe it will take management commitment to get the job done. MathML support is particularly hard to integrate into an HTML engine. It needs hooks deep into the HTML/CSS formatting engine. Without support from high-level architects, it gets difficult for the programmer who is simply donating a few evenings and weekends to get the support necessary. Alex, correct me if I am wrong, but you ran into this problem, right?

      • Alex Milowski

        In a nutshell, yes. In that regard, Apple was quite helpful at times but I was often in the dark and relied on experimentation or late nights reading the line layout code. Unfortunately, there needs to be a “meeting of the minds” to take the rendering engine in the right direction so it can support Mathematical layout. That’s were we’ve run into trouble because the idea of a bottom up layout algorithm isn’t what the CSS folks expect. I strongly resisted the idea that we needed to develop a new line layout algorithm or componentize the renderer for MathML (like SVG) because it seemed to me that we just need a few additional primitives.

        The recent workshop on CSS and the interest in CSS for print gives me hope. Both the standards representatives and engineers seem more open to considering new rendering requirements. As such, the idea that new primitives are needed for MathML isn’t such a radical one to socialize.

        • Peter Krautzberger

          Thanks for leaving a comment, Alex. François’s and your work laid the foundations for all other contributions — I think this cannot be understated! About Apples QA, I always wondered how Safari 5.1 was able to resolve all issues without stabilizing them in the WebKit codebase (i.e. without Chrome doing so); it would have helped if they had fed that back.

          Of course, I didn’t mean to say that the WebKit (or Blink!) communities aren’t friendly.

          It just seems unrealistic to expect major design decisions on HTML/CSS layout to land. Those would be pretty large patches that would have a hard time to find reviewers (let alone acceptance). I agree that two developers, one year, is probably enough assuming some design decisions are resolved. I don’t think anybody is going to get another bottom-up patch through at this point.

          • Alex Milowski

            Oh, but they did! The code in WebKit is the code the ship as far as I know. The concerns about modifying the rendering tree are a bit unfounded in that it never actually produced any direct issue. It just isn’t the way WebKit rendering was designed to work. The funny bit there is that no one balked until much later. My patches went in and then people much later scratched their heads and decided that wasn’t the way things are designed to work (at least from my perspective).

            They’ve “fuzzed” that code a lot and whatever issues they found have been fixed over time. Meanwhile, Dave Barton made a lot of those issues less so and his contributions are very crucial. I haven’t had the time to track what has made it into the WebKit trunk vs. what is still being debated.

            If a developer (or two) resource were to be applied to this problem, it would be essential to have Apple’s (and possibly other’s) support. They’d have to be willing to dedicate QA and engineering support to those developers in the same way they did for SVG. With Google gone from WebKit, Apple is the main player. The good news is the general feeling I get is they’d like to see MathML succeed as a native implementation.

          • Peter Krautzberger

            Ah, ok. I was thinking about the fact that it wasn’t until Dave’s work that Chrome had its problems fixed — I just confused the two-heads of the beast there for a minute. Thanks for setting me straight :)

            I agree that Apple is supportive of the code right now. The two biggest changes not in Safari 7 are a patch implementing multiscripts and a patch eliminating all of Chrome’s security concerns (mutation of the render tree and calling layout during preferred-widths).

          • Alex Milowski

            That’s good to know.

            I think it is really easy to “demonize” big companies and their contributions (or not) to things like MathML. While I wish that Apple would dedicate engineering resources to implementation MathML like they did for SVG and might complain that they haven’t done so, I really appreciate the support they have provided. That makes it possible for individuals to contribute.

            Meanwhile, I don’t understand Google’s position and their dismissal of MathML feels like a slap in the face–not just personally but to all those who have spent their own time making what is in there work such as it does. But, in my opinion, that’s a trend for the Google Chrome folks and it probably shouldn’t be read as an attack on MathML.

            My real fear is that when we get it working well in WebKit (and that will happen), Blink will be so different that it won’t port.

          • Peter Krautzberger

            I agree — demonizing won’t accomplish anything.

  • Innovimax SARL

    Good post! Thanks !

    It’s probably worth citing the Acid Test in your testsuite section

    Best regads,


    • Peter Krautzberger

      Hi Mohamed,

      Thanks for raising this. The Acid test is a useful technical tool but does not really explain what the technical shortcomings mean in practice. That’s why I chose two simple visual tests that allow a wide audience to understand the problem.


  • PaulTopping

    I agree that we shouldn’t be “demonizing” these large companies and I don’t believe we have been. These companies make a lot of money by addressing the perceived needs of their customers. It should be the goal of the education, accessibility, science, engineering, and publishing communities to raise the perception that good MathML support is needed. I’m convinced that many of the people that make decisions at these companies do not have any idea how much MathML support is needed. I have seen representatives of these companies say things like, “We don’t get much request for MathML support.” I assume this is true and, therefore, they see it as a low-demand/high-cost situation. It is up to us to get their attention and the attention of these communities. Of course, posts like this one help a lot.

  • Carl Malartre

    To quickly input, share and remix MathML equations, you can use Disclaimer: I work on this free project. Have fun!

  • Ernest Wong

    But then in the future, when MathML is fully supported, should chemistry also be support? And then, when that’s supported as well, what about music notation? …just something to think about, although I know there’s things like the mhchem extension, but there are some diagrams beyond that. By the way, thanks for writing this post, and for contributing to MathJax!