Review MathML

[travisleithead]

Bonjour TAG,

I'm requesting a TAG review on behalf of XX (need to find the right folks):

• Name: MathML
• Specification URL: https://www.w3.org/Math/draft-spec/
• Explainer, Requirements Doc, or Example code: ?? No?
• Tests: (need to look)
• Primary contacts: TBD

Further details (optional):

• Relevant time constraints or deadlines: none
• I have read and filled out the Self-Review Questionnare on Security and Privacy. The assessment is here.
• I have reviewed the TAG's API Design Principles

You should also know that...

• MathML has been shipping in Mozilla for many many years now. Also in Safari 10+. Not shipping in Blink, Edge.
• Open question about relationship to web components, and longer term strategy to re-introduce high-level markup languages into the platform?

We'd prefer the TAG provide feedback as (please select one):

• open issues in our Github repo for each point of feedback
• open a single issue in our Github repo for the entire review
• leave review feedback as a comment in this issue and @-notify TBD

---

Please preview the issue and check that the links work before submitting

For background, see our explanation of how to write a good explainer.

[littledan]

Note that @fred-wang's MathML implementation note describes some more details about how MathML can be rendered and integrated into HTML.

[fred-wang]

During TPAC discussions, it appeared that not everybody in the TAG group was aware of recent MathML activities. Here is a quick summary:

• As @littledan mentioned, a MathML in HTML5 implementation note has been available for some time in order to simplify and improve the MathML 3 specification [1]. In particular, it is accurate enough to write cross-compatible WPT tests. After suggestion by Youenn Fablet (Apple) these tests were merged into the main WPT repository [2]. Two years ago, we (Igalia) sent various ideas for a future version of MathML to the Math WG mailing list. However, the Math WG has been inactive since that time.

• In 2014, Microsoft officially integrated Word's MATH table into the OpenType standard [3]. This has been used for the MathML in HTML5 implementation note and is supported by Mozilla and WebKit's MathML implementations. It is provided by various math fonts [4].

• MathML has shipped in Mozilla browsers since 2002 [5]. Recently, Emilio Cobos (Mozilla) has done some minimal maintenance of the code, especially to make it work with Stylo (Servo's CSS style system). At the web engines hackfest, we mentioned ideas to simplify Mozilla's implementation [6].

• WebKit has supported MathML since 2010 [7]. The implementation had some design issues and was only enabled for a short time in Chromium due to security and maintenance concerns (the code was completely removed after Blink fork). Two years ago, Igalia worked on a complete refactoring of WebKit's MathML code based on the MathML in HTML5 implementation note, making making these concerns obsolete [8].

• A bit more that one year ago, Igalia and Google's layout team agreed on a plan to implement MathML in Chromium, based on LayoutNG [9]. Then we have been waiting for LayoutNG to be stable enough (from Google's feedback, that should be the case very soon now) and in parallel have looked for sponsors for this project. One is already public: NISO announced they got a grant to support this effort [10].

We plan to announce and launch the MathML in Chromium project and to give further details very soon, after internal discussions.

[1] http://www.mathml-association.org/MathMLinHTML5/
[2] http://w3c-test.org/mathml/
[3] https://blogs.msdn.microsoft.com/murrays/2014/04/27/opentype-math-tables/
[4] https://developer.mozilla.org/en-US/docs/Mozilla/MathML_Project/Fonts#Fonts_with_a_MATH_table
[5] http://www.mozillazine.org/articles/article2278.html
[6] https://bugzilla.mozilla.org/show_bug.cgi?id=1495813
[7] https://webkit.org/blog/1366/announcing%e2%80%a6mathml/
[8] https://webkit.org/blog/6803/improvements-in-mathml-rendering/ and https://trac.webkit.org/wiki/MathML/Early_2016_Refactoring
[9] https://bugs.chromium.org/p/chromium/issues/detail?id=6606#c61
[10] https://www.niso.org/niso-io/newsline/2018/08/newsline-august-2018

