The W3C announced October 21, 2010 that the MathML 3.0 specification is a W3C Recommendation. This post describes some of the features added to MathML in version 3.0. The specification also includes numerous clarifications that are helpful for people wanting to implement MathML 3.0. The specification’s introductory section “Status of this Document” concludes with a summary of the features.

### Improved Unicode Alignment

In February 2001 when the “first edition” of MathML 2.0 became a W3C Recommendation, Unicode/ISO 10646 was still officially missing many math symbols. Unicode 3.1 (May, 2001) added the Unicode math alphanumerics (U+1D400.U+1D7FF) and the differential-d set (U+2145..U+2149). Unicode 3.2 (March, 2002) added the lion’s share of remaining math symbols in the STIX set, including the arrows and math operators in the range U+2900..U+2AFF. The “second and current edition” of MathML 2.0 was released in October 2003 partly to re-align with Unicode and to include math character blocks instead of private use area code points. The operator dictionary did not include Unicode code points.

MathML 3.0 is fully aligned with Unicode 6.0+. In addition to the discussions of the Unicode math character sets in Chapter 15 of The Unicode Standard, Unicode Technical Report #25, and Unicode Technical Note #28, MathML 3.0 adds a thoroughly revamped math operator dictionary featuring Unicode and giving basic operator properties. Complementing this is the new W3C Recommendation XML Entity Definitions for Characters, which incorporates all standard entities used for mathematics. In particular, Section 3 of this document features Unicode blocks of characters that you can mouse over to see relevant math properties. Each character is displayed twice, once with a STIX font and once with a png.

### Right-to-Left Math

The earlier posts Tailoring the Unicode Bidi Algorithm and Directionality in Math Zones discuss right-to-left (RtL) math and give useful references for further study, notably Arabic mathematical notation. MathML 3.0 includes full support for RtL math zones, including a directionality attribute, dir, which can appear on most elements. If the dir attribute does not appear, the directionality of the <math> element and children is inherited from the current Bidi embedding. Adil Allawi of Diwan Software Limited notes (in a private communication) that the right-to-left features of MathML 3.0 make “it possible, for the first time, to build standards-based and truly interoperable electronic maths books for students in the Arab countries.”

### Elementary math

People write long division and multiplication in various ways around the world. Particularly for educational purposes, it is desirable to have an interchangeable format to represent such conventions on the web and in other electronic media. Accordingly, MathML 3.0 defines elements to handle many such conventions. The facility allows special alignments as well as borrow/carry annotations.

### Accessibility

MathML is supported by various accessibility tools and has been incorporated into the DAISY Standard. Adding MathML 3.0’s elementary math capabilities widens the range for accessible math.

### CSS for math

In a companion specification, a subset of MathML 3.0 is described that can be rendered with CSS. This allows browsers that do not have sophisticated math layout engines to display many mathematical formulas.

### Line breaking

MathML 3.0 includes a very rich set of attributes. Office 2010 implements a subset that handles the most common scenarios, including options to display duplicated operator as ++, +-, –, but it is not nearly as general. For example, MathML 3.0 allows breaking at an arbitrary character position with a wealth of possible indents/alignments for the wrapped line(s).

### href’s everywhere

You can put an href (hyperlink) attribute on most any element in MathML 3.0. This makes it easy, for example, to provide links on a fraction numerator or denominator. Such links can aid the teaching of mathematics as well as to define the meanings of expressions.

### Padding

The <mpadded> element has been generalized and clarified. This can be useful for tweaking the positioning of arguments for printing. Caveat emptor: since math layout engines often differ in their spacing choices, tweaking for one engine may spoil the spacing for another engine. The elements <mglyph> and <maction> are also motivated and described more thoroughly.

### Content MathML

A substantial effort has gone into improving Content MathML, notably in allowing a rigorous correspondence to OpenMath with its content dictionaries. This work is valuable for symbolic and numerical computations.

### Mixing Markup

One reason Microsoft Office went with its own “Office MathML”, that is, OMML, was to be able to combine a math XML with parent namespaces, such as WordProcessingML. MathML 3.0 has generalized the <semantics> element and clarified various scenarios to make such mixing of namespaces more convenient.

### What’s not yet done

