# Review MathML #313

Open
opened this Issue Oct 29, 2018 · 11 comments

Projects
None yet
Contributor

### travisleithead commented Oct 29, 2018

 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 commented Oct 29, 2018

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

### fred-wang commented Oct 30, 2018 • edited

 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.

Member

### TzviyaSiegman commented Oct 30, 2018

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

### fred-wang commented Nov 1, 2018

 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 commented Nov 2, 2018

 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 commented Nov 2, 2018

 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.

Member

### wycats commented Nov 5, 2018

 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 commented Nov 5, 2018

 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 commented Nov 7, 2018

 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 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 .

Open