New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Review MathML #313

Open
travisleithead opened this Issue Oct 29, 2018 · 11 comments

Comments

@travisleithead
Contributor

travisleithead commented Oct 29, 2018

Bonjour TAG,

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

Further details (optional):

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

This comment has been minimized.

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

This comment has been minimized.

fred-wang commented Oct 30, 2018

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

@dbaron dbaron self-assigned this Oct 30, 2018

@dbaron dbaron assigned cynthia and slightlyoff and unassigned hadleybeeman Oct 30, 2018

@torgo

This comment has been minimized.

Member

torgo commented Oct 30, 2018

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

@TzviyaSiegman

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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.

@pkra

This comment has been minimized.

pkra commented Nov 2, 2018

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment