# MathML in HTML5 - Implementation Note

Editors:
Frédéric Wang

## Abstract

This document is a detailed technical document for a core subset of presentation MathML [MathML3] in order to render with high quality the majority of mathematical formulas used in practice. This document should be understandable by any implementer with sufficient knowledge of web rendering engines and text layout. Contrary to the official MathML specification, a significant effort is made to be 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 version 3 [OpenFontFormat3]. The priority is to be 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.

## Status of This document

This section describes the status of this document at the time of its publication. Other documents may supersede this document.

This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

# 1 Introduction

## 1.1 Rationale for this Technical Document

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:

1. 1.

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 $\sigma_{8},\sigma_{9},\xi_{8},{3\xi_{8}},{7\xi_{8}},\sigma_{11}$ and $\sigma_{12}$ 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.

2. 2.

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 element is just a “convenient form in which to express common constructs involving fences” but is strictly equivalent to an expanded form with and 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 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.

## 1.2 Remarks

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.

This document only deals with the visual rendering of presentation MathML and briefly mentions interactions (javascript, links etc). It does not specify how presentation MathML must be exposed to assitive technologies nor does it explain how the semantic provided by content MathML can be used.

This document has been generated by LaTeXML from LaTeX sources. It should be read in a browser that supports web technologies such as HTML, CSS, SVG and MathML.

A set of tests following the format and convention of the Test The Web Forward project are available in a separate git repository. Browser vendors are encouraged to use these tests during implementation & automated testing. Contribution of new tests and error reports are welcome.

## 1.3 Terminology

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

# 2 Relation with other technologies

## 2.1 HTML5 Tree

### 2.1.1 DOM, HTML, SVG and Javascript

User agents must use a HTML5 [HTML5] parser to build a DOM tree [DOM1] from the source code of web pages. In particular, they must follow the rules describing when elements must be in the MathML namespace http://www.w3.org/1998/Math/MathML and must recognize the entity definitions from the HTML MathML entity set of [XMLEntities]. They must also take into account the following integration points between SVG, MathML and HTML as allowed by [ValidatorSchemas]:

1. 1.

The  element can be used at any position permitted for phrasing content or inside SVG elements.

2. 2.

The element can be used inside elements with encoding SVG1.1 or image/svg+xml.

3. 3.

The element and flow content can be used inside elements with encoding application/xhtml+xml or text/html.

4. 4.

Any phrasing element can be used inside elements.

From this DOM tree, user agents must provide a visual representation of the document. The DOM tree may be dynamically modified using Javascript [ECMA262] and the user agents must keep the visual representation in synchronization with the DOM tree.

When evaluating the SVG requiredExtensions attribute [SVG11], user agents must claim support for the extension of name http://www.w3.org/1998/Math/MathML. An algorithm to decide the visible child of the element is proposed in section 3.8.

### 2.1.2 MathML

All MathML elements accept the id, class and style attributes [MathML3]. They must be interpreted as described in section 3.2.5 of the HTML5 specification [HTML5] and in particular they specify a unique identifier (to identify elements in links and scripting), affect CSS selectors, affect getElementsByClassName() and enable authors to do inline styling.

MathML 3 allows to use the href attribute on any MathML element [MathML3]. In the present document, it is only required to implement href on the mrow element with the behavior described in 4.8 of the HTML5 specification for the a element [HTML5]. It is recommended to make links visually distinguisable by default, for example by adding a rule in the user agent stylesheet (section 2.3.2) such as

 mrow[href] { color: blue; }

The toplevel math element accepts the altimg, altimg-width, altimg-height, altimg-valign and alttext attributes. These attributes allow to specify fallback content and may just be ignored. User agents that do not fully implement this document may decide to render this fallback content in some situations e.g. when they are specified or under a preference option. In that case, an approximate implementation is to render the math element as a HTML img element with the value of altimg as an src attribute, the value of alttext as an alt attribute, the value of altimg-width as the CSS width property, the value of altimg-height as the CSS height property and the value of altimg-valign as the CSS vertical-align property [HTML5] [CSS2]. Here is a partial implementation using the attr() function of [CSS3Values]:

 math { display: inline; } math[display="block"] { display: block; text-align: center; } math { background-image: attr(altimg url); width: attr(altimg-width length); height: attr(altimg-height length); vertical-align: attr(altimg-valign length); } math > * { display: none; }

The toplevel math element also accepts the display attribute, mathcolor, mathbackground attributes as well as other attributes from the mstyle element. These attributes must be supported and this may be achieved using specific rules in the user agent stylesheet as described in section 2.3.2.

In general MathML elements or attributes that are not mentioned in this document may just be ignored. This includes deprecated attributes or Content Markup described in chapter 4 of the MathML 3 specification [MathML3].

User agents must contain an operator dictionary describing the default properties of operators. For interoperability, it is recommended to use the one proposed in the non-normative Appendix C of [MathML3].

## 2.2 Text and Math layout

### 2.2.1 Open Font Format

Because math fonts generally contain very tall glyphs such as big integrals, using typographic metrics is important to avoid excessive line spacing of text. This behavior is specified in math fonts using the USE_TYPO_METRICS flag from the OS/2 table [OpenFontFormat3] and user agents must honor that flag.

Mathematical formulas can be viewed as an extension of standard text layout and thus user agents must be able to perfom complex text layout [CTL] using fonts under the Open Font Format [OpenFontFormat3]. In particular, they must implement bidirectional rendering and shaping of Arabic scripts.

Mathematical formulas may mix standard text with other graphical outlines (e.g. fraction or top radical bars). For consistency, these outlines should be rendered the same way as normal text. In particular, user agents must be able to apply visibility and color CSS properties to them. They may also support similar CSS properties for text such as text-shadow or opacity.

Good mathematical rendering requires use of non-Unicode glyphs. Mathematical fonts may only provide these glyphs when the math script tag is enabled and so user agents must ensure that the text within MathML token elements is rendered with that script tag. Some characters like primes already have script size by default and hence would be too small when used in a script position. Hence user agents must support glyph selections via the OpenType font feature ssty (Script Style) in order to display such “prescripted” characters with the appropriate size. For bidirectional layout, Unicode defines character-level mirroring to transform a character into its mirrored form, for example U+0028 LEFT PARENTHESIS into U+0029 RIGHT PARENTHESIS. User agents must also support the OpenType font feature rtlm (Right-to-left mirrored forms) to allow glyph-level mirroring in cases where character-level is not enough [OpenFontFormat3]. At the time of writing, Unicode does not distinguish between Chancery and Spencerian style for the Unicode MATHEMATICAL SCRIPT characters. Some mathematical fonts rely on salt or ssXY properties to provide both styles. User agents may support the CSS font-variant-alternates property and corresponding OpenType font features to enable page authors to get access to these styles [CSS3Font] [OpenFontFormat3].

User agents must be able to read information from the OpenType MATH table [OpenFontFormat3]. In particular they must be able to read the values from the MathConstants subtable. They must also be able to use the MathVariants subtable to solve the following problem: given a particular default glyph shape and a certain width or height, find a variant shape glyph (or a construct created by putting several glyphs together) that has the required measurement. More information are provided in see section 3.2.4.

### 2.2.2 LaTeX

Mathematical rendering rules in this document are implicitly based on MathML, OpenType MATH table and the TeXBook [MathML3] [OpenFontFormat3] [TeXBook]. In this section, we describe more precisely some rules from the TeXBook.

In addition to concepts similar to MathML’s displaystyle and scriptlevel, LaTeX has a “cramped” property, which is involved in the determination of script shifts. It is initially unset on the math element and in general all the children inherits the “cramped” property from their parent. However, it is set to true in the following children:

1. 1.

The denominator of an mfrac element. See section 3.3.2.

