# Intent to Ship: MathML

516 views

### Frédéric Wang

Jun 22, 2022, 5:48:35 PM (13 days ago) Jun 22

#### Contact emails

fw...@chromium.org, rb...@chromium.org, bkar...@igalia.com

#### Explainer

https://github.com/mathml-refresh/mathml-core/blob/master/docs/explainer.md
https://people.igalia.com/fwang/explainer-font-family-math

#### Specification

https://mathml-refresh.github.io/mathml-core

#### Design docs

https://drafts.csswg.org/css-fonts-4/#valdef-font-family-math
https://w3c.github.io/mathml-aam

#### Summary

Adds native DOM/IDL, accessibility support and CSS-compatible OpenType-based layout of mathematical formulas. The reference specifications are MathML Core (which describes in extensive details a fundamental subset of the MathML 3 recommendation), MathML AAM (which describes mapping to platform accessibility APIs). This includes the "math" font-family as well as features included in section "CSS Extensions for Math Layout".

mathml

#### TAG review

https://github.com/w3ctag/design-reviews/issues/438 https://github.com/w3ctag/design-reviews/issues/313#issuecomment-460523527

#### Interoperability and Compatibility

- This is not implementing the complete list of MathML3, OpenType MATH or accessibility features that one can find in other browsers.

- New enhancements (e.g. clarification regarding CSS interoperability) may not be implemented in other browsers yet.

- MathML Core and MathML AAM are still working drafts.

Gecko: Shipped/Shipping

WebKit: Shipped/Shipping

