Response to Peter Krautzberger’s “MathML is a failed web standard”

Since I have spent many years supporting MathML, and was a member of the original W3C Math Working Group that created it, I feel I have to respond to Peter’s MathML is a failed web standard post, especially given this provocative title. I agree with a lot of what it says. Where I suspect we differ is in the degree to which these things are problems and on the proper response to them.

The first thing to note in his post is that he says that MathML is a failed web standard. By this, I believe he is only saying that it has failed as a language supported by browsers. He acknowledges that it is in heavy use in education, publishing, and elsewhere but I wish he’d made this distinction a bit more strongly.

I am glad Peter has brought these issues to the fore. While my first reaction is to defend MathML, there is a lot in MathML and surrounding technologies that needs to be sorted out. That said, the idea that MathML is somehow holding us back seems wrong to me. The browser makers ignore MathML so getting rid of it won’t affect them much. Perhaps Peter is directing his message to the MathML community itself. My message to them is not to replace MathML but to fix it. In short, if MathML is a failed web standard, it is not because browser makers have ignored it. It is not as if they made a deep analysis of MathML and found it lacking. To my knowledge, there are no papers from browser makers saying that MathML shouldn’t be implemented because it is flawed.

The Problems

“MathML has not been significantly supported by browser vendors, neither on the spec level nor on the implementation level”

This is certainly true but we have to look at why this is the case or we risk the same thing happening. As far as I know, no browser vendor has been forthcoming on why they don’t implement MathML. MathML code was taken out of Chrome because of security issues but, as I understand it, it was not because there were known security issues in the code but that there was no one qualified to guarantee that the code did not contain security problems. In a push for better security, they simply dumped an incomplete, understaffed implementation.

It is this lack of interest in MathML that is at the heart of the browser implementation problem. This was a problem for MathML right from the start. I recall when the W3C Math Working Group was visited by someone from Mozilla. We all thought it was going to be an open discussion with an expert about how we could work together to add MathML support. Wrong! Instead, an evangelist delivered a canned speech encouraging us to write code for Mozilla and telling us how their new Gecko rendering engine was going to solve all our problems. Any mention of problems to overcome was met with a dismissive, unconvincing “The new engine is so powerful I am sure it will handle it.” We could tell nothing was going to happen unless we did it ourselves. Luckily, a volunteer stepped up in the following months and was able to implement it. He told me he got very little help from Mozilla’s core developers. Their attitude, and those of other browser makers for that matter, is to imagine that the solution is just to write a plugin or contribute to their open source project. None are willing to recognize that implementing a math renderer requires a lot of support from the core rendering engine. They are just unwilling to have that conversation.

Things have not improved since then. The browser makers continue to actively ignore MathML. Even the connection with accessibility seems not enough to make it interesting to them. Here’s my take on why this is the case:

• While many people know math, very few have thought about math notation and the problems in rendering it in a browser. Even though this has been an issue for us for many years, we continue to encounter people that are surprised it all can’t just be a matter of using the right fonts.
• HTML provides declarative markup for human text languages and support for a few common non-text items: images, movies, sound, and that’s about it. Supporting more than that is to be solved by writing an application implemented via scripts in the page, server-side programming, or both.There is an implied division between the problem domains addressed by declarative markup and active programming. Unfortunately, handling math notation is thought to be firmly on the active programming side of that line. It is complex and, perhaps more importantly, domain-specific.
• There is a disconnect between the browser makers’ world and the world who uses math notation. They just don’t talk to each other because there are very few points at which they meet.

In short, it is not MathML being considered bad but it’s simply ignored. I don’t see this disinterest going away. Even if we put our energies behind a solution involving some additions to CSS and such, this lack of interest on the part of browser makers will be a significant problem. I believe the only solution is to find a way to embed our requested features into a problem domain much larger than math notation. More about this later.

“Browser implementations of MathML are not used.”

This one’s easy. MathML isn’t implemented in most browsers so its not used. I suppose one thing we can conclude from this observation is that Firefox could remove its MathML implementation and hardly anyone would care or notice.

“Content MathML has failed to provide usable semantics.”

I completely agree. Content MathML always seemed like a bad idea to me. To cover a large portion of mathematics is a big job so the Math WG smartly avoided that. However, the small subset of math represented by Content MathML is too small to be of much use. Furthermore, in most problem domains in which an XML encoding of math semantics is useful, it is easier to invent a one-off, ad hoc solution than deal with Content MathML. Another way to look at this is critical mass was never achieved. There was never a large, useful body of math semantics that needed encoding. My company, Design Science, gave up on Content MathML some time ago. Presentation MathML is the only MathML used in the wild by far.