2. 2.

The subscripts of the msub, msubsup, munder and munderover elements. See section 3.4.

3. 3.

The overscript of the mover and munderover elements when it is an accent per the MathML specification. See section 3.4.

4. 4.

The children of the msqrt and mroot elements as well as the menclose element that have radical notation.

To implement math spacing, the TeXBook defines eight basic types (Ord for ordinary atoms, Op for large operators, Bin for binary operations, Rel for relations, Open for opening fences, Close for closing fences, Punct for punctuations and Inner for a delimited subformula) and define an inter space for each pair of such types. In the present document, we only follow the spacing algorithm of MathML 3: by default the inter space is always zero and the spacing is produced by spacing elements like mspace, mphantom or mpadded or by the leading and trailing space around embellished operators.

## 2.3 CSS Styling

### 2.3.1 Properties

User agents must support the CSS language [CSS2] and must take special styling into account when building the visual representation of the document. Many of the MathML elements accept attributes with length value whose general syntax is described in section 2.1.5.2 of the MathML specification [MathML3]. In general, the syntax is compatible with [CSS2] but user agents must handle specificities of the MathML specification. In particular, the keywords veryverythinmathspace, verythinmathspace, thinmathspace, mediummathspace, thickmathspace, verythickmathspace, veryverythickmathspace, negativeveryverythinmathspace, negativeverythinmathspace, negativethinmathspace, negativemediummathspace, negativethickmathspace, negativeverythickmathspace and negativeveryverythickmathspace must be interpreted as their equivalent em value. Also, percent and unitless values must be interpreted with respect to the appropriate reference value. Note that the mpadded element also accepts more general length values as discussed in section 3.3.6.

User agents must support at least the following properties:

1. 1.

display: at least inline, block, inline-table, table-row, table-cell and none. It is used for the math and tabular elements. Appropriate values may be specified in the user agent stylesheet as described in section 2.3.2.

2. 2.

direction. The dir attribute on the math, mstyle, mrow and token elements must be mapped to that property.

3. 3.

font property and its shorthands. The mathsize attribute on the math, mstyle and token elements must mapped to that property.

4. 4.

background and color. The mathcolor and mathbackground attributes on presentation MathML elements must be mapped to these properties.

5. 5.

visibility. It is is used for the mphantom element and may be specified in the user agent stylesheet as described in section 2.3.2.

User agents must support the displaystyle attribute. This may be implemented using a new mathml-math-style property described in table 2.3.1. The expected behavior may be completely specified in the user agent stylesheet as described in section 2.3.2.

User agents must support the mathvariant attribute. This may be implemented using a new mathml-math-variant property described in table 2.3.1. The expected behavior may be implemented by mapping mathvariant attributes on the math, mstyle and token elements to mathml-math-variant. Then during the rendering of text nodes, the mathml-math-variant value must be taken into account to remap some characters to their equivalent code points, as specified by the MathML specification. However, as indicated in section 3.2.2, when mathml-math-variant is none on an mi element with a single character, it must actually be treated as if the mathvariant was italic ; this can not be handled via CSS-only.

User agents must implement the scriptlevel attributes and support automatic incrementation of the scriptlevel described in the MathML specification. They may implement the scriptsizemultiplier and scriptminsize attributes or instead just use the default values (respectively 0.71 and 8pt). These parameters affect the font-size property as follows: If the parent font-size is not already below the scriptminsize, then the child font-size is computed by the following formula:

 $\text{FontSize}_{\text{Child}}={\max\left(\text{ScriptMinSize}_{\text{Parent}}% ,{\text{FontSize}_{\text{Parent}}\times{\text{ScriptSizeMultiplier}_{\text{% Parent}}^{\left(\text{FontSize}_{\text{Child}}-\text{FontSize}_{\text{Parent}}% \right)}}}\right)}$ (1)

Since the font-size change is typically done in a dedicated CSS module of user agents, it may be convenient to introduce a new mathml-script-level property described in table 2.3.1. User agents may then implement the expected behavior by mapping the scriptlevel attribute on the math and mstyle elements to that property and adding appropriate rules in the user agent stylesheet (section 2.3.2). However as indicated in section 3.4.2, the scriptlevel change for underscripts and overscripts can not be handled via CSS-only.

If scriptsizemultiplier and scriptminsize are supported, then they may also be implemented using new CSS properties mathml-script-size-multiplier and mathml-script-min-size described in tables 2.3.1 and 2.3.1 respectively. User agents may then implement the expected behavior by mapping the scriptsizemultiplier and scriptminsize attributes on the math and mstyle elements to these properties.

### 2.3.2 User Agent Stylesheet for MathML

Because mathematical formulas are generally written with special fonts, the default user agent stylesheet must reset the CSS font-family on the math element to serif. User agents should then use their own mechanism to try and interpret this serif value on the math element as a font with an OpenType MATH table.

