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 September 2021, a significant amount of the work is upstreamed and already available in official Chromium builds under the Experimental Web Platform Features flag. The latest status is indicated by a green check mark “✅” (work upstreamed), a roadwork sign “🚧” (upstream work in progress) and a red cross “❌” (upstreaming not started yet).
<merror>(with special CSS style),
<menclose>, but this has been generalized to all unknown elements.
dirattribute is properly mapped to the CSS
directionproperty and that property taken into account for MathML layout, mirroring of stretchy operators is currently not supported.
semantics: just display the first child and hide annotations.
<mfrac>), with its
mpaddedwith simplified interpretation of
form(for selecting an entry in the dictionary)
movablelimits(to perform spacing in under and over scripts)
accentproperty/attribute but this has been removed in favor of suppporting accent/accentunder attributes on underover scripts.
rspace(to perform spacing in
largeopoperators in under and over scripts
<mrow>-like elements and under and over scripts.
mathvariantvalues from MathML 3. However we were only able to get one
text-transformvalue accepted by the CSSWG. This provides automatic italic of variables ; authors are encouraged to directly use the relevant Unicode characters for other math variants.
🖊 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:
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:
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.
🖊 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:
maxsizeattributes for vertical operator stretching
Besides these tasks, Igalia continues to keep an eye on security bugs, interoperability issues as well as compatibility with CSS.