“Presentation MathML fails front-end developers because it unnecessarily binds layout features to MathML elements instead of providing a usable set of CSS features.”

I agree — sort of. The Math WG should have just lobbied for a few new CSS features to support math and other kinds of rich layout. A lot of people tried to make this case at the time of MathML’s creation but hit the lack-of-interest wall. I worry that that will also be the case if this is attempted again. A new approach is needed. I also think this approach leaves untouched some important philosophical problems that need to be resolved.

“MathML fails because it does not specify layout sufficiently.”

Sure but imagine if MathML specified layout to the level that TeX does. Basically, Don Knuth declared that a math formatter is not to be called “TeX” unless it produces the same output as his TeX implementation. Regardless of the stifling effect this has had on advancement of that technology, TeX users appreciate this absolute implementation independence. Would the Math WG be willing to do the work necessary to achieve this for MathML? TeX is a document description language. MathML would have to integrate completely into HTML and CSS to do the same thing. While it is hard to disagree with Peter’s statement here, it seems unclear whether he is advocating that we specify layout to the extent that TeX does. This is a very important question for both MathML and any replacement technology.

“Presentation MathML fails because CSS is slowly implementing all layout features that mathematical layout needs, making it obsolete.”

This might well be the case but what’s the point here? If CSS now has what math layout needs, we’re done, right?

“Presentation MathML fails to provide sufficient semantics.”

Perhaps, but even if Presentation MathML provided sufficient semantics, most authors wouldn’t add them. The fact is MathML already provides recommended markup patterns for expressing a lot of math semantics but authors aren’t interested in adding such patterns to their math. Authors generally stop tweaking their math as soon as it looks right and can be read by a fellow human. I don’t think this will change. Even publishers are less and less interested in spending resources on marking up math with the required level of semantics. This won’t change even if MathML added missing semantics constructs and the necessary editing tools were available. Instead, everyone is moving in the opposite direction, spending less and less time and money on careful authoring.

Peter acknowledges Neil Soiffer’s work on algorithmically extracting semantic information from Presentation MathML but seems to think it has hit a brick wall. I totally disagree. That work only scratches the surface of what should be possible. We already have a lot of software able to read English and make sense of its structure. Math notation is much more structured than English and its domain much smaller, making the problem much more tractable. The problem here may be a misunderstanding of the level of semantic detail necessary. “Sufficient semantics for what?” should be the response to Peter’s statement. More about this below.

“The MathML spec is not actively developed.”

This is largely true but also reflects how work is done in the W3C. Working Groups disappear when their work is done. I imagine this is so that groups don’t turn into institutions and to ensure that work is driven by need alone.

What to do next

“MathML needs to be dropped from HTML 5.”

In technology, when someone has a better idea how to do something they should just do it and let the market decide whether their solution is really an improvement. They don’t start their project by calling for the competition to be killed first.

“Math layout can and should be done in CSS and SVG. Let’s improve them incrementally to make it simpler.”

No problem but a lot of work needs to be done first. Where are the proposals? Peter claims MathML’s mere existence is blocking discussions. What discussions did it block? Sounds to me like someone claiming that they could provide a proof but there’s just not enough room in the margin. I’m skeptical. He mentions that CSSWG and Houdini TF are the venues for these discussions. Did those groups say that they are unwilling to have discussions or accept proposals as MathML already solves the problem? I’m guessing that is not the case or Peter would have claimed it. To his credit, he does list a few areas where CSS enhancement is needed. Sounds like a good idea and time to write some proposals.

“We need a new approach for exposing semantics.”

I actually agree with this but I don’t think it is necessary to replace MathML to do it. Instead, what is needed is a better definition of exactly what semantics we need to define. There is also the authoring problem I’ve already mentioned. In general, authors are not looking for a way to mark up their semantics and not finding it. Instead, they are unwilling to do the semantics tagging in the first place. We do need more semantic representations but of the right type and for the right purpose, both of which I will tackle below.

My take

There are some real problems with the MathML status quo and Peter touches on most of them. However, what Peter proposes is vague in much the same manner that the original MathML effort was vague. They failed to address the hard questions but eliminating MathML won’t address them either. If someone wants to do better than MathML, they should just go for it and let the community judge their work.

As a software developer, I am well aware of the Not Invented Here syndrome. It is easy to imagine that one could do a better job. But most software engineering experts warn against throwing out a working product and starting over. It is generally better to improve and refactor the old code. I think that is what is needed here. I would love to help resolve these hard questions but I have not much interested in throwing out MathML and starting over. Not, at least, until its replacement is defined to a much greater extent than it is now.

