Can you have an ebook format for education that doesn’t support math? (Note: it’s a rhetorical question!)

Math is pervasive, despite the common perception that it’s only for STEM. Even novels have been known to include equations from time-to-time.

And yet consumer-end MathML support in digital works is still lacking, despite two decades of work in W3C. If you want the whole story, Peter Krautzberger has written a fantastic article on the history of MathML and support in browsers that I’d highly recommend reading. I’m not going to attempt anything similar today, as there’s nothing of value a math neophyte like me could add.

Rather, what has me thinking MathML is the upcoming second EDUPUB conference, and the lack of consistent rendering, and voicing, of math in EPUB reading systems. In particular, how do we effect real change?

## Why MathML

But first, if it needs justification, there are lots of good reasons why we need MathML, not least of which is that math equations are not pictures — despite the prevalent belief to the opposite among web-goers.

I think there’s a tendency to forget that the pictures you get in ebooks today have to come from somewhere, and authors aren’t drawing them by hand. The problem is that MathML on the back-end doesn’t often see the light of day because support has been, and still is, so spotty. (I realize some people will have LaTeX behind the scenes, but assuming getting to MathML isn’t what prevents it being used in outputs.)

Math is a text format, so representing it as pictures is on par with adding pictures of headings or other text. Let me correct that, it’s worse than plain old text in images because describing a math equation is so much more complex. The alt text is rarely a one-to-one representation of the text in the image.

To cite the simple example I put in the book, what does the description “square root of a plus b” translate into? There are two ways to read it. With MathML (and voicing), anyone could figure out the correct interpretation, as the equation becomes part of the DOM and can be walked over. Without… well, you’re at the mercy of a description.

## Native support

Assuming you believe me that MathML is a key need for accessibility, why does native support in browsers, and by extension reading systems, matter so much? We’ve lived with plugins and polyfills this long, right?

While these solutions work for the web generally, neither represents a great solution for ebooks. Plugins, for example, simply aren’t viable for reading system apps. The reader has to use a browser to take advantage of them. And when you start putting restrictions on what devices and applications a reader can use, you ghettoize accessibility, which is what making accessibility a core tenet of a mainstream format like EPUB was intended to get away from.

To use Design Science’s plugin doesn’t mean only limiting yourself to IE9 and below (now that IE doesn’t support plugins), but means limiting yourself to only reading systems that directly run inside a browser.

Polyfills have greater range, but suffer a kind of impedance mismatch with ebooks and reading systems. For one, who implements the polyfill? Is it the reading system that lacks native support, or is it the content author who wants to ensure the ebook will render no matter the reading system?

And if it is the author, why is it incumbent upon them to integrate what is a rendering engine into their content? It’s bizarre — almost beyond words — for a standalone format, and barely more tolerable for regular web pages.

There are other technical reasons why native is better than code that has to be run at rendering time and/or live on top of the browser. Speed of rendering is a commonly cited one. Access to fonts another.

We’re lucky to have MathPlayer and MathJax to bridge the gap, don’t get me wrong, but ultimately the goal has to be integration into the core.

## Fixing the equation

So what can be done to improve the situation?

What is interesting from reading Peter’s article is how MathML is treated as peripheral technology not worth investing resources into. I can see that pre-HTML5, but I’d have expected that view to have changed with support being integrated. It’s odd, to say the least, that unless volunteers are working on these implementations they go nowhere.

That said, this lack of priority also gives a possible clue about what needs to be done. Either the organizational disinterest in supporting math needs to change, or developers need to be financed to finish the work (even if they’re volunteers as far as submitting the code goes).

There is a persistent belief that MathML is underused, because images are what appear in web and EPUB content. An analysis of web markup isn’t going reveal much of anything about the amount of MathML that flows through publishing, for example, or how much is stifled before it ever makes it out the door.

It might be time for a concerted push by the large publishers and/or publishing organizations to raise awareness that treating MathML development as a peripheral need has to change. A little heft couldn’t hurt.

Barring that, funding a developer to finish the WebKit code might be another alternative. If it is as key to digital publishing for education as I believe, finding that money shouldn’t require moving mountains. How it would go over with the browser engine folks I couldn’t say, but I’m only out to speculate on options.

Maybe I’m being naive and have stars in my eyes, but now that MathML is a core part of HTML5, pushing support over the final hurdles seems like a goal everyone can share.

Of course, MathML rendering doesn’t mean MathML voicing, so there are still hurdles, but we have to start somewhere.

But before I go off too long on this, I’ll wrap up by expressing how frustrating it is to have more “potential” for accessible math than actual support.

When I can’t convince myself that I’d trust MathML rendering… and unformatted math is as inaccessible for sighted readers as pictures of math can be for blind… well, that’s how we get stuck in these cycles.

It’ll be interesting to see what comes at this next EDUPUB meeting, and whether a strategy for MathML hits the radar.

> It might be time for a concerted push by the large publishers and/or publishing organizations to raise awareness that treating MathML development as a peripheral need has to change. A little heft couldn’t hurt.

