INTRODUCTION

This rant was inspired by a quote from a poster to MozillaZine who queried the need to implement MathML support in Mozilla. `I mean, why do we need MathML?', he said. `I can already transform LaTeX documents into HTML with GIFs substituting for complicated math expressions. Or, there are several java applets out there which already parse and render MathML, so why does Mozilla need it built in?'

I started writing a rebuttal to this comment, and then realized it was getting too long to be a comment. So I decided to expand on my rambling thoughts and tidy it up a bit. Here, then, are my reasons for MathML support being a Good Thing, as opposed to the existing hotch-potch of GIF, applet, and TeX plug-in math on the Web.

SPEED

Right from the start, as soon as MathML is implemented in Mozilla, it will have several notable advantages over math rendered using images, applets, or plug-ins.

The most obvious one is speed, where MathML would win on two fronts. Firstly, MathML math will always have much lower bandwidth than image/applet math -- in the image case, simply because the image has high redundancy whereas MathML does not, and in the applet case, because the applet itself will usually (unless it is cached) need to be downloaded along with the math data itself. Even with a locally stored math plug-in, which does not usually need to be downloaded separately, the math still needs to be stored in a separate file, and inserted into the HTML document using an OBJECT or EMBED tag (I stand correctable here). This means an extra HTTP request (in HTTP 1.0, at least) for what is probably a very small amount of data.

Secondly, applet (or plug-in) math is almost certain to be slower to display than MathML, given the time needed to fire up the JVM (or the plug-in) compared to the time to parse and render the MathML. (Bitmapped math would probably, all other things being equal, be faster to display than MathML; but in my opinion this advantage is more than outweighed by the other reasons given here.)

The other immediate advantage to MathML would be that it is far quicker to generate, and -- just as importantly -- to maintain, as math stored in another format. Editing text is a whole lot quicker (and can be automated much more easily) than editing (or rewriting) your equation, saving it, and going through the fiddly process of reconverting it to image or applet form.

RENDERING

As far as rendering is concerned, a few simple examples should show how MathML would be better than bitmapped or `appleted' math.

1. When I change my font preferences, the font used in math expressions should change too. If the math is in MathML, no problem (provided you have the fonts); if it's a bitmap, tough luck.

2. When I resize my browser window, math in the document should wrap in the window just like the rest of the text does. If it's in MathML, no problem (with a few exceptions for things like large fractions); if it's a bitmap, sorry, you're going to have to scroll.

3. The DOM. Need I say more? Ok then, I will. Math inserted as an image can not be manipulated by JavaScript. Individual characters or parts of the equation can not be selected, or found using Edit > Find. Individual bits of the equation cannot be linked to explanatory notes somewhere else (unless you get into the horrors of maintaining an image map along with the image itself). All these problems are solvable using MathML.

Applet/plugin math might be able to do some of these things, but they would be very tricky to implement. For (1) and (2), the applet or plugin would need to have access to browser environment variables (font, background color, window size, and so on), and it would have to do this in a standard way (so that it didn't need to make a special case for every browser it found itself running on). You can imagine the mess that would result. The W3C would have to churn out a standard for passing browser preferences to an applet or plugin, and the whole thing would turn into a quivering mess. Given a choice between MathML and what the W3C might call UserAgentEnvXML, I'll take MathML any day.

All this is assuming, of course, that you're using Mozilla. What about Lynx users? MathML is good for them too. Bitmapped, applet, or plug-in math can not be viewed by users of Lynx and other text browsers. (Yes, I know, you can set up Lynx to do this IF you're running under a windowing system AND you have an image viewer and JVM set up as plug-ins, but in that case there's no real reason for you to use Lynx instead of Mozilla anyway. :->) With MathML math, a current version of Lynx will at least show the text involved (even if vital bits like fraction positions are missing). And a future version of Lynx has a fighting chance of being able to display the equation more recognizably by doing its own MathML rendering; with bitmapped/appleted math, it has no such chance.

Or what about those who use a speech browser, because they're blind, or because they're too cool to do their Web-surfing in front of a monitor? A speech browser can't take a GIF equation and tell the person, `why equals eks squared plus sine of ...'. An applet could, but you'd be relying on the Web page author being kind enough to give their particular applet speech capabilities. (Yeah, right. Does Java even HAVE sound yet?) A speech browser, given MathML-parsing ability, could speak an equation, but couldn't speak an image.

These last two reasons have nothing to do with Mozilla. What can this mean? Could this mean, possibly, that we're doing something in Mozilla that will eventually be of benefit to even those people who are not using it? Yes, it could and it does. By establishing MathML as a widely-used standard, Mozilla will make life easier for those using other browsers as well.

THE FUTURE

Yesterday, a friend asked me for help with a statistics assignment, part of which involved combinations -- for example, how many different combinations of 4 coins you can pick from a bag containing 40 separate coins. I couldn't remember the exact formula for combinations, but I did remember that it involved a fraction in which both the numerator (the top bit of the fraction) and the denominator (the bottom bit) had factorials in them. (A factorial (!) is what you get when you multiply a whole number by all the numbers from itself to 1 inclusive; for example, 4! = 4 * 3 * 2 * 1.)

Today, I could do a Web search for `combinations' and `formula' to try and find a page containing the relevant formula, but with search terms as general as that I wouldn't get very far at all.

Tomorrow, with widespread use of MathML on the Web, I could do a Web search (on a Web search engine which supported searching for raw XML tags, as most search engines would by then) for the exact MathML tags and content which my half-remembered formula contained. Or I could use a specialized search engine interface applet, which would allow me to visually construct the equation I was looking for (inserting `?'s where there were bits I couldn't remember), and which would then send the appropriate XML content to the search engine. The search engine would then scurry away and find all the pages containing such a formula, and if I specified that the word `combinations' must appear as well, I'd be almost certain to find something useful.

This is the power which MathML, and indeed all XML, will bring us. Can I, on the other hand, do a Web search for terms contained in a bitmapped rendering of an equation? Of course I can't.

On a more simplistic, futuristic level, imagine right-clicking on a MathML equation in Mozilla 7.0 for MacOS X, and seeing an item which had been automatically inserted in Mozilla's context menu by Apple's Graphing Calculator v3.0: `Solve for x'. You select the menu item, and the solved equation appears in the Graphing Calculator. How easily could you do that with an equation inserted as a bitmap? Quite simply, you couldn't.

CONCLUSION

It's just occurred to me that there are all sorts of parallels between the MathML-versus-GIF and HTML-versus-PDF debates. All of the reasons I have given for MathML's superiority over bitmapped math also apply to the HTML-versus-PDF issue -- speed of downloading, speed of rendering, ease of editing and maintaining, and flexibility in end use and rendering of the information.

Flexibility, in the end, is the most important issue. Bitmapped math, like PDF (and Macromedia's Flash, and Shockwave, and even those GIF text headings which we see on far too many Web pages) is extremely shallow. It allows only one way of meaningfully presenting the information -- directly accessing it, using a program which happens to be able to render it, in front of a person who happens to be able to see. And that's exactly what SGML and XML in general, and HTML and MathML in particular, were designed to get around. Because restricting the Web to visual gratification vastly limits its potential.

That's why the Web is built on HTML; that's why Mozilla supports XML; and that's why Mozilla will support MathML. Not because it will necessarily be good for Mozilla, but because it will be good for the Web.