[torgo]

Pinging @pkra and @zorkow on advice of Hadley and Sangwhan.

[TzviyaSiegman]

All STEM publishers (myself included) are greatly interested in this. We use MathML heavily and might be able to provide some resources.

[fred-wang]

Summary of our plan:

(1) We know that the MathML specification has design issues and is currently no longer maintained by the Math WG. Instead of just throwing it away and restarting something from scratch, we want a smooth transition to make it more aligned with the rest of the Web platform. The implementation note that we used for WebKit was one step in that direction and we are willing to do more. Basically, our idea is to extract a core subset (with some hints on how to keep backward compatibility for existing documents) and rely as much as possible on HTML5/CSS features (refining the implementation note while new features are introduced). Finally, TeX/OpenType algorithms/features and WPT tests are essential to provide accurate and consistent rendering across browsers. This is harder if one lets Web developers implement and maintain their own math rendering.

(2) Google is pushing for Houdini and layered APIs but things are far from being ready. In particular, they think they will only ship basic LayoutNG support in a few months and things like a font API (instrumental for math layout) are still in the planning stage. However, we agree with Google's layout team that this new layout approach is a good path forward. The plan is to start with a C++/LayoutNG-based implementation of MathML in order to see how much we are able to do while introducing new APIs as needed. In particular, an abstraction layer for HarfBuzz's OpenType MATH API would be helpful for the Houdini fonts API and to ensure it is good enough to fulfill the needs of math rendering. In the future, we could move to higher level implementations, always being careful that the WPT tests do not break and that we don't have significant performance regressions compared to the pure C++ implementations.

(3) Apple and Mozilla's plans for Houdini and Layered APIs are not clear at the moment. However, WebKit and Gecko already have MathML implementations. Our short-term plan is to refine/cleanup these implementations based on the standard evolution we are going to make in (1) and in the future we could rely on the outcome of (2) to further improve the implementations.

[davidcarlisle]

You linked to https://www.w3.org/Math/draft-spec/ but the currently maintained editors draft is
https://w3c.github.io/mathml/
even though the Math WG is currently not formally chartered issues raised in the public www-math@w3.org are still handled and if there was sufficient backlog of updates the plan has always been to go through the process of formally restarting a community or working group to update the published version.

At that time some integration with http://www.mathml-association.org/MathMLinHTML5/ would probably make sense.

[zorkow]

In my opinion it is time to think about deprecating MathML as a web standard. In
particular it does not do a good job in defining what rendered content actually
should look like and it would cost a lot of effort to get this right. Instead
increased efforts should be made to enhance other, successful web standards to
allow for easier rendering of maths (and related) content. Specifically,

