This section is non-normative.
The Mathematical Markup Language is the most popular XML format for describing mathematical notation and capturing both its structure and content [MathML3]. It has been integrated in various other standards such as [HTML5], [EPUB3], [ODF1] or [Daisy3]. Although the stated goal is “to enable mathematics to be served, received, and processed on the World Wide Web”, the MathML specification has two serious shortcomings that make it hard to implement presentation MathML in web rendering engines:
The MathML specification intentionally does not contain any detailed rendering rules. As a consequence, the fact that web rendering engines are compliant with the MathML specification does not necessarily mean that they will have the rendering quality expected by most readers. For example, the specification essentially just says that “mfrac element is used for fractions” and that the default medium linethickness “is left up to the rendering agent” [MathML3]. As a comparison, to determine the exact spacing and thickness of fractions and stacks the TeXBook’s Appendix G [TeXBook] relies on parameters and while the MATH table of the Open Font Format [OpenFontFormat3] extends these to parameters FractionNumeratorDisplayStyleShiftUp, FractionNumeratorShiftUp, FractionNumeratorDisplayStyleGapMin, FractionNumeratorGapMin, FractionRuleThickness, FractionDenominatorDisplayStyleGapMin, FractionDenominatorGapMin, FractionDenominatorDisplayStyleShiftDown, FractionDenominatorShiftDown, StackTopDisplayStyleShiftUp, StackTopShiftUp, StackDisplayStyleGapMin, StackGapMin, StackBottomDisplayStyleShiftDown and StackBottomShiftDown.
The MathML specification is designed as an independent XML language and browser vendors have almost not been involved in the standardization process, except for integration in [HTML5]. Instead, the specification is sometimes biased by MathML rendering and authoring tools behaving quite differently from web rendering engines. Hence it is not always obvious whether all features are fundamental or whether they fit well into the web rendering engine codebase. For example, the <mfenced> element is just a “convenient form in which to express common constructs involving fences” but is strictly equivalent to an expanded form with <mrow> and <mo> elements. It requires web rendering engines to create many “anonymous” rendering frames and keep them up-to-date, to duplicate the logic for drawing and exposing the content of fenced expressions etc. Another example is the first cell in a <mlabeledtr> row which is not necessarily positioned the same way as in HTML table and actually is supposed not to be involved in metric computation or border drawing of the table [MathML3].
This “MathML in HTML5” implementation note intends to address these issues by being as accurate as possible on the visual rendering of mathematical formulas using additional rules from the TeXBook’s Appendix G [TeXBook] and from the Open Font Format [OpenFontFormat3]. Focus has been put on keeping compatible with existing technologies of web rendering engines [HTML5] by relying as much as possible on CSS, text & table layout and box models. As a consequence, parts of presentation MathML that do not fit well in this framework or are rarely used in practice have been ommited ; details on these and suggestions for standardization bodies are provided in the Appendix.
Future versions of this document may describe support for a larger subset of presentation MathML by including features that are important in a web context e.g. CSS-compatible line breaking.
This section is non-normative.
This document focuses on the most important points to implement MathML in web rendering engines. Hence it is intentionally short and readers are invited to check the MathML 3 specification for details [MathML3]. As a convenience, quotations from the MathML 3 specification are referred to with the following style:
This is a quotation from the MathML 3 specification.
This document relies on many definitions taken from the MATH specification of the Open Font Format [OpenFontFormat3]. These values are written with the following style: This is a definition from the MATH specification.
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, are to be interpreted as described in [IETFRFC2119].