Web developers: Positive (https://twitter.com/search?q=mathml%20chrome&f=live) Users have recently been excited about it, experimented exiting implementation under a flag and are eager to see it shipped soon. It is currently the 5th most starred Blink issue, see https://bugs.chromium.org/p/chromium/issues/list?can=2&q=component:Blink&sort=-stars&colspec=ID%20Stars%20Pri%20Status%20Component%20Opened%20Summary

Other signals:

#### Ergonomics

In the past, MathML trees were not treated specially at all and this was fast ! Now, more work is needed for pages that do math rendering e.g. accessing data from the MATH table, handling operator dictionary, using ink text bounds, performing low-level shaping of stretchy operators, loading and applying CSS UA sheet, or exposing an accessibility tree. However, the only performance report we received so far was issue #1073760, which was discarded after further analysis. In any case, performance is definitely better than existing non-native technologies. Additionally, pages will likely need loading WOFF fonts on operating systems that don't ship math fonts. Work is in progress here, see https://frederic-wang.fr/update-on-open-type-math-fonts.html for recent status.

#### Activation

- Editing MathML source is difficult but special authoring tools & converters do exist.

- Implementation may not be as complete as expected by users but the spec tries to allow extensibility and the Math WG provides polyfills at https://github.com/mathml-refresh/mathml-polyfills

- Users may require WOFF fonts to properly render formulas (see above).

#### Security

There is a risk due to the new attack surface:

- Relatively large amount of new code.

- Newly exposed APIs.

- Interacting with several parts of the web platform.

However, risks related to violation of layout algorithm are reduced now that the specification clarifies how to perform it in a CSS-compatible way. We've fixed 17 issues reported during 2.5 years of development and there are currently 0 open security issues (last report was in March).

Finally, similar security & privacy considerations as existing layout specifications apply, see the relevant sections from the MathML Core spec: https://w3c.github.io/mathml-core/#security-considerations https://w3c.github.io/mathml-core/#privacy-considerations

#### WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No.

#### Debuggability

- Nothing particular expected besides what is already provided for SVG and HTML.

- Existing devtools API was extended to handle "font-family: math", see https://chromedevtools.github.io/devtools-protocol/tot/Page/#method-setFontFamilies

Yes

Yes

MathMLCore

#### Requires code in //chrome?

True (this is only to implement support for “font-family: math”, which has a user preference menu for math font, see https://docs.google.com/document/d/1bvY_Npe2zLW_705KXdmecsH6P9I9wBMpHRsZ9CxWNOI/edit#heading=h.u9hwm9tp8nuy).

#### Tracking bug

http://crbug.com/6606

https://people.igalia.com/fwang/2022-06-igalia-week-shipping-mathml-in-chromium/#/12
https://fred-wang.github.io/MathFonts

#### Estimated milestones

 DevTrial on desktop 103
 DevTrial on Android 103

#### Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

https://github.com/w3c/csswg-drafts/issues/5866
https://github.com/w3c/mathml-core/issues/77

#### Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5240822173794304

#### Links to previous Intent discussions

This intent message was generated by Chrome Platform Status.
--
Frédéric Wang


### Frédéric Wang

Jun 22, 2022, 5:51:07 PM (13 days ago) Jun 22
to blin...@chromium.org

Hello,

My previous email was generated from the information of chromestatus.com ; I’d like to elaborate a bit more about the situation of MathML in Chromium. In 2019, we published a roadmap [1] which we basically implemented downstream the same year. As of today, we consider this roadmap complete upstream, modulo imperfect math layout of stretchy operators due to the limitation of the current LayoutNG architecture (the rendering team is aware of that and consensus is that it’s ok for a first implementation).

In addition, we have been receiving feedback from various people and tried to adjust our initial roadmap accordingly:

1. Some concerns were shared by some browser vendors, TAG members or some participants to the “Getting Math onto Web Pages CG” and are summarized on the official TAG’s feedback [2]. During these recent years, we’ve collaborated with the MathML and CSS working groups as well as browser vendors to publish specifications & tests that address these concerns. This also added many new tasks on the roadmap (e.g. new CSS properties, MathMLElement IDL, mixing with CSS/SVG, etc).
2. MathML supporters have also been asking a more complete support for MathML3 features, raising concerns about backward compatibility. Apple shares this concern about breaking content from their applications (e.g. Apple Books) and is generally reluctant to remove shipped features. Mozilla has been more positive about that and several patches landed to unship legacy features with low usage. We decided to solve that disagreement by publishing two specifications: MathML Core (intended to be implemented in browsers) and a superset called “MathML Full”. Polyfills for MathML features that are not part of the core spec have also been written. Incidentally, the layering/extensibility effort for (1) became instrumental to write such polyfills.
3. We also received feedback about making MathML accessible, so we added that in our plan. We implemented parity with Gecko/WebKit for macOS/NSAccessibility and Linux/ATK. We’ve also been working on a corresponding MathML AAM specification to standardize existing support and we wrote (currently internal) tests for that. Other platforms (Windows, ChromeOS, Android) don’t seem to have any special way to expose MathML nodes to assistive technologies, so instead we continue to rely on existing DOM-based approaches.
4. Finally, a lot of users have praised our work, tested existing support by enabling web platform features, reported bugs and they keep asking us when this is going to be officially shipped. Hopefully this intent-to-ship will allow to address that last feedback :-)

At that time, we believe the implementation is good enough for a first release. To be fully transparent these are known issues:

• There are bugs to fix or more features users would like to see. We expect the layering/extensibility approach will make possible to work around current limitations.
• Not all operating systems come with a pre-installed OpenType MATH font, which means poor math rendering on such systems by default. However, Windows has Cambria Math pre-installed and things seem to improve on the macOS & Android side [3]. The workaround for that is to use web fonts (on pages or as a web extension).
• There are a few interactions with CSS properties (e.g. width/height, out-of-flow, etc) that we would like to clarify in the spec and/or the implementation and ensure we have interoperability tests for that. These are likely edge cases for MathML authors but can be important for polyfills.

That’s it, we are looking forward to hearing your feedback !

--
Frédéric Wang


### Chris Harrelson

Jun 22, 2022, 7:43:01 PM (13 days ago) Jun 22
This is very exciting! A couple of questions below.

They ship MathML, but could you speak to the conformance level with the Core spec? In cases where there are gaps, are they going to cause significant web compat issues that will need to be addressed with implementation improvements to other browser implementations?

Relatedly, is it the case that the Chromium implementation passes all of the WPT tests and is in complete agreement with the Core spec?

Web developers: Positive (https://twitter.com/search?q=mathml%20chrome&f=live) Users have recently been excited about it, experimented exiting implementation under a flag and are eager to see it shipped soon. It is currently the 5th most starred Blink issue, see https://bugs.chromium.org/p/chromium/issues/list?can=2&q=component:Blink&sort=-stars&colspec=ID%20Stars%20Pri%20Status%20Component%20Opened%20Summary

Other signals:

#### Ergonomics

In the past, MathML trees were not treated specially at all and this was fast ! Now, more work is needed for pages that do math rendering e.g. accessing data from the MATH table, handling operator dictionary, using ink text bounds, performing low-level shaping of stretchy operators, loading and applying CSS UA sheet, or exposing an accessibility tree. However, the only performance report we received so far was issue #1073760, which was discarded after further analysis. In any case, performance is definitely better than existing non-native technologies. Additionally, pages will likely need loading WOFF fonts on operating systems that don't ship math fonts. Work is in progress here, see https://frederic-wang.fr/update-on-open-type-math-fonts.html for recent status.

#### Activation

- Editing MathML source is difficult but special authoring tools & converters do exist.

- Implementation may not be as complete as expected by users but the spec tries to allow extensibility and the Math WG provides polyfills at https://github.com/mathml-refresh/mathml-polyfills

- Users may require WOFF fonts to properly render formulas (see above).

#### Security

There is a risk due to the new attack surface:

- Relatively large amount of new code.

- Newly exposed APIs.

- Interacting with several parts of the web platform.

However, risks related to violation of layout algorithm are reduced now that the specification clarifies how to perform it in a CSS-compatible way. We've fixed 17 issues reported during 2.5 years of development and there are currently 0 open security issues (last report was in March).

Finally, similar security & privacy considerations as existing layout specifications apply, see the relevant sections from the MathML Core spec: https://w3c.github.io/mathml-core/#security-considerations https://w3c.github.io/mathml-core/#privacy-considerations

#### WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No.

#### Debuggability

- Nothing particular expected besides what is already provided for SVG and HTML.

- Existing devtools API was extended to handle "font-family: math", see https://chromedevtools.github.io/devtools-protocol/tot/Page/#method-setFontFamilies

#### Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

You mentioned in your other email that some platforms don't have good enough pre-installed Math fonts. It seems your recommendation would be to make sure STIX Two Math is installed, and macOS will have that soon.

Have you inquired about ChromeOS also?

What will math look like on platforms that don't have a pre-installed font, and for pages that don't use a web font? Will it not render at all or render with illogical fallback glyphs?

--
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

### Frédéric Wang

Jun 23, 2022, 3:40:10 AM (13 days ago) Jun 23

Resending since it seems the email failed to be delivered...

-------- Forwarded Message --------
Subject: Re: [blink-dev] Intent to Ship: MathML Thu, 23 Jun 2022 09:24:43 +0200 Frédéric Wang Chris Harrelson blink-dev

They ship MathML, but could you speak to the conformance level with the Core spec? In cases where there are gaps, are they going to cause significant web compat issues that will need to be addressed with implementation improvements to other browser implementations?

Chromium implements MathML Core which is smaller than what WebKit & Gecko have today. If authors stick to formulas based on the core subset (which we believe should the case for the majority of existing content), the interoperability is quite good as can be see visually with https://people.igalia.com/fwang/2022-06-igalia-week-shipping-mathml-in-chromium/#/5 VS https://people.igalia.com/fwang/2022-06-igalia-week-shipping-mathml-in-chromium/#/6

In practice interop gaps are more likely to come with existing MathML3 content that rely on more features. Our proposal is to rely on polyfills so they work in Chromium too and to try to carefully deprecate & unship these legacy features from WebKit/Gecko.

Additionally, if/when web authors & developers start to make use of them, then we foresee some interop gaps will happen with the new math-related CSS properties proposed to expose the internal magic (display: math, font-family: math, math-style, etc) as well as interaction with existing CSS properties (e.g. padding/margin/borders to tweak spacing).

So the short answer is that yes there is likely to be interop gaps and yes some work will be needed on the WebKit/Gecko side. Igalia actually already started to unship legacy features from WebKit (under a flag) and Gecko and did a few improvements regarding the CSS part. We've been focusing mostly on Chromium since that's where the biggest & most serious interop gap exist for users (no MathML support at all!) but it's very possible we'll put more effort on Gecko/WebKit after that (that's my personal preference but work sponsors may have a different opinion).

Relatedly, is it the case that the Chromium implementation passes all of the WPT tests and is in complete agreement with the Core spec?

Good question and this is what I presented during the Web Engines Hackfest: https://people.igalia.com/fwang/2022-06-igalia-week-shipping-mathml-in-chromium/#/11

The 3 categories of failures are the following:

1. A large amount of WPT failures are related to CSS text-transform (https://w3c.github.io/mathml-core/#new-text-transform-mappings) and the mathvariant attribute (https://w3c.github.io/mathml-core/#the-mathvariant-attribute). There were some disagreements between CSS and a11y folks in general here (see https://github.com/w3c/csswg-drafts/issues/3775) and the outcome of the math-related proposal ( https://github.com/w3c/csswg-drafts/issues/5386 ) was only to support automatic italic of variables. Some members of the Math CG feel strongly about keeping the mathvariant attribute for backward compatibility with existing content but as mentioned in the spec, one can actually just use the Unicode characters after transformation. So we didn't consider critical to try to push harder for this on the CSS side, even if we have a patch ready for that ( https://bugs.chromium.org/p/chromium/issues/detail?id=1076420 ).

2. Another feature that was initially planned is the href attribute. One of the issue here is that MathML3 allows links on *all* MathML elements (rather than just e.g. a dedicated <a> element). Emilio Cobos from Mozilla raised the issue about the complexity cost of that choice. For example there are some privacy concerns related to the :visited selector which requires to implement mitigation, links also needs special to work with the tabindex attributes, etc Also at the WHATWG, it was decided a long time ago that linkable elements should not be able to have a shadow DOM (I believe it was for security reason) which we feel would prevent some interesting use cases for extensibility of MathML elements. At the end, we decided to remove href from the MathML Core specification for now as they are not really the most critical part of MathML and will discuss it for a future version, but existing tests written for WebKit/Gecko are still there. For details see https://github.com/w3c/mathml-core/issues/142 and https://github.com/w3c/mathml-core/issues/63 https://github.com/w3c/mathml-core/issues/69

3. Finally, the remaining important failures are related to interpretation of CSS specifications (e.g. width/height, out-of-flow, display, etc) as mentioned at the end of my second email. Again MathML authors don't really care about this and we have freedom to choose how we interpret these CSS properties as long as that doesn't break existing content. However, we believe it can be quite critical and a source of interoperability concern if people start to write polyfills and the like on top of MathML. Here, the issue is that the MathML CG proposed resolutions to issues, but Chromium reviewers suggested a different approach during the implementation phase so we have inconsistencies between spec and implementation, and even sometimes between two tests. These points were discussed at the hackfest ( https://people.igalia.com/fwang/2022-06-igalia-week-shipping-mathml-in-chromium/#/13 ) and fixing that is the very next task to tackle on our list.

The rest of the failures are less concerning from an interop point of view, they are either due to some bugs that can be fixed in Chromium (e.g. implement the new onbeforeload event attribute) or some issues with the design of legacy MathML tests (e.g. not relying on a web font for better accuracy).

You mentioned in your other email that some platforms don't have good enough pre-installed Math fonts. It seems your recommendation would be to make sure STIX Two Math is installed, and macOS will have that soon.

Have you inquired about ChromeOS also?

What will math look like on platforms that don't have a pre-installed font, and for pages that don't use a web font? Will it not render at all or render with illogical fallback glyphs?

So this is a quotation from the "font-family: math" design doc: "The math font family is intended for displaying mathematical expressions. Such expressions not only require special symbols but also extra data provided by the OpenType MATH table such as dedicated layout parameters or stretchy constructions. Except for very simple cases, mathematical formulas will render poorly without such a math font."

https://frederic-wang.fr/update-on-open-type-math-fonts.html provides some screenshots with Cambria Math (shipped on Windows), STIX Two Math (shipped on macOS13 Ventura beta, packages available in most Linux distros) and Latin Modern Math (packages available in most Linux distros and likely to be installed with TeX).

Regarding ChromeOS and Android, i understand they both ship Roboto & Noto families. There is a Noto math font which addresses the "No Tofu" for mathematical symbols from the relevant unicode blocks ; this is enough for simple math and even makes more complex formulas readable. However, it currently lacks an OpenType MATH table and so won't work well with more advanced constructions that require glyph stretching, proper spacing, and the like. I'm attaching screenshots of Chromium 102, Firefox 101 and WebKitGTK 2.36.3 on Linux with Noto Sans Math vs STIX Two Math vs Latin Modern. Note that Chromium won't stretch the radical symbol and won't make the integral big ; WebKit works around the first issue by using a scale transform (glyph distorted) while Gecko works around both of them by fallbacking to an available OpenType MATH fonts on the system (glyphs from Latin Modern Math).

Again we discussed this during the hackfest. We proposed to consider the STIX font but it seems others are currently considering to add a MATH table to the Noto Sans Math font: https://github.com/notofonts/math/issues/14#issuecomment-1161414437

--
Frédéric Wang

latin-moder-math-stix-two-math-noto-sans-math.html
firefox-latin-moder-math-stix-two-math-noto-sans-math.png
epiphany-latin-moder-math-stix-two-math-noto-sans-math.png
chromium-latin-moder-math-stix-two-math-noto-sans-math.png

### Frédéric Wang

Jun 23, 2022, 3:56:00 AM (13 days ago) Jun 23

They ship MathML, but could you speak to the conformance level with the Core spec? In cases where there are gaps, are they going to cause significant web compat issues that will need to be addressed with implementation improvements to other browser implementations?

Chromium implements MathML Core which is smaller than what WebKit & Gecko have today. If authors stick to formulas based on the core subset (which we believe should the case for the majority of existing content), the interoperability is quite good as can be see visually with https://people.igalia.com/fwang/2022-06-igalia-week-shipping-mathml-in-chromium/#/5 VS https://people.igalia.com/fwang/2022-06-igalia-week-shipping-mathml-in-chromium/#/6

In practice interop gaps are more likely to come with existing MathML3 content that rely on more features. Our proposal is to rely on polyfills so they work in Chromium too and to try to carefully deprecate & unship these legacy features from WebKit/Gecko.

Additionally, if/when web authors & developers start to make use of them, then we foresee some interop gaps will happen with the new math-related CSS properties proposed to expose the internal magic (display: math, font-family: math, math-style, etc) as well as interaction with existing CSS properties (e.g. padding/margin/borders to tweak spacing).

So the short answer is that yes there is likely to be interop gaps and yes some work will be needed on the WebKit/Gecko side. Igalia actually already started to unship legacy features from WebKit (under a flag) and Gecko and did a few improvements regarding the CSS part. We've been focusing mostly on Chromium since that's where the biggest & most serious interop gap exist for users (no MathML support at all!) but it's very possible we'll put more effort on Gecko/WebKit after that (that's my personal preference but work sponsors may have a different opinion).

Relatedly, is it the case that the Chromium implementation passes all of the WPT tests and is in complete agreement with the Core spec?

Good question and this is what I presented during the Web Engines Hackfest: https://people.igalia.com/fwang/2022-06-igalia-week-shipping-mathml-in-chromium/#/11

The 3 categories of failures are the following:

1. A large amount of WPT failures are related to CSS text-transform (https://w3c.github.io/mathml-core/#new-text-transform-mappings) and the mathvariant attribute (https://w3c.github.io/mathml-core/#the-mathvariant-attribute). There were some disagreements between CSS and a11y folks in general here (see https://github.com/w3c/csswg-drafts/issues/3775) and the outcome of the math-related proposal ( https://github.com/w3c/csswg-drafts/issues/5386 ) was only to support automatic italic of variables. Some members of the Math CG feel strongly about keeping the mathvariant attribute for backward compatibility with existing content but as mentioned in the spec, one can actually just use the Unicode characters after transformation. So we didn't consider critical to try to push harder for this on the CSS side, even if we have a patch ready for that ( https://bugs.chromium.org/p/chromium/issues/detail?id=1076420 ).

2. Another feature that was initially planned is the href attribute. One of the issue here is that MathML3 allows links on *all* MathML elements (rather than just e.g. a dedicated <a> element). Emilio Cobos from Mozilla raised the issue about the complexity cost of that choice. For example there are some privacy concerns related to the :visited selector which requires to implement mitigation, links also needs special to work with the tabindex attributes, etc Also at the WHATWG, it was decided a long time ago that linkable elements should not be able to have a shadow DOM (I believe it was for security reason) which we feel would prevent some interesting use cases for extensibility of MathML elements. At the end, we decided to remove href from the MathML Core specification for now as they are not really the most critical part of MathML and will discuss it for a future version, but existing tests written for WebKit/Gecko are still there. For details see https://github.com/w3c/mathml-core/issues/142 and https://github.com/w3c/mathml-core/issues/63 https://github.com/w3c/mathml-core/issues/69

3. Finally, the remaining important failures are related to interpretation of CSS specifications (e.g. width/height, out-of-flow, display, etc) as mentioned at the end of my second email. Again MathML authors don't really care about this and we have freedom to choose how we interpret these CSS properties as long as that doesn't break existing content. However, we believe it can be quite critical and a source of interoperability concern if people start to write polyfills and the like on top of MathML. Here, the issue is that the MathML CG proposed resolutions to issues, but Chromium reviewers suggested a different approach during the implementation phase so we have inconsistencies between spec and implementation, and even sometimes between two tests. These points were discussed at the hackfest ( https://people.igalia.com/fwang/2022-06-igalia-week-shipping-mathml-in-chromium/#/13 ) and fixing that is the very next task to tackle on our list.

The rest of the failures are less concerning from an interop point of view, they are either due to some bugs that can be fixed in Chromium (e.g. implement the new onbeforeload event attribute) or some issues with the design of legacy MathML tests (e.g. not relying on a web font for better accuracy).

You mentioned in your other email that some platforms don't have good enough pre-installed Math fonts. It seems your recommendation would be to make sure STIX Two Math is installed, and macOS will have that soon.

Have you inquired about ChromeOS also?

What will math look like on platforms that don't have a pre-installed font, and for pages that don't use a web font? Will it not render at all or render with illogical fallback glyphs?

So this is a quotation from the "font-family: math" design doc: "The math font family is intended for displaying mathematical expressions. Such expressions not only require special symbols but also extra data provided by the OpenType MATH table such as dedicated layout parameters or stretchy constructions. Except for very simple cases, mathematical formulas will render poorly without such a math font."

latin-moder-math-stix-two-math-noto-sans-math.html
firefox-latin-moder-math-stix-two-math-noto-sans-math.png
epiphany-latin-moder-math-stix-two-math-noto-sans-math.png
chromium-latin-moder-math-stix-two-math-noto-sans-math.png

### Morten Stenshorne

Jun 23, 2022, 7:06:30 AM (13 days ago) Jun 23
Exciting times!

Since the layout implementation of MathML is pure NG (i.e. it has no
legacy engine counterpart), you should be aware that this is somewhat
uncharted territory. We *do* have mechanisms that kick in when we need
to fall back to legacy layout (e.g. when printing, or when there are
tables inside multicol), and have NG-only content inside (such as
MathML), but no pure NG features have shipped yet, so we don't really
know how well this works on the world wild web.

That said, we're also about to ship container queries, which has the
same problem - so you're not alone. I was hoping that we'd be rid of the
legacy engine completely before we started shipping pure NG features,
because of this risk. I'm not saying that we definitely need to wait for
the legacy engine to be completely gone, but you need to be aware of the
risk, at least. Maybe clusterfuzz will find something interesting once
this feature is switched to "stable". :)

By the way, I just tested, and MathML inside legacy layout doesn't seem
to work. I filed
https://bugs.chromium.org/p/chromium/issues/detail?id=1338882
--
Morten Stenshorne, Software developer,

### Frédéric Wang

Jun 23, 2022, 7:39:41 AM (13 days ago) Jun 23
Hi Morten,

Thanks for raising this issue, I forgot to mention it. We experimented
this in the past and IIRC we found issues with:

- Printing: indeed printing pages with math is likely to happen!
- Multicol: Wikipedia uses that for the "References" section at the
bottom of articles and some pages actually do use math inside!
- SVG: definitely needed for math in graphics. This is no longer an
issue now that foreignObject was implemented in LayoutNG.
- Editing: I'm not sure what's the status of EditingNG but I believe we
wanted to disable editability on MathML anyway due to complexity for
editing math, which will require some tree fixup. This is better handled
by other tools.

I don't remember what was the recent status, but we definitely need to
check again. I believe we have crash tests in WPT and another to check
correct layout for math-in-svg.
Frédéric Wang

### Chris Harrelson

Jun 23, 2022, 11:54:19 AM (12 days ago) Jun 23
to Frédéric Wang, Morten Stenshorne, blink-dev
EditingNG has already shipped. Only table fragmentation and printing are still to ship, and hopefully they will both be done by the end of the year.

--
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

### Frédéric Wang

Jun 24, 2022, 1:43:05 AM (12 days ago) Jun 24
to Chris Harrelson, Morten Stenshorne, blink-dev
Thanks Chris. I'm attaching a testcase for contenteditable MathML. Indeed, the formula is properly rendered. It can also be edited and this will likely lead to "invalid" MathML markup (e.g. fraction ending up with only one child) but Firefox and WebKit don't perform integrity check either. And I guess it's fine, probably someone should really rely on JS to extend the native editor.

Morten was actually only mentioning the case when table is within a multicol so probably that excludes the Wikipedia use case (I'm going to do more checks there).

Printing would still be an issue.

So yeah, I personally don't think that should block shipping MathML but there are remaining issues with legacy layout that we need to be aware of.
--
Frédéric Wang

contenteditable-mathml.html

### Daniel Bratell

Jun 24, 2022, 5:15:10 AM (12 days ago) Jun 24
to Frédéric Wang, Chris Harrelson, Morten Stenshorne, blink-dev

I'm really happy to see this coming along! Awesome work by everyone involved!

I do agree that a feature of this size doesn't need to have all quirks ironed out before initial shipping. I expect some people to miss printing so I hope the gap where it doesn't work won't be too big.

You mentioned fuzzy testing. Do the fuzzing tools have support for mathml elements? If not, you should probably add a to-do item to teach them.

What is the situation for developers that learn about this and want to start using it? Are there good resources for learning how to write MathML? I think a feature like this also deserves some attention when it lands. Maybe that will happen by itself, or maybe someone needs to initiate it. That info should probably also mention initial limitations like printing, (multi-column?) and non-Core.

More about compatibility: Do you have any idea (guess really) of how much of existing MathML content will "work" with just MathML Core? Is it 99%, 90%, 50%, 10%?

/Daniel

### Frédéric Wang

Jun 25, 2022, 8:09:25 AM (11 days ago) Jun 25
to blin...@chromium.org
On 24/06/2022 11:14, Daniel Bratell wrote:
>
> I'm really happy to see this coming along! Awesome work by everyone
> involved!
>
Thanks!
>
> You mentioned fuzzy testing. Do the fuzzing tools have support for
> mathml elements? If not, you should probably add a to-do item to teach
> them.
>
MathML has been there for several years so I do expect (naively?) that
fuzzers have some kind of support already. My understanding is that
fuzzing tools can either generate data or "shuffle" from existing input.
For the latter, we have now a bunch of WPT tests with MathML to feed the
fuzzers and I believe these are particularly interesting to cover edge
cases with CSS, JS, etc. For the former, I thought that was the case for
https://github.com/MozillaSecurity/ or https://github.com/renatahodovan/
but can't find any up-to-date repo for MathML currently, so I agree we
need to work on that.
>
> start using it? Are there good resources for learning how to write
> MathML? I think a feature like this also deserves some attention when
> it lands. Maybe that will happen by itself, or maybe someone needs to
> initiate it. That info should probably also mention initial
> limitations like printing, (multi-column?) and non-Core.
>
Similarly, MathML has been there for a while so there is already a bunch
of resource available about MathML (e.g. MDN to mention the obvious one)
as wellas editors & converters to generate it, polyfills to cover
browser's limitations, etc but I agree they will probably need a refresh
since (1) we implement a core subset (2) we are moving to an extensible
approach based on web technologies (3) there are chrome-specific bugs
like the printing one.

> More about compatibility: Do you have any idea (guess really) of how
> much of existing MathML content will "work" with just MathML Core? Is
> it 99%, 90%, 50%, 10%?
>
I'm don't have actual values to provide but my guess (hope?) is that
it's between 90-99% of existing MathML content delivered to
Firefox/WebKit (note: they implement more than MathML Core but still not
the full MathML3 spec either). But if you want something more concrete,
regarding features we unshipped from Firefox I have a conversation on
Mozilla's matrix channel where we measured counters for deprecated
MathML3 features between 2020-08-11 and 2020-09-17. Most of them were
returning 0 count and only two of them were returning 1 count... to
compare with the counter for pages using MathML which was several millions!

--
Frédéric Wang

### Brian Kardell

Jun 28, 2022, 5:23:37 PM (7 days ago) Jun 28
[snip]

> More about compatibility: Do you have any idea (guess really) of how
> much of existing MathML content will "work" with just MathML Core? Is
> it 99%, 90%, 50%, 10%?

In addition to what Fred said about counters investigation,  I can add that the MathML Refresh group (that spent about 2 years working toward this and getting it back on a W3C rec track) was very interested in and focused on this question.  We did a bunch of research, and we also asked people with significant pools of MathML already to dig into some of it.   I guess I can assure you that much effort spent toward finding an interoperable subset that can give us a baseline for rendering the vast majority of content that was actually achievable and yielded acceptable results with 0-little effort for authors.

So, basically: It's hard to say with authority but the working group itself has been both very cautious and pragmatic here.  They definitely understand that even complete interoperability of L1 can't just make all MathML ever written work.  They focused on making "the vast majority of stuff great" and  making sure things outside that had a decent story too - be that it "failing" in a better way natively or just having a very simple remediation story, etc.

### Mike West

Jun 29, 2022, 12:08:54 PM (6 days ago) Jun 29
to blink-dev, Brian Kardell, fw...@igalia.com, Chris Harrelson
I'm excited about shipping MathML. I don't think it's necessary for us to wait O(months) for printing to work correctly, but I do think it's critical for us to give users who try to print some way of understanding that the rendering failure is not their fault. It would be unfortunate if folks go through debugging, uninstalling/reinstalling printer drivers, etc. for something that we know isn't going to work a priori.

I'd be happy LGTMing any reasonable compromise for the short term. A variety of approaches could be reasonable: a warning note in the print dialog, jamming some "Aw, snap!" rendering into the printed page, a pre-printing alert() dialog, basically anything our friendly UX experts will approve.

-mike

### slightlyoff via Chromestatus

Jun 30, 2022, 5:43:26 AM (6 days ago) Jun 30
to blin...@chromium.org
Excited to see this moving forward. Happy to see this ship with printing caveats from Mike. For my part, even a console log message would suffice.

### Daniel Bratell

Jun 30, 2022, 8:36:46 AM (6 days ago) Jun 30
to slightlyoff via Chromestatus, blin...@chromium.org

We discussed that option in the API Owner meeting and did not really like it. If there are no better alternatives, maybe it would be good enough but the typical people to encounter printing problems would probably not discover it.

I hope it's possible to find something more obvious so we don't have to go that route. Missing printing and the effects that may have on users was the only real blocking issue we identified.

/Daniel

On 2022-06-30 11:43, slightlyoff via Chromestatus wrote:
Excited to see this moving forward. Happy to see this ship with printing caveats from Mike. For my part, even a console log message would suffice.
--
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

### Frédéric Wang

Jul 1, 2022, 10:56:02 AM (5 days ago) Jul 1
to blin...@chromium.org

Just to follow-up on two points raised by Daniel:

On 25/06/2022 14:09, Frédéric Wang wrote:
>> You mentioned fuzzy testing. Do the fuzzing tools have support for
>> mathml elements? If not, you should probably add a to-do item to
>> teach them.
>>
> MathML has been there for several years so I do expect (naively?) that
> fuzzers have some kind of support already. My understanding is that
> fuzzing tools can either generate data or "shuffle" from existing
> input. For the latter, we have now a bunch of WPT tests with MathML to
> feed the fuzzers and I believe these are particularly interesting to
> cover edge cases with CSS, JS, etc. For the former, I thought that was
> the case for https://github.com/MozillaSecurity/ or
> https://github.com/renatahodovan/ but can't find any up-to-date repo
> for MathML currently, so I agree we need to work on that.
So we've been contacting various security people doing browser fuzzing
to make sure their tools handle MathML and are aware of MathML Core.
We've also spent some time focusing more precisely on Chromium-related
fuzzing, basically increasing code coverage of "in-process guided
fuzzing" for low-level font modules and teaching MathML Core grammar to
https://bugs.chromium.org/p/chromium/issues/detail?id=1340884

>>
>> to start using it? Are there good resources for learning how to write
>> MathML? I think a feature like this also deserves some attention when
>> it lands. Maybe that will happen by itself, or maybe someone needs to
>> initiate it. That info should probably also mention initial
>> limitations like printing, (multi-column?) and non-Core.
>>
> Similarly, MathML has been there for a while so there is already a
> bunch of resource available about MathML (e.g. MDN to mention the
> obvious one) as wellas editors & converters to generate it, polyfills
> to cover browser's limitations, etc but I agree they will probably
> need a refresh since (1) we implement a core subset (2) we are moving
> to an extensible approach based on web technologies (3) there are
> chrome-specific bugs like the printing one.

Also started to update MDN e.g.
https://github.com/mdn/content/pull/17735
https://github.com/mdn/content/pull/17812

Of course, we can probably get help from the MathML community to update it.

--
Frédéric Wang

### Benjamin Aster

Personally, I don't think it's a good idea to ship MathML with missing printing support at all. Users definitely expect printing mathematical documents (and saving them as PDFs!) to be working. Many websites use feature detection (something like "MathMLElement" in window) to check if MathML is supported and use polyfills like MathJax if not. In this case, the website would then display non-printable MathML formulas, but it would be better if the website would still use the MathJax polyfill so that printing would work. For example, Wikipedia might switch to MathML formulas some time after stable MathML support in Chromium, and users would be quite confused that if they print the article or save it as a PDF, the formulas aren't rendered correctly any more.
- A non-standard way for the developer to feature-detect if printing MathML is not supported (I'm thinking of something like MathMLElement.webkitPrintingUnsupported == true), so that you could still use MathJax for websites where users are likely to print them.