• improvements to CSS in areas like stretchy characters, baseline alignment, etc.
  (See @arnog's presentation at TPAC.)

• ARIA support for content specific adaptations such as customised navigation,
  multi-channel output (speech, Braille, etc.).

Having said that, I still think that there is a place for MathML as a
representation language for mathematics in XML (e.g., in publishers workflows).
It's just inadequate and unnecessary as a web standard of its own.

[pkra]

Thanks for the ping @torgo.

I admit it's not clear (to me) what kind of input TAG is looking for, so I apologize if what follows isn't too useful.

I'll second @zorkow since I'm already on record calling for the deprecation of MathML from HTML5. However, this is a complicated discussion to have and I'm hesitant to have it on an issue thread.

My suggestion would be for TAG to engage with web developers who build the tools that are currently used for equation layout on the web (i.e., not using MathML but using CSS, SVG etc) to find out why they do not consider MathML an option (including the existing implementations). The MathOnWeb CG has a good representation of that group as well as supporters of MathML and our bi-weekly conference calls are open to everyone (disclaimer: I'm co-chair).

Personally, I think instead of a large monolithic spec like MathML, expressing layout in a way reminiscent of early HTML, the web would benefit from incrementally adding low level features to succcessful standards (e.g., CSS, SVG, ARIA) to help the web community at large. Reversely, MathML has been very succesful in the XML world outside of the web and it would be better if MathML could develop outside of HTML5 so as to serve the community that has found it useful.

At the risk of oversimplifying, I believe MathML adds no value to the web platform. Almost all necessary layout features of Presentation MathML are available in CSS and SVG. Those layout features that require hacks (in CSS or SVG) are becoming fewer and fewer (down to 3-5 issues depending on who you ask). Most of those are generally useful (e.g., better access to font features, easier baseline alignment, stretchy brackets) so it seems natural that those features should be realized as part of the relevant standards in a way that helps move the web forward as a whole.

The few layout features that are hard to reconcile with existing standards are, in my experience, not about MathML (which barely specifies layout to begin with) but are due to preferences stemming from print layout (e.g., the specifics of TeX layout). I'm not sure if realizing such details is a reasonable architectural goal for the web but either way it seems to be an independent problem.

The often ignored Content MathML presents a bit of a different problem. Besides there not being a lot of ContentMathML in the wild, it is very difficult to align visual layout with the way semantics are expressed in Content MathML (in part due to the highly formalized style of semantics). Content MathML also adds no value in terms of accessibility and there is a lack of tools that can leverage its semantics (e.g., search). Presentation MathML does not encode semantics in the usual sense (though it may appear to do so) and the few assistive technologies that try to support it heavily rely on heuristics to try to make sense of the markup. I think would be better to require heuristics at authoring time (to enhance legacy content) alongside general improvements to ARIA, AOM etc. to make it easier to expose additional information and simplify exploration of complex content fragments, both of which would benefit the larger community (e.g., diagrammatic content in STEM fields).

Overall, closing gaps in existing standards seems a much smaller task with a clearer benefit to the web as a whole than trying to salvage MathML.

[wycats]

I'd personally like to see MathML remain a standard. Like any other web standard, there are ways in which it would be useful to improve it to make it more usable for more use-cases, and ways to layer it better to provide better escape valves.

But that doesn't mean we should abandon a long-lived web standard that some people have found useful and that provides a reasonable starting point for further work.

If the argument is that people can do it in userspace instead, that may be an argument for excavating primitive underpinnings (with the collaboration of people already building alternatives in userspace). We're using this approach in TC39 to design improved temporal APIs in JavaScript that can serve to reduce the size and complexity of userspace libraries like moment.js.

Moving things to userspace, in contrast, increases the amount of shipping JS over time, something that we can all agree we should try to avoid.

[pshihn]

I created a web-component based MathML implementation: https://github.com/pshihn/math-ml
It's not full spec compliant but works quite well in most cases :
Demo using Torture test on MDN.

For those waiting for full native support, this might fill in gaps in the interim.

[NSoiffer]

It is disappointing that Chrome and Edge do not have native implementations of MathML. That lack has definitely hampered wider deployment of MathML on the web, at least in terms of visual display of math. I am encouraged by recent developments including the work at Igalia that @fred-wang mentioned along with the announcement from NISO that the Sloan Foundation is sponsoring a project to add MathML support to Chromium.

MathML has greatly enabled accessibility of math on the web. It is now the case that the major screen readers (JAWS, NVDA, VoiceOver) all support MathML as do many math-oriented websites (the MathML is typically invisible/hidden due to the lack of universal display). It is an understated success that someone who is blind can simply open a Wikipedia or Khan Academy page and (mostly) hear the math, review the math by navigating it, and read the math in braille on their refreshable display. The major limiting factor is that not all math in these pages uses MathML, but the vast majority does, especially for larger expressions. There is no jumping through hoops, no hitting special key combinations, it is simply read as part of the page.

The web has evolved since MathML first became a recommendation and I think it would be a good idea to work on a V4 for MathML that tackles some pain points in implementation. These include:

• better alignment with CSS and HTML
• detailed specification for layout
• potential addition of attributes to allow semantic "hints" such as subject area or function.

I'm sure other people can extend this list.

As @davidcarlisle and @fred-wang have mentioned, a very good start has already been done for the first two items, a strong indication that these are solvable problems. I agree with @pkra that the web would benefit from adding low level features to CSS and APIs to support math layout. Where I disagree with @pkra is the purpose of adding that support. I feel adding the support would ease the burden that browser developers face in supporting MathML and its math-oriented elements and hence lead to more browser implementations. Using layout support to justify removal of MathML because math can be displayed with styled <span>s is not a good idea for HTML5 and especially not for accessibility of math.

The third item in some sense also is already in use. Both MathPlayer (of which I am an author) and @zorkow's semantic enrichment engine in MathJax internally extend MathML to allow generation of more semantically meaningful speech (e.g., recognizing P(A|B) as a probability statement or AB with a line over it as a line segment). By making such a feature standardized in MathML, authors, authoring tools, and semantic enrichment algorithms could simplify the production of semantic speech in cases where the mathematical presentation is ambiguous. It also could ease the burden on search tools for semantic searching of math for those cases .

[bkardell]

For what it is worth, I have fairly complex thoughts on the topic that I tried to explain on my blog, but mostly I agree with what @wycats said. If approached well, getting an implementation in blink of the core set of things here can serve both the goals of those who have created significant volumes of/around MathML content and provide foundations and paths for those who want more/better. Feedback that I've received from many different groups within the web community seem to find that as generally a positive idea. I could be over-reading one end of the feedback, but mostly, any disagreement or uncertainty seems largely around how deep this excavation should go at once and concerns that it would stop 'too high' and punt on things that should be part of CSS, for example.

[dani31415]

We are talking about the implementation of MathML into the browsers. If we are going to do it, do it well, please! Otherwise it will be switch off again.

MathML has been criticized for being monolithic. What does it mean? My interpretation is that once you start writing MathML tags, you enter a different world with respect to HTML. The rules are not the same: some CSS do not work, you cannot mix other HTML tags, the font typesetting changes, etc. Can this be improved? If there is a general agreement about something we do not like about MathML, we can fix it. It is not easy but doable.

Another important property of HTML is that the layout provided by most of the current HTML tags are also available as CSS properties. See display=table|list-item|… or vertical-align=sup|super . Following this idea, it would be great to have display=fraction, display=underover and so on. These layouts would render any HTML element in a similar way as MathML but without some of the MathML limitations: you can use any HTML element as a child, the CSS styles are always applied in a standard way, the font typesetting does not change (or any style in general), the resulting fragment does not have semantics or accessibility implications (unless you add explicitly ARIA attributes), etc.

[fred-wang]

Another important property of HTML is that the layout provided by most of the current HTML tags are also available as CSS properties. See display=table|list-item|… or vertical-align=sup|super . Following this idea, it would be great to have display=fraction, display=underover and so on.

Just to clarify this, the point of Houdini's CSS layout API is exactly to allow defining this kind of user-defined display, so a priori it does not seem necessary to explicitly asks web engines developers to implement them natively (of course as long as users are fine implementing them in Javascript). As said above Igalia's MathML project will rely on LayoutNG (Chromium's C++ implementation of the CSS Layout API) so this is aligned with that goal and in the long term that could help to achieve your request. But IMHO at that time it's probably too soon to send such a request for new math-specific display values to the CSS-WG.

[clapierre]

Benetech has created a "Global Certified Accessible" program to certify publisher EPUB books have met the Accessibility 1.0 Conformance and Discovery Specification which is now under the W3C's domain. For STEM educational books which contain math publishers are encouraged to include mathML instead of just an image of the math equation.

Over the past two years the DIAGRAM Center has been working on a method to allow assistive technology access to the mathML for those reading systems which can understand the MathML and for those systems which can not we have a fallback solution proposed which uses SVG and an alt text description of the math. Testing of this technique is currently underway and the results of these tests will be posted on EPUBTest.org and MathSupportFinder

Publishers have millions of equations already in MathML format and they want to do the right thing and make their math accessible. Deprecating mathML completely from HTML without an accessible drop-in replacement in my opinion would be a detriment to those students who desperately need access to accessible math.

Work is currently underway to try and remediate some of the issues that has prevented widespread adoption of mathML in Browsers and the current fragmentation of mathML support.

The W3C has just deprecated the older versions of MathML in favor of the latest 3.0 spec. Let's not be too hasty and remove mathML completely from HTML since EPUB is built on HTML and most reading systems use HTML browser engine to render the EPUBs.

[NSoiffer]

FYI to TAG group: There is now a proposed CG to refresh the MathML spec. It has the required number of supporters and has been waiting for almost a week to become official. Hopefully that happens soon.

David Carlisle has already taken Frédéric's Wang's "MathML in HTML5" to produce a strawman HTML5 profile of a revised MathML spec. This is the beginning of an effort to specify exact layout rules for MathML on the web along with aligning MathML better for the web. Once up and running with our github repository, then issues relating to the spec and Igalia's implementation in Chromium can be tracked and commented on as requested by the Chrome team.

[cynthia]

We have discussed this during out Tokyo F2F - here is our official response. Apologies that this took so long.

---

Hey MathML fans!

We appreciate the feedback posted above and the passion for the technology which is apparent in your responses. We also appreciate the great work that is currently ongoing in the community and the MathML in HTML5 document is a fantastic example of this.

We’d like to see this community rally around creating the next iteration of the official MathML specification. As you know, there is currently no W3C Math Working Group, but that shouldn’t stop good innovation from proceeding to incubate the next iteration of the spec, for example in a Community Group.

We also have some high-level feedback from an architectural level that we’d like to offer.

MathML layering. In recent years, we’ve focused a lot on understanding and exposing the primitives that underpin higher levels of the web platform, and making those available to web developers in order to improve the platform’s extensibility. For examples, Web Components continue to make progress into explaining how HTML works. It’s important to us that the web platform have good layering, so that high-level MathML has as little “magic” as possible.

As the next version of MathML is developed, we encourage the designers to be mindful of places where a MathML element requires special platform behavior that is not available through any other means, and consider what primitives are missing that could generally make that behavior available (to reduce or eliminate) the “magic”. Of course, this may not be possible in all cases, but the places that do require it should be well understood and documented.

It looks like many folks are already thinking about how MathML can better integrate into the existing platform, and what redundant concepts can be removed, what minimal new features are necessary, etc. Of particular concern is the relationship between MathML and CSS. If MathML takes layout dependencies on concepts that are not supported in CSS, we would expect these concepts to be raised in the CSS working group for discussion. We appreciate the thinking that has already taken place and look forward to seeing the ensuing discussions.

Improved interoperability requirements: The previous MathML spec was developed before the evolution to more prescriptive and detailed specifications which has become the new norm for specifications. This increased level of detail helps avoid ambiguity in interpreting the spec, which in turn helps users and web developers avoid problems with interoperability between rendering engines. We’d like to see the MathML spec embrace this new spec-authoring norm for its next iteration. Case-in-point, many of us pointed out the Rendering section of the spec has an example where it would be extremely unlikely that multiple implementations could arrive at interoperable behavior based on the current spec’s content.

Tests: The other major factor that helps avoid interoperability problems between rendering engines is having a thorough set of conformance tests. It is becoming a de facto requirement for new standards to have accompanying tests anyway, so starting early for a language as large and complex as MathML will be essential.

We’re excited to see MathML take its next step forward. We believe that by following these architectural principles, implementers will be able to see the value and opportunity for interoperable Math in the web platform and join the effort. Thanks again for all your comments on this thread, and good luck!