Below is an example on a stylesheet to style MathML elements on which the User Agents may rely. Unfortunately, some rendering engines do not allow universal selectors in their user agent stylesheets and so rules must be expanded to list all possible MathML elements described in the present document. For example mfrac > * can be converted into mfrac > mi, mfrac > mn, mfrac > mo, mfrac > mtext, mfrac > mspace, mfrac > ms, mfrac > mrow, mfrac > mfrac, mfrac > msqrt, mfrac > mroot, mfrac > mstyle, mfrac > merror, mfrac > mpadded, mfrac > mphantom, mfrac > menclose, mfrac > msub, mfrac > msubsup, mfrac > munder, mfrac > mover, mfrac > munderover, mfrac > mmultiscripts, mfrac > mtable, mfrac > maction.

 @namespace url(http://www.w3.org/1998/Math/MathML); /* The  element */ math { direction: ltr; display: inline; font-size: inherit; font-style: normal; font-family: serif; mathml-math-style: inline; } math[display="block"] { display: block; text-align: center; mathml-math-style: display; } math[display="inline"] { display: inline; mathml-math-style: inline; } math[displaystyle="false"] { mathml-math-style: inline; } math[displaystyle="true"] { mathml-math-style: display; } /* Links */ mrow[href] { color: blue; } /* Tabular elements */ mtable { display: inline-table; mathml-math-style: inline; } mtable[displaystyle="true"] { mathml-math-style: display; } mtable[frame="none"] { border: none; } mtable[frame="solid"] { border: solid thin; } mtable[frame="dashed"] { border: dashed thin; } mtr, mlabeledtr { display: table-row; vertical-align: baseline; } mlabeledtr > mtd:first-child { display: none; } mtd { display: table-cell; vertical-align: inherit; text-align: center; padding: 0.5ex 0.4em; } /* The  element */ ms { display: inline; } ms:before, ms:after { content: "\0022" } ms[lquote]:before { content: attr(lquote) } ms[rquote]:after { content: attr(rquote) } /*  The  element */ merror { outline: solid thin red; background-color: lightYellow; } /* The  element */ mphantom { visibility: hidden; } /* Scriptlevel and displaystyle for other elements */ mstyle[displaystyle="false"] { mathml-math-style: inline; } mstyle[displaystyle="true"] { mathml-math-style: display; } mfrac > * { mathml-script-level: auto; mathml-math-style: inline; } mroot > :not(:first-child) { mathml-script-level: increment-by 2; mathml-math-style: inline; } msub > :not(:first-child), msup > :not(:first-child), msubsup > :not(:first-child), mmultiscripts > :not(:first-child) { mathml-script-level: increment-by 1; mathml-math-style: inline; } munder > :not(:first-child), mover > :not(:first-child), munderover > :not(:first-child) { mathml-math-style: inline; }

# 3 Presentation Markup

## 3.1 Introduction

### 3.1.1 Box Model

User agents must also follow the rules described in section 4.7.14 Embedded content, MathML of [HTML5], in particular the equivalence with implicit mtext and merror to handle non-conforming MathML markup.

MathML elements have the following box model. The [itex] root may have inline or block display, as suggested in section 2.3.2. Tabular MathML elements have table, table-row and table-cell display as discussed in section 3.5. The [itex] and <mtd> elements generate an anonymous <mrow> MathML box child that contains the boxes of their children and use the box parameters below to layout this anonymous <mrow> box. No line breaking can happen within MathML boxes and the min-content width is equal to the max-content width, these are simply called the intrinsic width. Each MathML box has the following parameters:

1. 1.

intrinsic width $W$.

2. 2.

logical width $w$, ascent above the origin $a$ and descent below the origin $b$. The height is then $a+b$.

3. 3.

ink ascent $A$ and descent $B$, corresponding to the exact box enclosing ink of text and bars within the MathML box.

For MathML element containing only text nodes or foreign elements, we assume that the content is simple enough to determine these values. For example, in most case, this is just a single text node and $w=W$. A MathML element containing only other MathML elements follow special rules to layout their children at position $(x_{i},y_{i})$ with parameters $W_{i},w_{i},a_{i},b_{i},A_{i},B_{i}$. Then as a general rule, its box parameters are given by taking the union of child boxes, that is:

 $w=\left(\max_{1\leq i\leq n}{x_{i}+w_{i}}\right)-\left(\min_{1\leq i\leq n}x_{% i}\right)$
 $W=\left(\max_{1\leq i\leq n}{x_{i}+W_{i}}\right)-\left(\min_{1\leq i\leq n}x_{% i}\right)$
 $a=\max_{1\leq i\leq n}{a_{i}-y_{i}}$
 $b=\max_{1\leq i\leq n}{b_{i}+y_{i}}$
 $A=\max_{1\leq i\leq n}{A_{i}-y_{i}}$
 $B=\max_{1\leq i\leq n}{B_{i}+y_{i}}$

Note that the schemas in this document are drawn assuming left-to-right directionality. If the CSS direction is set to right-to-left, then the elements should be layout by making the $x$-axis pointing from right-to-left. In this document, we use the terminology of [MathML3]: “leading” means “left” in right-to-left and “right” in right-to-left mode, while “trailing” means “right” in right-to-left and “left” in right-to-left mode.

The MathItalicsCorrectionInfo table contains the italic correction of some glyphs, which provides a measure of how slanted the glyphs are (see figure 2). The MathTopAccentAttachment table also contains a reference points that is used for the horizontal positioning of glyphs as an accent (see figure 3). In later sections, we generalize this by claiming that all MathML boxes have italic correction and top accent attachment values. The values for glyphs are used to try and extend to token elements or to special boxes that do not change child metrics. Otherwise fallback values are used: 0 for italic correction and half the width of the box for top accent attachment.

The present document assumes that $W,w,a,b,A,B$, italic correction and top accent attachment are nonnegative values. If computations result in negative values, then they must be interpreted as being zero. Note that some MathML elements such as mspace or mpadded may set box dimensions to negative values.

### 3.1.2 Layout Steps

For compatibility with HTML5 rendering, the MathML layout is performed in two independent steps:

1. 1.

In the first step, we determine the intrinsic width $W$ of MathML boxes. To do so we just follow the description given in this document for each MathML box. We rely on vertical positions $x$ as well as values for italic correction and top accent attachment. However, we ignore any vertical positioning or metrics.

2. 2.

In the second step, we do the final layout of MathML boxes following the description given in this document. We obtain all the box metrics, including the actual width $w$, vertical metrics $a,b,A,B$ and vertical positions $y$.

In order to perform the first step independently of the second one, the horizontal metrics must not depend on the vertical metrics. As described in section 3.3.6, this adds some restrictions on the possible pseudo-units of the mpadded element. As indicated in section 3.2.4, the width of size variants or of the glyph assembly used for vertical stretchy operators may depend on the target size to cover. Taking the maximum widths for all these size variants or for the glyph assembly during the first step makes the intrinsic width independent of the target size but may lead to a small over-estimation.

Each of this step is done recursively: the metrics of a given MathML box are determined from those of the child boxes. User agents must implement the “Exception for embellished operators” described in [MathML3]. This means that the actual stretching of operators described in section 3.2.4 may be “delayed” until we reach the top of its embellished operator subtree. We then have to apply the current operation again to this embellished operator (intrinsic width determination or layout). Fortunately, such embellished operator subtrees are not deep in practice.

This document does not require support for operator stretching in table cells. The “delayed” stretching of all operators must then be performed when we arrive at the anonymous <mrow> child of [itex] and <mtd> elements. That way, the intrinsic width of this anonymous <mrow> is well-defined for the layout of mtable elements and of the containers of the [itex] element. Similarly, the final layout of this anonymous <mrow> is already done when we want to perform the one of its ancestors.

## 3.2 Token Elements

### 3.2.1 Using images to represent symbols <mglyph/>

The MathML specification describes mglyph as follows [MathML3]:

The mglyph element provides a mechanism for displaying images to represent non-standard symbols.

This document does define any layout algorithm for the mglyph element. User agents may just ignore it.

### 3.2.2 Identifier <mi>

The MathML specification describes mi as follows [MathML3]:

An mi element represents a symbolic name or arbitrary text that should be rendered as an identifier.

In general, the mi element must be treated the same as the mtext element. However, when the mathvariant on an mi element is none and the mi content is made of a single character then the element must behave as if mathvariant was actually set to italic.

### 3.2.3 Number <mn>

The MathML specification describes mn as follows [MathML3]:

An mn element represents a ”numeric literal” or other data that should be rendered as a numeric literal.

For the layout algorithm described in this document, the mn element must be treated the same as the mtext element.

### 3.2.4 Operator, Fence, Separator or Accent <mo>

The MathML specification describes mo as follows [MathML3]:

An mo element represents an operator or anything that should be rendered as an operator.

Many properties of an mo element can be specified via attribute on that element. The default value of the form of an mo element is obtained as described in section “Default value of the form attribute” of [MathML3]. From the form and the text content, we can deduce other default values from the operator dictionary or use the fallback values given in “Dictionary-based attributes” of [MathML3].

The leading space lspace and trailing space rspace must be added on each side of the mo element (or its outermost embellished ancestor).

In most cases, the mo element is treated as an mtext element. However, when an mo element with a single character must be displayed as a large operator then instead we use the MathVariants table to try and find a glyph of height at least DisplayOperatorMinHeight (figure 4). If none is found, we fallback to the largest one. Because this parameter does not always give the best size, user agents may also use the following heuristic: ensure that the large variant height is at least $2$ times as large as the base height for integrals and $\sqrt{2}$ times as large as the base height for other operators.

When an mo element with a single character must be displayed as a horizontal or vertical operator then instead of displaying the normal character we use the MathVariants table to try and find a glyph that has at least the desired size or an assembly from several glyphs to cover at least the desired size (figure 5). The rules for vertical stretching are a bit more complicated and are described in section “Vertical Stretching Rules” of [MathML3]. If the operator has property symmetric="true", it must be stretched symmetrically with respect to the axis height, using the AxisHeight value as the math axis. Figure 6 compares the symmetric and non-symmetric stretching.

The size variant or construction used for vertical stretchy operators will depend on the target size to cover. To determine the intrinsic width $W$ of the operator, we consider the maximum of all possible widths for the base size, size variants and construction available for the given operator. It is assumed that the width of the operator is almost independent of the stretch size, which is the case in practice for most math fonts and operators.

See section 3.3.1 for details about how to treat “embellished ancestor”, and how decide when to display operators larger or when to stretch them vertically & horizontally.

### 3.2.5 Text <mtext>

The MathML specification describes mtext as follows [MathML3]:

An mtext element is used to represent arbitrary text that should be rendered as itself.

In most cases the <mtext> element contains some text that is laid out without line breaks using complex text layout [CTL]. It is assumed that we can measure the ink ascent & descent, logical ascent & descent and advance width of the text frame and use these values for the MathML box of the <mtext> element.

If the trailing glyph of the text content has an entry in the MathItalicsCorrectionInfo table then the specified value is used as the italic correction. User agents may substract the advance width from the abscissa of the trailing ink edge as a heuristic value for the italic correction of the <mtext> element when it is not specified in the MathItalicsCorrectionInfo table.

If the text content is made of a single glyph and this glyph has an entry in the MathTopAccentAttachment table then the specified value is used as the top accent attachment of the <mtext> element.

If the CSS direction on the <mtext> element is set to right-to-left then user agents must enable the rtlm OpenType feature on text nodes unless it contradicts what the page author has specified with the font-feature-settings CSS property.

If <mtext> is used at a non-zero scriptlevel then user agents must enable the ssty OpenType feature on text nodes unless it contradicts what the page author has specified with the font-feature-settings CSS property.

In the most general case, the <mtext> element may contain text with line breaks or arbitrary HTML5 phrasing elements. We assume that we can still determine logical dimensions and max-content width of the text content and use it for both the logical and ink values of the <mtext> element. The italic correction and top accent attachment are assigned the fallback values indicated in section 3.1.1

### 3.2.6 Space <mspace/>

The MathML specification describes ms as follows [MathML3]:

An mspace empty element represents a blank space of any desired size, as set by its attributes.

The mspace element is laid out as shown on figure 7. The logical box is determined by the height, depth and width attributes defined in [MathML3]. The ink box matches the logical box. The linebreak attribute on the <mspace/> element must be ignored.

### 3.2.7 String Literal <ms>

The MathML specification describes ms as follows [MathML3]:

The ms element is used to represent ”string literals” in expressions meant to be interpreted by computer algebra systems or other systems containing ”programming languages”.

In general, ms must be treated the same as the mtext element except that quotes are automatically added around its content. The user agents may implement the lquote or rquote attributes with the following style in the user agent stylesheet as suggested in section 2.3.2:

 ms { display: inline; } ms:before, ms:after { content: "\0022" } ms[lquote]:before { content: attr(lquote) } ms[rquote]:after { content: attr(rquote) }

## 3.3 General Layout Schemata

### 3.3.1 Horizontally Group Sub-Expressions <mrow>

The MathML specification describes mrow as follows [MathML3]:

An mrow element is used to group together any number of sub-expressions, usually consisting of one or more mo elements acting as ”operators” on one or more other expressions that are their ”operands”.
Several elements automatically treat their arguments as if they were contained in an mrow element. See the discussion of inferred mrows in Section 3.1.3 Required Arguments. […]
mrow elements are typically rendered visually as a horizontal row of their arguments, left to right in the order in which the arguments occur within a context with LTR directionality, or right to left within a context with RTL directionality. The dir attribute can be used to specify the directionality for a specific mrow, otherwise it inherits the directionality from the context. […] The description in Section 3.2.5 Operator, Fence, Separator or Accent <mo> of suggested rendering rules for mo elements assumes that all horizontal spacing between operators and their operands is added by the rendering of mo elements (or, more generally, embellished operators), not by the rendering of the mrows they are contained in.
MathML provides support for both automatic and manual linebreaking of expressions (that is, to break excessively long expressions into several lines). All such linebreaks take place within mrows, whether they are explicitly marked up in the document, or inferred (See Section 3.1.3.1 Inferred <mrow>s), although the control of linebreaking is effected through attributes on other elements (See Section 3.1.7 Linebreaking of Expressions).

The dir attribute must be mapped to the direction CSS property. The current version of this document does not define any linebreaking algorithm for the mrow element, user agents may just ignore linebreaking rules.

User agents must follow the rules for inferred mrows described in [MathML3]. For example, to layout <msqrt>child_1 child_2 child_3 ...</msqrt>, one must follow the layout rules described for msqrt in section 3.3.3 using the box of <mrow>child_1 child_2 child_3 ... child_N</mrow> as the base.

The <mrow>child_1 child_2 child_3 ... child_N</mrow> element is laid out as show on figure 8. The boxes of $\text{child}_{1}$, $\text{child}_{2}$, … $\text{child}_{N}$ are put in a horizontal row one after the other with all their baselines aligned. As a consequence of this and of child box models, graphical elements such as fraction bars or symmetric stretchy operators will also be aligned along the math axis when the AxisHeight is unchanged (e.g. in the typical case where the math font is unchanged).

As indicated in section A, we generally do not add special spacing around the children. For example, the leading and trailing spacing is already included in the box metrics of embellished operators. The only exception is for the italic correction: when a “slanted” child is followed by a “straight” child, then an horizontal space corresponding to the italic correction of the “slanted” child is added between the two children [OpenFontFormat3]. The italic correction of the last child is also added after that child when it is “slanted” and when the mrow has more than one child. In this document, we interpret “slanted” as a child that is not an operator with largeop="true" (or an embellished operator whose mo element core has largeop="true") and has nonzero italic correction and “straight” as “non-slanted”.

When the mrow element contains only one child then the previous description implies that the box metrics of the mrow is the same as the one of its unique child. As indicated in section 3.1.1, we thus use the italic correction and top accent attachment of the child as the corresponding values of the mrow box.

### 3.3.2 Fractions <mfrac>

The MathML specification describes mfrac as follows [MathML3]:

The mfrac element is used for fractions. It can also be used to mark up fraction-like objects such as binomial coefficients and Legendre symbols. The syntax for mfrac is
<mfrac> numerator denominator </mfrac>
The mfrac element sets displaystyle to "false", or if it was already false increments scriptlevel by 1, within numerator and denominator.

The displaystyle and scriptlevel changes be achieved with the following style in the user agent stylesheet as suggested in section 2.3.2:

 mfrac > * { mathml-script-level: auto; mathml-math-style: inline; }

The axis of the mfrac element is always given by AxisHeight.

The default line thickness is given by FractionRuleThickness Use the linethickness attribute [MathML3] to determine the actual thickness of the fraction bar. A percent or unitless length is interpreted as a multiple of the default rule thickness and the named values ”thin”, ”medium” and ”thick” are interpreted as 50%, 100%, 200%. The color and visibility of the fraction bar must honor the values given by the color and visibility CSS properties on the mfrac element.

If the actual line thickness is nonzero, the mfrac element is laid out as shown on figure 9. The width is given by the maximum width of the numerator and denominator and the numerator and denominator are horizontally centered. A fraction bar with the actual thickness is drawn centered on the axis height. The numerator and denominator are shifted up and down using the values FractionNumeratorShiftUp, FractionDenominatorShiftDown in inline style and FractionNumeratorDisplayStyleShiftUp, FractionDenominatorDisplayStyleShiftDown in display style. If necessary, these shift values are increased to ensure that the gaps between the numerator/denominator and fraction bar satisfy the minimal values provided by FractionDenominatorGapMin and FractionNumeratorGapMin in inline style and FractionDenominatorDisplayStyleGapMin and FractionNumeratorDisplayStyleGapMin in display style.

If the actual line thickness is zero, the mfrac element is instead laid out as shown on figure 10. The gap between the top and bottom boxes is equally split around the axis height. The relevant shift values are now StackTopShiftUp, StackBottomShiftDown in inline style and StackTopDisplayStyleShiftUp, StackBottomDisplayStyleShiftDown in display style. If necessary, the two shift values are increased by a same value to ensure the gap between the top and bottom boxes satisfy the values provided by by StackGapMin in inline style and StackDisplayStyleGapMin in display style.

If the numerator is an embellished operator and the mfrac element is the outermost element in this embellished operator hierarchy then the operator leading and trailing spaces must be added around the fraction.

User agents may extend the box model to support the numalign, denomalign and bevelled attributes [MathML3].

The MathML specification describes radicals as follows [MathML3]:

These elements construct radicals. The msqrt element is used for square roots, while the mroot element is used to draw radicals with indices, e.g. a cube root. The syntax for these elements is:
<msqrt> base </msqrt>
<mroot> base index </mroot>

The mroot element requires exactly 2 arguments. However, msqrt accepts a single argument, possibly being an inferred mrow of multiple children.
The mroot element increments scriptlevel by 2, and sets displaystyle to "false", within index, but leaves both attributes unchanged within base. The msqrt element leaves both attributes unchanged within its argument. […]
Note that in a RTL directionality, the surd begins on the right, rather than the left, along with the index in the case of mroot.

The displaystyle and scriptlevel changes be achieved with the following style in the user agent stylesheet as suggested in section 2.3.2:

 mroot > :not(:first-child) { mathml-script-level: increment 2; mathml-math-style: inline; }

The line thickness of the overbar is given by RadicalRuleThickness. The gap between the overbar and base is given by RadicalVerticalGap in inline style and RadicalDisplayStyleVerticalGap in display style. The ascent above the overbase is given by RadicalExtraAscender. The surd is drawn by trying to vertically stretch the character U+221A SQUARE ROOT to at least the sum of the ink height of the base, the radical gap and the radical rule thickness. If the CSS direction is set to right-to-left, then the surd is actually drawn from the glyph obtained by mirroring U+221A SQUARE ROOT via the rtlm OpenType feature. The color and visibility of the surd and overbar must honor the values given by the color and visibility CSS properties on the msqrt element.

The msqrt element is laid out as shown on figure 11. The width is given by the sum of the width of the surd and of the base. The baseline of the square root matches the baseline of the base. The ink box is determined from the ink boxes of the surd and base while the logical box takes into account the extra ascender

The mroot element is laid out as shown on figure 12. We start by ignoring the root index and we layout the base and surd as shown on figure 11 to obtain a box $B$. The horizontal metrics of the mroot element are obtained by putting RadicalKernBeforeDegree before the root index, then placing the root index, then a kerning of RadicalKernAfterDegree after the root index and finally placing $B$. In general the kerning before the root index is positive while the kerning after it is negative, which means that the root element will have some space before it and that the root index will overlap the surd. For the vertical metrics of the mroot element, we first take the baseline of $B$ as the baseline. We graduate the ink height of $B$ with a linear scale going from the bottom at coordinate 0 to the top at coordinate 1. Then the baseline of the root index will be vertically positioned at coordinate RadicalDegreeBottomRaisePercent. Finally, we take into consideration the box of the root index and $B$ to deduce the metrics for the whole box of the mroot element.

### 3.3.4 Style Change <mstyle>

The MathML specification has a long description of mstyle with several ways to interpret the attributes, to handle inheritance and to deal with additional exceptions. The most important points are [MathML3]:

The mstyle element is used to make style changes that affect the rendering of its contents. […]
The mstyle element accepts a single argument, possibly being an inferred mrow of multiple children […]
Loosely speaking, the effect of the mstyle element is to change the default value of an attribute for the elements it contains. Style changes work in one of several ways, depending on the way in which default values are specified for an attribute.

For the layout algorithm described in this document, the mstyle element must be treated the same as the mrow element. However, some attributes on the mstyle element must be mapped to CSS properties as indicated in section 2.3.1. All the other mstyle attributes not defined in this document must be ignored.

### 3.3.5 Error Message <merror>

The MathML specification describes merror as follows [MathML3]:

The merror element displays its contents as an ”error message”. This might be done, for example, by displaying the contents in red, flashing the contents, or changing the background color. The contents can be any expression or expression sequence.
merror accepts a single argument possibly being an inferred mrow of multiple children. […]

For the layout algorithm described in this document, the merror element must be treated the same as the mrow element. The user agent stylesheet must set some CSS properties on the merror element in order to highlight the error. As suggested in section 2.3.2, this can for example be achieved with the rule:

 merror { outline: solid thin red; background-color: lightYellow; }

The MathML specification describes mpadded as follows [MathML3]:

An mpadded element renders the same as its child content, but with the size of the child’s bounding box and the relative positioning point of its content modified according to mpadded’s attributes. […]
The mpadded element accepts a single argument which may be an inferred mrow of multiple children

See [MathML3] for how the metrics of mpadded element are determined. Note that pseudo-units allows horizontal metrics to depend on vertical metrics, for example width="2height" which can be problematic to determine intrinsic widths. Hence in the present document, if the value of the width and lspace attributes contains ”height” or ”depth” pseudo-units, then they must be ignored.

The mpadded element is laid out as shown on figure 13. The height, depth and width of the content in [MathML3] corresponds to the logical box of the content. The content of the mpadded element is positioned from the origin of the mpadded element as follows: We shift the content forward by a distance of lspace and shift it upward by a distance of voffset. The logical metrics of the mpadded element are given by the height, depth and width of the mpadded element described in [MathML3]. The ink metrics of the mpadded element match their logical metrics.

### 3.3.7 Making Sub-Expressions Invisible <mphantom>

The MathML specification describes mphantom as follows [MathML3]:

The mphantom element renders invisibly, but with the same size and other dimensions, including baseline position, that its contents would have if they were rendered normally. […]
The mphantom element accepts a single argument possibly being an inferred mrow of multiple children […]

For the layout algorithm described in this document, the mphantom element must be treated the same as the mrow element. The user agent stylesheet must set some CSS properties on the mphantom element in order to hide its content. As suggested in section 2.3.2, this can for example be achieved with the rule:

 mphantom { visibility: hidden; }

### 3.3.8 Expression Inside Pair of Fences <mfenced>

The MathML specification has a long description of mfenced with several exceptions for the parsing of its attributes. It gives a strict equivalence between mfenced and constructions that rely exclusively on mo and mrow elements Here is the main point [MathML3]:

The mfenced element provides a convenient form in which to express common constructs involving fences (i.e. braces, brackets, and parentheses), possibly including separators (such as comma) between the arguments. […]

This document does define any layout algorithm for the mfenced element. User agents may just treat them as equivalent to the mrow element or to an merror element with a relevant error message indicating unsupported markup. Alternatively, mfenced may be implemented using a shadow tree, anonymous boxes, or any other methods that produce the same rendering as the equivalent constructions with mo and mrow elements.

Authors are encouraged to use the equivalent constructions with mo and mrow elements, instead of relying on the mfenced element.

### 3.3.9 Enclose Expression Inside Notation <menclose>

The MathML specification describes menclose as follows [MathML3]:

The menclose element renders its content inside the enclosing notation specified by its notation attribute. menclose accepts a single argument possibly being an inferred mrow of multiple children […]

The color and visibility of the menclose notations must honor the values given by the color and visibility CSS properties on the menclose element.

Based on [OpenFontFormat3] [TeXBook], we use the notation $\xi_{8}$ from the TeXBook to denote the default rule thickness and use $3\xi_{8}$ for gaps. We actually let $\xi_{8}$ be OverbarRuleThickness. Contrary to what is done in general, the $x$-axis direction of all notations except radical are independent of the CSS direction. In order to determine the metrics of the menclose notation, we compute each notation individually and take the union of the metrics:

1. 1.

The left notation is drawn by putting a vertical bar of thickness $\xi_{8}$ on the left of the content of the menclose element. The length of the bar is obtained by extending the height of the content with OverbarVerticalGap plus OverbarRuleThickness above and UnderbarVerticalGap plus UnderbarRuleThickness below. The gap between the bar and the content is $3\xi_{8}$. The logical box is obtained by adding some space of width $\xi_{8}$ on the left of the bar. See figure 14.

2. 2.

The right notation is drawn the same as the left notation, but with the vertical bar placed on the right.

3. 3.

The top notation is drawn by putting an overbar of thickness OverbarRuleThickness over the content of the menclose element. The length of the bar is obtained by extending the width of the content with $4\xi_{8}$ on each side. The gap between the overbar and the content is OverbarVerticalGap. The logical box is obtained by adding some space of height OverbarExtraAscender above the bar. See figure 15.

4. 4.

The bottom notation is drawn the same as the top notation, but with the vertical bar placed below the content and using parameters UnderbarRuleThickness, UnderbarVerticalGap. and UnderExtraDescender.

5. 5.

The box notation is treated as equivalent to left right top bottom.

6. 6.

To draw the roundedbox notation, we consider the box obtained by expanding the ink box by $\frac{7\xi_{8}}{2}$ on each side. Using SVG terminology, we draw a rounded rectangle on this expanded box with parameters rx, ry and stroke-width set to $\xi_{8}$ [SVG11]. To obtain the logical box we again add a space of $\xi_{8}$ on each side of the ink box. See figure 16.

7. 7.

The actuarial notation is treated as equivalent to right top.

8. 8.

The madruwb notation is treated as equivalent to right bottom.

9. 9.

The horizontalstrike notation is drawn with an horizontal bar of thickness $\xi_{8}$ and vertically centered inside the menclose content. This does not change the box metrics. See figure 17.

10. 10.

The verticalstrike notation is drawn the same as verticalstrike but with a vertical bar of thickness $\xi_{8}$ and horizontally centered inside the menclose content.

11. 11.

The updiagonalstrike notation is drawn with a line of thickness $\xi_{8}$ going from the bottom left corner of the menclose content to its top right corner. Using SVG terminology, the stroke-linecap of the line is butt [SVG11]. As an approximation, the ink box is set equal to the logical box and obtained by increasing the original box from each side by $\frac{\xi_{8}}{2}$. See figure 18.

12. 12.

The downdiagonalstrike notation is drawn as an updiagonalstrike but the line strike goes from the top left corner to the bottom right corner. Using SVG terminology, the stroke-linecap of the line is butt [SVG11].

13. 13.

The radical notation is drawn as described for msqrt in section 3.3.3.

14. 14.

The longdiv notation is drawn as radical but independent of CSS direction. U+221A SQUARE ROOT is replaced with U+0028 LEFT PARENTHESIS. The rule thickness is $\xi_{8}$, the gap between content and overbar is $3\xi_{8}$ and the extra ascender is $\xi_{8}$.

15. 15.

To draw the circle notation, we first consider the ink box of width $w$ and height $h$. We draw the ellipse of axes the axes of symmetry of this ink box, of radii $\frac{\sqrt{2}}{2}w$ and $\frac{\sqrt{2}}{2}h$ and of thickness $\xi_{8}$. We ensure that the logical box also has space $\xi_{8}$ around each side of the ellipse ink box.

16. 16.

Other menclose notations may be ignored.

## 3.4 Script and Limit Schemata

### 3.4.1 Subscripts and Superscripts <msub>, <msup>, <msubsup>

The MathML specification describes Subscripts and Superscripts as follows [MathML3]:

The msub element attaches a subscript to a base using the syntax
<msub> base subscript </msub>
It increments scriptlevel by 1, and sets displaystyle to "false", within subscript, but leaves both attributes unchanged within base. […]
The msup element attaches a superscript to a base using the syntax
<msup> base superscript </msup>
It increments scriptlevel by 1, and sets displaystyle to "false", within superscript, but leaves both attributes unchanged within base. […]
The msubsup element is used to attach both a subscript and superscript to a base expression.
<msubsup> base subscript superscript </msubsup>
It increments scriptlevel by 1, and sets displaystyle to "false", within subscript and superscript, but leaves both attributes unchanged within base. […]

As suggested in section section 2.3.2, the displaystyle and scriptlevel changes be achieved with the following style in the user agent stylesheet:

 msub > :not(:first-child), msup > :not(:first-child), msubsup > :not(:first-child) { mathml-script-level: increment 1; mathml-math-style: inline; }

The msub element is laid out as shown on figure 20. The baseline is the baseline of the base and the subscript is shifted down by SubShift. SubShift is initially set to SubscriptShiftDown and is increased until the shift SubTopShift for the top of the subscript is at least SubscriptTopMax. When determining the logical box, a space of width SpaceAfterScript is added after the subscript. By default, the leading edge of the subscript is aligned with the trailing edge of the base. However, if the base is an operator with largeop="true" (or an embellished operator whose mo element core has largeop="true") the subscript is horizontally shifted backward by the italic correction of the base.

The msup element is laid out as shown on figure 21. The baseline is the baseline of the base and the superscript is shifted up by SuperShift. If the msup element is cramped (section A) SuperShift is initially set to SuperscriptShiftUpCramped otherwise it is set to SuperscriptShiftUp. SuperShift is increased until the shift for the bottom of the superscript SuperBottomShift is at least SuperscriptBottomMin. When determining the logical box, a space of width SpaceAfterScript is added after the superscript. By default, the leading edge of the superscript is aligned with the trailing edge of the base and shifted forward by the italic correction of the base, except if the base is an operator with largeop="true" (or an embellished operator whose mo element core has largeop="true").

The msubsup element is laid out as shown on figure 22. The baseline is the baseline of the base, the subscript is shifted down by SubShift and the superscript is shifted up by SuperShift. SubShift is initially set to SubscriptShiftDown. If the msubsup element is cramped (section A) then SuperShift must be at least SuperscriptShiftUpCramped otherwise it must be at least SuperscriptShiftUp (see section A). SupShift is increased until the shift for the bottom of the superscript SupBottomShift is at least SuperscriptBottomMin. We then increase the gap SubSuperGap between the bottom of the superscript and the top of the subscript until it is at least SubSuperscriptGapMin: This is first done by continuing to shift the superscript up as long as the SupBottomShift does not exceed SuperscriptBottomMaxWithSubscript and next by continuing to shift the subscript down. When determining the logical box, a space of width SpaceAfterScript is added after each script. By default the leading edges of the scripts are aligned with the trailing edge and either the superscript is shifted forward by the italic correction of the base. However, if the base is an operator with largeop="true" (or an embellished operator whose mo element core has largeop="true") then instead the subscript is shifted forward by the italic correction of the base.

User Agents may ignore the attributes subscriptshift and superscriptshift or may interpret them as minimal values to satisfy when determining SubShift and SuperShift respectively.

### 3.4.2 Underscripts and Overscripts <munder>, <mover>, <munderover>

The MathML specification describes Underscripts and Overscripts as follows [MathML3]:

The munder element attaches an accent or limit placed under a base using the syntax
<munder> base underscript </munder>
It always sets displaystyle to "false" within the underscript, but increments scriptlevel by 1 only when accentunder is "false". Within base, it always leaves both attributes unchanged.[…]
If base is an operator with movablelimits="true" (or an embellished operator whose mo element core has movablelimits="true"), and displaystyle="false", then underscript is drawn in a subscript position. In this case, the accentunder attribute is ignored. […]
The mover element attaches an accent or limit placed over a base using the syntax
<mover> base overscript </mover>
It always sets displaystyle to "false" within overscript, but increments scriptlevel by 1 only when accent is "false". Within base, it always leaves both attributes unchanged.[…]
If base is an operator with movablelimits="true" (or an embellished operator whose mo element core has movablelimits="true"), and displaystyle="false", then overscript is drawn in a superscript position. In this case, the accent attribute is ignored.[…]
The munderover element attaches accents or limits placed both over and under a base using the syntax
<munderover> base underscript overscript </munderover>
It always sets displaystyle to "false" within underscript and overscript, but increments scriptlevel by 1 only when accentunder or accent, respectively, are "false". Within base, it always leaves both attributes unchanged. […]
If base is an operator with movablelimits="true" (or an embellished operator whose mo element core has movablelimits="true"), and displaystyle="false", then underscript and overscript are drawn in a subscript and superscript position, respectively. In this case, the accentunder and accent attributes are ignored. […]

User Agents must perform the scriptlevel increment by checking the appropriate accent or accentunder value, which can not be done using only CSS. However, displaystyle changes can be achieved with the following style in the user agent stylesheet, as suggested in section 2.3.2:

 munder > :not(:first-child), mover > :not(:first-child), munderover > :not(:first-child) { mathml-math-style: inline; }

In cases where underscript and overscript are drawn as subscript and superscript position then the layout algorithm is the same as section 3.4.1. Note that in that case, accent or accentunder are ignored so the scriptlevel increment is always performed.

The general layout of munderover is shown on figure 23. The overscript is placed above the base, the underscript below the base and by default are aligned with respect to their geometrical center. If the overscript is an accent and has a TopAccentAttachment value, then this value may be used to horizontally align the accent instead of its geometrical center. OverShift is the distance between the top ink of the base and the baseline of the overscript, OverGap is the distance between the top ink of the base and the bottom ink of the overscript, OverExtraAscender is extra space to add above the overscript when determining the logical box. UnderShift, UnderGap and UnderExtraAscender are defined similarly for the underscripts. We distinguish three cases:

1. 1.

If the base is an operator with largeop="true" (or an embellished operator whose mo element core has largeop="true") then ensure that OverGap is at least UpperLimitGapMin, that OverShift is at least UpperLimitBaselineRiseMin that UnderGap is at least LowerLimitGapMin, that UnderShift is at least LowerLimitBaselineDropMin. OverExtraAscender and UnderExtraAscender are zero. The underscript is shifted backward by half the italic correction of the base. The overscript is shifted forward by half the italic correction of the base.

2. 2.

If the base is an operator with stretchy="true" (or an embellished operator whose mo element core has stretchy="true"). Then ensure that OverGap is at least StretchStackGapBelowMin, that OverShift is at least StretchStackTopShiftUp that UnderGap is at least StretchStackGapAboveMin, that UnderShift is at least StretchStackBottomShiftDown. OverExtraAscender and UnderExtraAscender are zero.

3. 3.

In other cases we proceed as follows. We first ensure that UnderGap is at least UnderbarVerticalGap. If overscript is an accent and the ink ascent of the base does not exceed AccentBaseHeight then we just align the baseline of the overscript with the baseline of the base. Otherwise, we ensure that OverGap is at least OverbarVerticalGap. Finally, OverExtraAscender and OverExtraAscender are respectively set to OverbarExtraAscender and UnderExtraAscender.

The layout of munder and mover is the same as the one of munderover except that one script and its corresponding extra space are ignored.

User Agents may ignore the align attribute. Alternatively, when it is either left or right, then it may be used to the alignment of the base, underscript and overscript along the specified edge. Note that these values are independent of CSS direction.

### 3.4.3 Prescripts and Tensor Indices <mmultiscripts>

The MathML specification describes the mmultiscripts element as follows [MathML3]:

Presubscripts and tensor notations are represented by a single element, mmultiscripts, using the syntax:
<mmultiscripts>
base
(subscript superscript)*
[ <mprescripts/> (presubscript presuperscript)* ]
</mmultiscripts>

This element allows the representation of any number of vertically-aligned pairs of subscripts and superscripts, attached to one base expression. It supports both postscripts and prescripts. Missing scripts can be represented by the empty element none.
[…]
The mmultiscripts element increments scriptlevel by 1, and sets displaystyle to "false", within each of its arguments except base, but leaves both attributes unchanged within base. […]

The displaystyle and scriptlevel changes be achieved with the following style in the user agent stylesheet as suggested in section 2.3.2:

 mmultiscripts > :not(:first-child) { mathml-script-level: increment 1; mathml-math-style: inline; }

Any layout for mmultiscripts is acceptable as long as it follows the condition of the MathML 3 specification [MathML3] and is consistent with section 3.4.1 for mmultiscripts contructions that are equivalent to msubsup. Here is a possible algorithm that is represented on figure 24.

1. 1.

Determine the vertical shifts for each subscript/superscript pair using the algorithm for msub (if the superscript is none), msup (if the subscript is none) or msubsup (if none of the scripts are none) or otherwise use shifts of zero (if both scripts of the pair are none). When placing the scripts, use the maximum of the subscript shift for all subscript and the maximum of the superscript shift for all superscripts.

2. 2.

For the horizontal layout of postscripts, use the trailing edge of the base or of the previous pair as the leading edge of the current pair. For each pair, apply the same italic correction described for msubsup in section 3.4.1. Apply the same italic corrections for all these postscripts.

3. 3.

For the horizontal layout of prescripts, use the leading edge of the base or of next pair as the trailing edge of the current pair. Do not apply any italic correction for prescripts.

## 3.5 Tabular Math

The MathML specification describes tabular math as follows [MathML3]:

Matrices, arrays and other table-like mathematical notation are marked up using mtable, mtr, mlabeledtr and mtd elements. These elements are similar to the table, tr and td elements of HTML, except that they provide specialized attributes for the fine layout control necessary for commutative diagrams, block matrices and so on.

In the present document, we restrict ourselves to a minimal implementation compatible with HTML tables. First the mtable element must be treated as a HTML table and by [MathML3], mtable must accept a displaystyle attribute with default value false. To implement that, one may rely on the following rules for the user agent stylesheet as suggested in section 2.3.2:

 mtable { display: inline-table; mathml-math-style: inline; } mtable[displaystyle="true"] { mathml-math-style: display; }

In addition, user agents may use the following rules to emulate the frame attribute:

 mtable[frame="none"] { border: none; } mtable[frame="solid"] { border: solid thin; } mtable[frame="dashed"] { border: dashed thin; }

The mtr and mlabeledtr elements must be treated as HTML table rows and the label of mlabeledtr element must be hidden by default. The default value of rowalign must be baseline. One may rely on the following rules for the user agent stylesheet as suggested in section 2.3.2:

 mtr, mlabeledtr { display: table-row; vertical-align: baseline; } mlabeledtr > mtd:first-child { display: none; }

Finally, the mtd elements must be treated as a HTML table cell. The default value of rowalign must be baseline and the default value of colulmnalign must be center. User agents may also try to approximate the default rowspacing and columnspacing between cells. This can be achieved with the following CSS:

 mtd { display: table-cell; vertical-align: inherit; text-align: center; padding: 0.5ex 0.4em; }

The mtd element must also support the columnspan (sic) and rowspan attributes. This can be implemented the same way as the HTML colspan and rowspan attributes.

The layout for other tabular elements and attributes are not specified by this document.

## 3.6 Elementary Math

Elementary Math was introduced in version 3 of the MathML specification [MathML3]:

Mathematics used in the lower grades such as two-dimensional addition, multiplication, and long division tends to be tabular in nature. However, the specific notations used varies among countries much more than for higher level math. Furthermore, elementary math often presents examples in some intermediate state and MathML must be able to capture these intermediate or intentionally missing partial forms. Indeed, these constructs represent memory aids or procedural guides, as much as they represent ‘mathematics’.
The elements used for basic alignments in elementary math are:
mstack: align rows of digits and operators msgroup: groups rows with similar alignment msrow: groups digits and operators into a row msline: draws lines between rows of the stack mscarries: annotates the following row with optional borrows/carries and/or crossouts mscarry: a borrow/carry and/or crossout for a single digit mlongdiv: specifies a divisor and a quotient for long division, along with a stack of the intermediate computations mfenced […]

This document does not define any layout algorithm for the mstack, msgroup, msrow, msline, mscarries, mscarry and mlongdiv elements.

## 3.7 Enlivening Expressions

The MathML specification describes maction as follows [MathML3]:

To provide a mechanism for binding actions to expressions, MathML provides the maction element. This element accepts any number of sub-expressions as arguments and the type of action that should happen is controlled by the actiontype attribute. Only three actions are predefined by MathML, but the list of possible actions is open.

User agents must display at most one of the child of a maction element. User agents must determine the visible child as follows:

1. 1.

If actiontype is toggle and the selection attribute (with default value 1) points to a valid child index between 1 and the number of children, then use the specified child.

2. 2.

If the actiontype is statusline or tooltip then use the first child (if any).

3. 3.

Otherwise, the visible child is undetermined.

For the layout algorithm described in this document, the maction element must be treated the same as the mrow element containing its visible child. If it is undetermined, the user agent may treat the maction element as an empty mrow element or as an merror element with some relevant error message indicating invalid or unsupported markup.

User agents may additionally provide a complete implementation of the toggle actiontype updating the value of the selection attribute after the maction element receives a click event. For statusline and tooltip attributes, they may also display the second child in some way when the maction element receives a hover event. This document does not define how these DOM events are propagated or how to change the default behavior.

Given the similarity with the semantics element described in section 3.8, it is suggested to share the implementation of semantics and maction.

## 3.8 Semantics and Presentation

The MathML specification describes semantics as follows [MathML3]:

The semantics element is the container element that associates annotations with a MathML expression. The semantics element has as its first child the expression to be annotated. Any MathML expression may appear as the first child of the semantics element. Subsequent annotation and annotation-xml children enclose the annotations. An annotation represented in XML is enclosed in an annotation-xml element. An annotation represented in character data is enclosed in an annotation element. […]

User agents must display at most one of the child of a semantics element. For example, they may always display the first child (if any) or may use this more advanced algorithm to determine a visible child:

1. 1.

If the semantics element has a first child that is any of the MathML elements (other than annotation and annotation-xml) whose rendering is described in this document then use it as the visible child and stop.

2. 2.

Otherwise, check the children of the semantics element in the DOM order to try and find the first child that is

1. (a)

Either an annotation without any src attribute.

2. (b)

Or an annotation-xml without any src attribute and with an encoding attribute that has value "application/mathml-presentation+xml", "MathML-Presentation", "image/svg+xml", "SVG1.1", "application/xhtml+xml" or "text/html".

3. 3.

Otherwise, fallback to the first child (if any).

4. 4.

Otherwise, the semantics element is empty and the visible child is undetermined.

For the layout algorithm described in this document, the annotation-xml element must be treated the same as the mrow element, the annotation element must be treated the same as the mtext element. The semantics element must be treated the same as an mrow element containing only its visible child. If it is undetermined, the user agent may treat the semantics element as an empty mrow element or as an merror element with some error message indicating invalid markup.

Given the similarity with the maction element described in section 3.7, it is suggested to share the implementation of semantics and maction.

# Appendix A MathML

The mstyle element duplicates the CSS inheritance mechanism in a CSS-incompatible way and has ugly exceptions to workaround the fact that attribute names may be used for different purposes. In practice, many of its attributes are not useful and never used. It is a burden for implementers since they essentially have to reimplement a specific “attribute” inheritance mechanism to support the general case even if the most prominent attributes have obvious mapping to CSS. It is also a performance issue to perform the rendering and keep it up-to-date since the rendering on any node may depend on its mstyle ancestors. In this document, it instead suggested to keep only attributes that are compatible with CSS and five new CSS properties are introduced in section 2.3.1. These attributes actually correspond to what is used in practice.

The element is just a “convenient form in which to express common constructs involving fences” but is strictly equivalent to an expanded form with and elements and has many horrible exceptions to handle. It is thus not actually necessary and just requires more code for implementers and may lead to rendering inconsistencies with the expanded form. It requires web rendering engines to create many “anonymous” rendering frames (or similar) and keep them up-to-date which may lead to rendering, performance or security issues. Because the text of fences and separators is included in attributes and not in MathML elements then by default it may not be possible to search, select, copy it. It may also not be exposed to assitive technologies without further effort. In this document support for mfenced is not required. Authors are encouraged to use the expanded form and we recommend that the element is dropped from future version of the MathML specification.

The “radical” notation of the element is equivalent to the element. Again, this adds duplicate logic for visual rendering and exposure to assistive technologies. In practice, the is always used for square roots. We suggest to remove the “radical” notation in future version of the MathML specification.

As explained in section 3.1.2 it is important in a HTML5 context to be able to determine the min-content width and the max-content width for linebreaking purpose. However, the mpadded element may be problematic since the pseudo-units allow horizontal metrics to depend on vertical metrics. A restriction is proposed in section 3.3.6 and should not be problematic in practice.

The TeXBook’s Appendix G as well as the OpenType MATH table rely on the “cramped” concept to adjust spacing. This is absent from the MathML specification. A simple way to determine when an element is cramped is proposed in section .

# Appendix B CSS

Some mstyle attributes follow the standard CSS inheritance and can be easily implemented by mapping them to CSS properties. Five new CSS properties would be needed for that purpose and are proposed in section 2.3.1:

1. 1.

mathml-math-style (cf table 2.3.1)

2. 2.

mathml-math-variant (cf table 2.3.1)

3. 3.

mathml-script-level (cf table 2.3.1)

4. 4.

mathml-script-size-multiplier (cf table 2.3.1)

5. 5.

mathml-script-min-size (cf table 2.3.1)

In practice, only the first three properties are involved (either implicity or explicitly) in documents with MathML content while the default values are almost always used for the two last properties. Hence, these three first properties seem the most important to consider.

# Appendix C OpenType

It is not clear how the DisplayOperatorMinHeight is supposed to be used or whether it is really reliable. More specifically, integral symbols (e.g. INTEGRAL U+222B) are typically taller than N-ary operators (e.g. N-ARY SUMMATION U+2211) so a unique minimal height may not always be enough to determine the display size. Suppose for example that the sum has three size variants: the base size of height 1em, the display size of height 2em and a bigger variant of height 3em. Suppose that the integral has three sizes: a base size of height 1em, a larger size variant of height 2em and a display size of height 3em. If DisplayOperatorMinHeight is less than 3em then it does not force the display size of the integral to be selected. If it is more than 3em then none of the available sizes satisfies the condition. How to interpret that? Should we pick the largest as a fallback? If it is 3em, the desired size will be selected for the integral in display size but the one selected for the sum in display size will be too large. A heuristic is proposed in section 3.2.4 to workaround limitations of DisplayOperatorMinHeight.

The OpenType MATH specification does not seem to take into account linebreaking. As explained in section 3.1.2 it is important in a HTML5 context to be able to determine the min-content width and the max-content width. However when an operator is stretched vertically to cover a target size, it is not possible to know the selected size variant or glyph assembly without knowing the target size and so the min-content and max-content widths can only be approximated. In practice, the width of the vertical operators is almost independent on its stretch size. Should that be a requirement of the OpenType MATH specification?

In section 3.3.9 we describe the MathML menclose element. This one contains many notations that are not mentioned in the OpenType MATH specification. Some rendering suggestions are given based on the value of OverbarRuleThickness but perhaps new values should be introduced in the MathConstants subtable to cover these notations.