In order to end this post on a positive note, I would like to take a shot at identifying these “hard problems” and hinting at my solutions to them.

Choosing the right semantics level

One of the problems with the word “semantics” is that it needs to refer to some domain in order to be well-specified. In mathematics, semantics is often taken to refer to what it means to mathematicians, scientists, or engineers. This kind of math semantics is notoriously hard to nail down. Instead, what we should be defining are the semantics of math notation, not the semantics of mathematics. Let me demonstrate the distinction. Imagine a typical math or physics book heavy with mathematical notation. Most such books start with a short, one or two-page section entitled “Notation used in this book”, or something to that effect. In such a section, the authors say things like “Bold Roman letters are used to represent 3-D vectors of real numbers.” They don’t attempt to define what is meant by “vector” or “real”, even though they may be highly controversial and, in fact, might be the subject of the book itself. They are simply making a connection between a notation and a concept, not fully defining that concept.The domain of the former is the semantics of math notation, the domain of the latter would be the semantics of mathematics or physics itself.

Here’s another way to look at it. Math notation semantics is the body of knowledge that is a prerequisite for reading a math book, math semantics proper is the domain of what the book is about — what one learns by reading the book.

And, finally, a third way of looking at it. Math notation semantics is to math notation as grammar (nouns, verbs, etc.) and spelling are to written English. Full computer understanding of English requires a yet-to-be-invented level of AI whereas we have had grammar and spelling checkers for years.

The authoring problem and the role of representations

The idea that we need better ways of representing math notation semantics is reasonably well accepted. We can certain add structures to MathML or use an alternative language. The question that is going unanswered is who is going to write these new structures. Are authors going to use them to mark up their math as they enter it? Are publishers going to add it after the fact? Or are automated algorithms going to infer the structure and add it explicitly to math notation as a cached annotation? Perhaps we can do all of these things but we still need to answer the question in order to ensure that our solution is practical and what is needed by the community.

Personally, I don’t believe authors or publishers are willing to spend the time creating the level of notation semantics required. Not only that, the trend is in the opposite direction. There is strong pressure to pay less and less for content and that means publishers will be willing to pay less and less to prepare content. This says to me that the future is algorithms inferring semantics and storing them in the math representation. If so, we need to design the representation accordingly. We should not rule out author or publisher adding such semantics to the representation but algorithms need to be able to tell if that is the case so as not to mistakenly replace the author’s intent.

Of course, Peter doesn’t believe automated semantics recognition can do the job. I don’t believe we’ve really tried that hard yet. If Neil Soiffer’s efforts could achieve so much (I helped too), what might happen if we put more people on it? Let’s find out. It is way too early to throw in the towel. I have a lot of ideas on how to do this.

Do we want implementation-independent math layout?

Whatever math representation we choose, we will need to render it, regardless of whether we use CSS or render directly from MathML. Do we want that math to look identically in every browser? I believe the answer is generally “no”. However, there are a lot of TeX people that would disagree. Perhaps we can do both but we need to decide how this works.

As Peter points out, MathML leaves a lot of rendering decisions up to the implementation. I think this is the right decision in general but there are some inconsistencies. Why should an operator dictionary define spacing rather than simply leave it to the renderer? Can a publisher add attributes to MathML such that it locks down rendering to the extent that reproducibility is obtained? In other words, can we have math notation that adjusts to circumstances and the whims of implementations and, at the same time, give authors and publishers the ability to completely control how their math will be seen by readers? There are trade-offs here that even a MathML replacement would have to tackle.

Gaining traction with the community by widening the problem domain

We have had no luck getting the web community interested in MathML. If we simply replace MathML by some other math representation, I suspect it will fare no better. Perhaps the way to get more attention is to attempt to solve a bigger problem that contains the math problem. After all, math notation is one of many kinds of notation. With the advent of web technology such as SVG, we should expect to see a spike in invention of new notations, especially since they can be made to interact with the user. In fact, I would like to see some attempts at making math notation interactive. Of course, this has been tried before but now we have much more powerful tools.

I’m guessing that notations other than math have similar problems in allowing semantics to be represented, providing selection models, accessibility, clipboard copy and drag-and-drop, etc. There are very few standards that go far enough to make implementing such notations easy. Why not join forces with other domains that struggle with these things and come up with general solutions?

Wrap up

I applaud Peter for waking everyone up and calling for discussions on these issues. I just feel that calling for MathML’s head on a platter is not the way to go about it. Let’s work together constructively. If MathML falls by the wayside in favor of a better solution, so be it.

I’d be happy to post this elsewhere in order to get more comments and start a discussion.