Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Review MathML #313
I'm requesting a TAG review on behalf of XX (need to find the right folks):
Further details (optional):
You should also know that...
We'd prefer the TAG provide feedback as (please select one):
Please preview the issue and check that the links work before submitting
For background, see our explanation of how to write a good explainer.
During TPAC discussions, it appeared that not everybody in the TAG group was aware of recent MathML activities. Here is a quick summary:
We plan to announce and launch the MathML in Chromium project and to give further details very soon, after internal discussions.
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.
You linked to https://www.w3.org/Math/draft-spec/ but the currently maintained editors draft is
At that time some integration with http://www.mathml-association.org/MathMLinHTML5/ would probably make sense.
In my opinion it is time to think about deprecating MathML as a web standard. In
Having said that, I still think that there is a place for MathML as a
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.
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.
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.
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.
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:
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
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 .