A number of things were postponed for future consideration. Document math defaults have not been specified. These include the default math font, equation alignment(s), space before/after, breaking conventions, n-ary/integral limit placements, all of which are specified in the OMML <mathPr> element. The power of the OMML math paragraph is also missing, although to some degree it can be emulated by the <mtable> element. Equation numbering is not represented, nor is it in OMML. The feeling of the MathML working group is that these concepts belong to the document container in which the MathML <math> elements reside. However, I think that some discussion should be given to lend a degree of interoperability to these concepts, which are clearly very important for the electronic representation of mathematical text. An example of the problem is that one browser currently left aligns equations by default, whereas the common convention is to center equations.

### What becomes of WG?

When the MathML 2.0 Working Group finished the MathML 2.0 specification, the group dissolved. It took some time to put it back together for MathML 3.0. Therefore, the plan for the future is to keep the group active with no specific agenda other than to maintain the spec, answer questions, and dream about the future. Something as complex and important as MathML needs a live pool of expertise.

See also Neil Soiffer’s blog about MathML 3.0.

If only IE could support this out of the box!

Obviously, it will not happen for IE9 (we got XHTML and SVG, no complaint). I wonder whether the IE team has started to look for people with previous experience in math rendering, e.g. in Office.

Maybe you could talk them into implementing MathML for IE10?

Yes it would be great if IE could support MathML out of the box. A lot of the infrastructure is in place already, but it is work to finish the job and the IE team continually has to prioritize which "must have" features to implement next. Naturally I think MathML is at the top of the list :-), but other people have different opinions. There is an excellent option for displaying MathML in IE, namely the Design Science MathPlayer (please Bing it if you're interested).

Has Design Science started to think about security? I don't see anything on their web pages about security updates. Either they write perfect code, or their have so little exposure that they don't bother about possible issues. Except for the time on the IE blog when they were recommending to disable local machine zone lockdown because they couldn't see the point. As it stands, I don't trust their code in as exposed a place as a web browser.

Regarding prioritizing, I agree that the IE team has a lot on their plate and that it makes sense that demands for MathML will come after stuff that will be used everywhere on the web. However, there are a few people (more than I expected) who have filed suggestions regarding MathML on Connect, and of course MathML is part of HTML5. I hope that it will be enough so that the job is not endlessly postponed.

This is the first I have heard about MathPlayer being considered a security risk. I would be interested in a link to the blog post in question where we at Design Science "couldn't see the point". If you or anyone else know of security holes in MathPlayer, we would certainly follow up. We have not received any reports of security issues or vulnerabilities. It is hard to prove that software is secure, of course, but I can guarantee we would follow up on any reported problems. We do update MathPlayer when necessary. In fact, we are updating it now to support MathML 3's new features. We believe MathPlayer supplies the best MathML support among all browsers and intend to keep it that way.For example, our support for accessibility is superior.

@Paul Topping: Any browser plugin is a security risk. The least you could do is to make clear how you try to minimize the risks. Not saying anything about security on your web site is very poor practice. Look at Microsoft's investment in SDL, with publicly stated development practices and publicly available security bulletins. Look at Adobe following the same path. If you want to know about vulnerabilities, reach out to security researchers and ask them to try some fuzzing tools on your code. Unless you are already doing it (and your comment about the absence of reports on vulnerabilities suggests you aren't), it's a near certainty that there is a lot to be fixed. (Don't ask me, that's not my job, I'm only commenting on how much I distrust plugin developers that do not invest in protecting their users.)

Regarding not getting the point of machine zone lockdown, I'm referring to comments by Neil Soiffer on this page: blogs.msdn.com/…/385230.aspx .

@Lionel: I took a look at how other plugin vendors deal with this. I don't see any evidence that any of them make a statement about security. They can't guarantee security so what's would the point be anyway? Such a statement would only scare normal users unnecessarily. As you point out, any browser plugin is a security risk and there are no absolute guarantees possible.

The lack of reports on MathPlayer security vulnerabilities does not suggest we are not concerned about security. I think it indicates that either MathPlayer doesn't have any vulnerabilities or no one has found them yet. I am not going to go into what steps we have taken internally to ensure security. That would be dumb as some malicious person might be reading this.

Your reference to Neil Soiffer's comment is also unfair. He works on accessibility and math formatting, not testing and security. He is responding to a blog post on accessibility in IE. Whatever he says about security should not be taken out of that context.

Wow, some of these 3.0 additions seem pretty minor. Hopefully that's an indication of the completeness of MathML.

The solution is not to shoot the plugin maker. The solutions is for IE team to stop dragging their feet, and catch up

with Firefox.

Firefox version 3 has excellent MathML support, and it improves again with Firefox 4.

Yes I appreciate that the IE team have been busy catching up with other standards, but I am afraid that was the fruit of previous strategy. Not the end users fault at all.