> Barring that, funding a developer to finish the WebKit code might be another alternative. If it is as key to digital publishing for education as I believe, finding that money shouldn’t require moving mountains. How it would go over with the browser engine folks I couldn’t say, but I’m only out to speculate on options.

Are you aware of http://www.ulule.com/mathematics-ebooks/?

No, in fact, I wasn’t, but it’s somehow not surprising that I’m behind the curve on developments…

Thanks very much for sharing the link!

Thanks for your kind words about my piece at Programming. I agree that such a serious, long term effort seems the only way for native support right now. But it is a much more difficult project idea to pitch to potential sponsors than a polyfill or plugin (which is hard enough). For example, a browser project still needs a serious dedication from browser vendors — architectural support, a long term strategy for the code contributions, and a path towards vendors taking ownership of the MathML code base. Then, it’s difficult to gain long-term sponsors for such a project because of the impression of making a “gift” to Apple, Google, Mozilla and Amazon. (That doesn’t mean I won’t work towards such a project.)

By the way, my favorite personal reason in favor native support is that math (and science) deserve to move beyond MathML 3 — just like HTML deserved to move beyond HTML 4 (or 5 ;-) ). As good as MathML 3 is (and it is!), it is almost exclusively a conversion of printed mathematics. We have very few ideas right now what MathML 4 and 5 might look like, what a truly native expression of math on the web will look like. I’m eager to find out what people will come up with once they have MathML 3 at their universal disposal.

Thanks, Peter, and let me reiterate what a great article you wrote. It’s been some time since I’ve read such a fair and balanced presentation of the facts of a situation, and that’s on top of it being deeply interesting on its own.

My actual knowledge of MathML is inversely proporional to my interest, but I don’t let those sorts of facts stop me from writing!

The first EDUPUB conference really exposed the impact of inconsistent support of MathML and scripting on the ability to create educational material, so hopefully there’s some way to build on that. Scripting is more within the realm of what the EPUB WG itself can solve, but it’s easy to feel handcuffed by the interplay of support of other technologies that EPUB requires.

I realized in writing that any volunteered-in code would probably face long-term support problems, but I hadn’t considered the freebie angle of doing it ourselves. I suppose I was thinking that bridge had been crossed by volunteerism to date.

But if we can have initiatives to build an SDK, promote EPUB adoption and accessibility, and so on, it seems like there must a way to throw more muscle behind this issue, too.

Thanks for your kind words for my company’s MathPlayer product. I just wanted to point out that while it is a plugin for IE, in that each user has to install it into their browser, it makes use of IE’s really robust extension mechanism. One installed, it runs at native code speed and operates much like the code behind native HTML elements.

My point in saying this is that Microsoft could take our code and integrate it into IE so it no longer needs to be installed by each user. This would give future versions of IE a powerful native MathML installation. It puzzles me that Microsoft doesn’t even care enough about MathML to do this.

The problem with Microsoft and the other browser makers is that they do not hear requests for MathML support from people, other than from us insiders of course. I don’t think most educators and AT people know enough about MathML to make such requests or they are not in the same world as the browser makers. As Frédéric Wang suggests, perhaps it is time for some kind of grass roots effort to get the word to them. However, publishers do understand about MathML as they’ve been using it internally for years. It is the education community that needs to be reached. Big companies like Microsoft and Google are very interested in supporting education. Education needs to be told what to ask for to get math support in browsers.

I’d definitely call it the gold standard, as you guys do an amazing job with with the rendering and the voicing. It’s interesting to hear you posit integration, as I wouldn’t have assumed that course for you. I’m surprised Microsoft wouldn’t take you up on it, as it would put them leaps and bounds ahead of everyone else, and give them a big edge in education. No doubt there’s a lot of inertia that has to be overcome in a lot of quarters to get support moving.

And while much EPUB 3 app development is WebKit-based, we still need core support across all browser cores, as EPUB is only one dimension. Accessibile math on the web is equally important, not that I need to tell you, if out-of-scope for what I was looking at. Nothing but good could come of integration, in other words.

FYI — The MathFlow product from Design Science, which allows easy editing and manipulation of MathML equations, has been integrated with the latest version of Adobe FrameMaker 12. Adobe also has a new, less expensive XML-only editor, FrameMaker XML Author 12, which supports this product. In either product, you can go into the XML code view of FrameMaker and see the XML display of MathML equations. Hopefully this will help spur acceptance.

As you now know Maxwell, companies like ours are using the FM XML editor and rendering to tekReader (our HTML5 eReader) in the cloud, including MathML using MathJax!

Thanks for the article.

Many folks in the AT community are aware of the need for native MathML support in EPUB reading systems but we lack sometimes a systematic way of making our voices heard. The CSUN conference offers us some opportunity to voice concerns to the big companies, yet we are often left with unanswered requests for support.

We recently posted a request to various a11y listservs that they vote for inclusion of MathML in the Edge browser.

So far, the vote tally is at 4,035 and counting:

https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/6508572-mathml

Let’s hope that they heed our voice this time.