In this piece I'll talk about MathML and why I think that it is especially unique, intersting, and stranger than fiction - as well as what we can/should do with it. (note: Stranger than Fiction is a movie about a very competant and number-obsessed accountant named Harold Crick who suddenly begins to hear his life being narrated, and learns that a seemingly innocuous event one Wednesday will ultimately change his life and lead to his demise, and what happens next).
Narrator: This is the story of
When Tim Berners-Lee created HTML, he drew the original elements from the corpus of SGML documents on hand at CERN. Tim picked the most common ones that he found as the original set. They are, effectively, semantics about text itself - and even in that, not necessarily especially good ones.
Given this, it is perhaps not surprising that almost immediately after its creation, discussions began arguing about what other tags should become part of HTML.
Since the Web was originally pitched as an idea about sharing information among researchers, particularly at CERN, it is probably also not surprising that two gaps that came up very quickly were "graphics" and "math": Researchers frequently need both.
Within a very short window of time, Dave Ragget had assemebled a number of ideas for what he called "HTML+" which took (believe it or not) only a fraction of those ideas and would have created roughly five times as many elements as Tim's original browser supported.
Notably among those, Section 12 of HTML+ included a
math element and they had experimental browser support at CERN.
That proposal wasn't accepted. But it wasn't the end of the conversation, or the need, either.
And so, for many years, two communities continued to work on these problems outside of HTML itself: In the case of graphics this would become SVG, and in the case of formulae, MathML.
Harold Crick was a manMathML was a markup of infinite numbers, endless calculations, and remarkably few words.
Little by little, bit by bit, they made progress. By the time the WHATWG/HTML5 era rolled along, there was some degree of maturity and the new standard would come to include at least some degree of answer for both of these asks by reference to the work that these communities did. HTML's section on Other Embedded Content mentions only two - these two, specifically.
If you are unfamilliar with MathML, it looks something like this.
<math xmlns="http://www.w3.org/1998/Math/MathML" display="block"> <mi>x</mi> <mo>=</mo> <mrow> <mfrac> <mrow> <mo>−</mo> <mi>b</mi> <mo>±</mo> <msqrt> <msup><mi>b</mi><mn>2</mn></msup> <mo>−</mo> <mn>4</mn><mi>a</mi><mi>c</mi> </msqrt> </mrow> <mrow> <mn>2</mn><mi>a</mi> </mrow> </mfrac> </mrow> </math>
Like HTML itself, its semantics are fairly weak - but also like HTML itself, it turns out that you can do quite a lot with that. Given the markup above, your browser would render something like this:
And so, it looked like we had an answer for this, at last.
Narrator: That was, of course, before Wednesday.
Harold's wristwatchChrome changed everything.
Work continued and Firefox shipped some kind of MathML support as early as 2006 and, for a time just about every browser had someone either working on implmentations or already shipped. IE was sort of the last major holdout.
Narrator: If one had asked Harold, he would have said that this Wednesday was exactly like all the Wednesdays prior. And he began it the same way he--
By 2013, all in all, things were looking pretty good for the MathML community.
Harold: Hello?... Hello? Is someone there?
Then, there was something of a shakeup in terms of browser engines: That February, Opera retired Presto and joined Google and Safari as "WebKit" browsers. Some worried about the loss of diversity in browser enginers. Then, a few months later, Google announced that it would fork WebKit and create "Blink" and, very quickly, Opera announced it would use Blink too.
Narrator: Little did he know that this simple, seemingly innocuous act would result in his imminent death.
Harold Crick: What? What? Hey! HELLOOO! What? Why? Why MY death? HELLO? Excuse me? WHEN?
In the process of forking, the Blink teams intent was to do a lot of refactoring and really focus on performance. Along the way, they reviewed code and found that the newly landed contribution of MathML had a lot of complexity. They found that it had several issues, including a security flaw. It had no long-term owner on the team and would make refactoring a lot harder, so, they debated what to do with it.
Professor Hilbert: I've written papers on "Little did he know." I've taught classes on "Little did he know." I once gave an entire seminar based upon "Little did he know." Sonofabitch, Harold... "Little did he know." That means there's something he doesn't know, which means there's something you don't know... Did you know that?
On Wednesday, October 30, 2013, Google announced their decision: They would remove support for it in Blink, for now at least, and instead recommend use of a polyfill of sorts called MathJax.
I think that it would be a mistake to read too much into this. I don't think that Google was as much unified in a desire to kill
Harold Crick MathML as they were in having to make a move and thinking that perhaps that was a reasonable choice at the time.
Judgements about the quality of that choice aside,this meant that by 2013 estimates, the projected native support of MathML was suddenly around a billion users less than it had been just a day before.
Karen Eiffel: I went out... to buy cigarettes and I figured out how to kill Harold Crick.
This has had some pretty complex effects on the status of MathML: It is left as one of a very small group of things in the platform which are in a very strange place in history. This situation has even been the topic of some discussion in the W3C Technical Architecture Group (TAG) recently (and elsewhere). Like Harold Crick, we're unsure quite which kind of story they are in.
Professor Hilbert: ..The only way to find out what story you're in is to determine what stories you're not in. Odd as it may seem, I've just ruled out half of Greek literature, seven fairy tales, ten Chinese fables, and determined conclusively that you are not King Hamlet, Scout Finch, Miss Marple, Frankenstein's monster, or a golem. Hmm? Aren't you relieved to know you're not a golem?
Along the way we began trying to collectively find new ways to think about how we go about evolving the whole platform in healtier ways than the past and explaining how we deal with where we are, and how we move forward - but this has actually not been great for MathML.
While we generally accept the starting point of existing standards, because of the above, MathML doesn't fit neatly into this camp in the minds of some.
While we say that the potential path to standardization of new elements lies in experimentation and proving need and use via Custom Elements, MathML predates custom elements by a long time.
Where does this leave MathML? Asking that community to be relieved that we now have custom elements seems a bit like asking them to be relieved that they aren't a golem.
Harold: You have to understand that this isn't a philosophy or a literary theory or a story to me. It's my life.
So, now what?
As I explained earlier, because of where it fit in history, I think MathML is an exceptional case. I would argue that we should 'credit' MathML as if they'd used Custom Elements all along and just shortcut that whole aspect of the conversation. But, then what?
Thinking through this is part of what led me to write Standards Crisis on Earth-1 and propose a thought excersize about experimentation and data and ask "then what"? Because, in this light, I have to wonder what kind of message we are sending with how we choose to deal with it.
Imagine another universe in which a community works for 30 years. They experiment. After a while, they come up with a solution. It's imperfect, like all solutions, but they manage to build a base. It is included in ISO/IEC, HTML, ebook and office formats. They build an ecosystem around it. They even manage to get major native implementations. Despite lack of native support from two major vendors, or even a super clear way to go from 'here' to 'there', their base manages to expand to millions of documents.
That is an exceptionally high bar, which I think we cannot expect of another community again, probably ever. But imagine it did, because it's pretty close to reality here... Then what? How do we standardize it, or why don't we? Why?
Professor Hilbert: Harold, if you want to stay alive, you have to try something else. Harold: What? Professor Hilbert: Nothing.
But, it's not just a general feeling of "we have a duty to any community who did that much to give them some answers" that is bothering me. It's pressed further by who these groups are. The groups who have invested in and continue to need MathML have names like the "National Science Foundation". They serve altruitistic purposes like Higher Education and cancer research. They aren't just important - they are literally among the very group of folks that the Web proposed to help from the very beginning.
Given this, it feels almost fundamental to the spirit of the Web — and good for us all — that we make some extra effort to help close an important gap after nearly three decades.
As for myself, I believe that any suggestion of 'starting over' here is problematic. It's not that there might not be 'better', but we need a starting point and to not largely accept the one that has this much success and investment already seems really bad. I believe we have to find a "standard way" to ship MathML in some way that is better than the situation today. The polyfills are better than nothing, but they introduce many new challenges from performance to accessibility which are unfortunate and non-trivial.
I believe that the best hope is through current work being done by Igalia. If you aren't familliar with them, Igalia is very interesting and unique. Most organizations involved in standards fit neatly into are either "are a browser vendor", or "doesn't write browser implementations". The latter are sometimes at something of a disadvantage for reasons more practical, and less political, than we often imagine them to be. Each vendor already has their own priorities, budgets, challenges and so on. But Igalia provides a bridge between these two worlds. They don't make a browser themselves, but they do contribute code and work to browser codebases, and have developed and maintain good relationships and trust at both ends.
When blink identified concerns with the implementation at the time of forking from webkit, Igalia worked with Apple to help right the situation and MathML continues to ship in Safari to this day.
Current efforts to find a path in blink are being funded by communities who really need MathML and current proposals involve using some new underlying primitives (some through Houdini) to help not only get MathML implmented in blink, but also to do so in a way that introduces no or minimal "new magic", but rather is well explained by common foundations. This seems as good an outcome as I can imagine and I really hope that it succeeds.
If you think think this is a valuable and worthwhile effort, be sure to speak up. If you work for someone who might think that this is important, tell them about it. We can help fund these efforts too.
Special thanks to many friends, Bruce Lawson, Michiel Bijil, Alice Boxhall, Daniel Ehrenberg and Lajja Shah for thoughtful discussions and insight on the topic along the way, or proofreading one of many developing evolutions of drafts of this piece. Their name listed here is not intended as an endorsement of my thoughts, merely to express that I am ever greatful for their friendship and willingness to discuss these topics with me.