Project

Below is the project roadmap that was completed in 2019 on Igalia’s downstream branch of Chromium. Since then, a huge effort has been made to upstream that code so that they are shipped in all Chromium-based browsers. Goals have been slightly adapted according to feedback from Chromium reviewers and agreement in standardization groups. Such changes are indicated by a pen symbol “🖊”️ together with the amendment details.

As of January 2023, the MathML implemention described in this roadmap is shipped in official Chrome releases. New developments and maintenance continue via the Open Collective project.

✅ Basic Setup

• ✅ Simple grouping <math> (with its display attribute), <mrow>, <mstyle>, <merror> (with special CSS style), <mpadded>, <mphantom> (with visibility: hidden).
  • 🖊 2020/06/01 Initial roadmap was mentioning simple grouping for <menclose>, but this has been generalized to all unknown elements.
• ✅ Simple text container: <mi>, <mn>, <mo>, <mtext> and <ms>.
• ✅ Simple spacing: <mspace> element with width, depth, height attributes.
• ✅ dir, mathcolor, mathbackground and mathsize attributes.
  • 🖊 2022/05/09: Initial roadmap did not elaborate about right-to-left support. Although the dir attribute is properly mapped to the CSS direction property and that property taken into account for MathML layout, mirroring of stretchy operators is currently not supported.
• ✅ Simplified semantics: just display the first child and hide annotations.

✅ Basic Layout

• ✅ Fraction (<mfrac>), with its linethickness attribute.
• ✅ Postscripts: <msub>, <msup>, <msubsup>
• ✅ Under and over scripts: <munder>, <mover>, <munderover>
• ✅ Multiple pre and post scripts: <mmultiscripts>
• ✅ Basic HTML-like implementation of mtable.
• ✅ Advanced Spacing: mpadded with simplified interpretation of width, depth, height, lspace and voffset.

✅ Operator Dictionary

• ✅ form (for selecting an entry in the dictionary)
• ✅ largeop and movablelimits (to perform spacing in under and over scripts)
  • 🖊 2020/06/01: Initial roadmap was mentioning the accent property/attribute but this has been removed in favor of suppporting accent/accentunder attributes on underover scripts.
• ✅ lspace and rspace (to perform spacing in <mrow>-like elements).

✅ Stretchy operators

• ✅ Shaping large and stretchy operators using the MathVariants table.
• ✅ Drawing of largeop operators in under and over scripts
• ✅ Stretch logic in <mrow>-like elements and under and over scripts.
  • 🖊 2021/08/04 Initial roadmap was to implement what is described in MathML Core but see below for current limitations.
• ✅ Using stretchy and symmetric attributes.
• ✅ Simple embellished operators
• ✅ Roots (msqrt, mroot)

✅ Advanced Style

• ✅ mathvariant
  • 🖊 2020/09/10: Initial goal was to support the mathvariant values from MathML 3. However we were only able to get one text-transform value accepted by the CSSWG. This provides automatic italic of variables ; authors are encouraged to directly use the relevant Unicode characters for other math variants.
• ✅ displaystyle
• ✅ scriptlevel

✅ Accessibility

🖊 2019/10/15: Initial roadmap was focusing on MathML rendering but after sending the intent-to-implement, we were asked to coordinate with the accessibility team. The goal is to get parity with Gecko and WebKit on two platforms:

• ✅ Same macOS / NSAccessibility roles, subroles and attributes as Gecko and WebKit.
• ✅ Same Linux / ATK roles and markup information as Gecko.

🖊 “width” of stretchy operators (blocked on Chromium’s refactoring)

In MathML Core, the min-content “width” and max-content “width” of a stretchy operator are the same : either the maximum “width” of all its sizes (vertical operators) or the “width” of its base size (horizontal operators).

This is obviously not the same as the actual “width” calculated during layout e.g. small, medium and big (vertical) fences can take different widths while a stretched (horizontal) accent is normally much wider than its base size.

Currently, Chromium’s layout implementation must use the min/max-content “width” as the actual “width” of bounding boxes. For MathML, this means that:

• A vertical stretchy operator may be more narrow than its bounding box.
• A horizontal stretchy operator may overflow its bounding box.

Note that Igalia’s downstream branch did not have this problem since it was not respecting Chromium’s limitation. Also, the issue is slightly mitigated upstream by splitting the extra space or overflow evenly on both sides.

Google’s rendering core has a plan to rewrite how the layout steps work but this is a big effort. Until that is resolved, one cannot properly implement stretchy operators as described in MathML Core and these operators will continue to cause serious rendering bugs.

✅ Other tasks (not in the initial roadmap)

🖊 2022/05/09: This list used to contain more items but has been updated to only include the ones that are expected to be in the initial release.

The following features have been discussed with Chromium reviewers or Math/CSS WG members during the implementation phase but they were not part of the initial roadmap:

• ✅ Clear and small specification targeted towards browser implementers
• ✅ Web Platform tests (with order of magnitude of thousands tests)
• ✅ Relaunching a Standardization Group for MathML
• ✅ Basic MathML DOM/IDL
• ✅ display: math
• ✅ text-transform: auto
• ✅ CSS math-style property
• ✅ CSS math-shift property
• ✅ CSS math-depth property
• ✅ font-family: math value
• ✅ UA stylesheet adjustments
• ✅ Basic handling of invalid markup
• ✅ Integration with features forcing legacy layout (SVG, editing, fragmentation)
• ✅ minsize and maxsize attributes for vertical operator stretching
• ✅ ink metrics for MathML token elements

Besides these tasks, Igalia continues to keep an eye on security bugs, interoperability issues as well as compatibility with CSS.