3 Presentation Markup

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 <math> 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 <math> 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:

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.

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 <math> 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 <math> element. Similarly, the final layout of this anonymous <mrow> is already done when we want to perform the one of its ancestors.

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.

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.

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.

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 math axis, which is given by the AxisHeight value. 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.

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

Add detailed rules for ssty

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

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.

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:

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.

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:

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.

In order to prevent the fraction bar to be confused with other items around the fraction (e.g. minus sign or the bar of another fraction), a 1 pixel space must actually be added on each side of the mfrac element.

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:

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 ink bottom 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.

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.

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:

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.

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:

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.

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. Note that contrary to what is done in general and unless specified otherwise, the $x$-axis direction of notations is assumed to be 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 $3\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 horizontalstrike 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 longdiv notation is drawn similarly to the msqrt element (figure 11). It is independent of CSS direction and U+221A SQUARE ROOT is replaced with U+0029 RIGHT PARENTHESIS. The rule thickness is $\xi_{8}$, the gap between content and overbar is $3\xi_{8}$ and the extra ascender is $\xi_{8}$.

14. 14.

    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.

15. 15.

    This document does define any layout algorithm for other menclose notations. User agents may ignore them.

Authors are encouraged to use the msqrt element to represent square roots instead of relying on the radical notation of the menclose element.

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:

The msub element is laid out as shown on figure 20. The baseline is the baseline of the base while the baseline of the script is shifted down by SubShift, which is the minimal value honoring the following conditions:

1. 1.

   SubShift is at least SubscriptShiftDown.

2. 2.

   The top of the subscript SubTop with respect to the baseline is not above SubscriptTopMax.

3. 3.

   The drop SubscriptBaselineDrop from the bottom of the base to the baseline of the script is at least SubscriptBaselineDropMin.

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 while the baseline of the script is shifted up by SuperShift, which is the minimal value honoring the following conditions:

1. 1.

   SuperShift is at least SuperscriptShiftUpCramped if the msup element is cramped (section A) or at least SuperscriptShiftUp otherwise.

2. 2.

   The bottom of the superscript SuperBottom with respect to the baseline is not below SuperscriptBottomMin.

3. 3.

   The drop SuperscriptBaselineDrop from the top of the base to the baseline of the script is at most SuperscriptBaselineDropMax.

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 while the baseline of the script is shifted down by SubShift and the superscript is shifted up by SuperShift which is initially set to the minimal values honoring the following conditions:

1. 1.

   SubShift is at least SuperscriptShiftUpCramped if the msup element is cramped (section A) or at least SuperscriptShiftUp otherwise.

2. 2.

   The top of the subscript SubTop with respect to the baseline is not above SubscriptTopMax.

3. 3.

   The drop SuperscriptBaselineDrop from the top of the base to the baseline of the superscript is at most SuperscriptBaselineDropMax.

4. 4.

   SubShift is at least SuperscriptShiftUpCramped if the msup element is cramped (section A) or at least SuperscriptShiftUp otherwise.

5. 5.

   The bottom of the superscript SuperBottom with respect to the baseline is not below SuperscriptBottomMin.

6. 6.

   The drop SubscriptBaselineDrop from the bottom of the base to the the baseline of the subscript is at least SubscriptBaselineDropMin.

We then increase the gap SubSuperGap between the bottom of the superscript and the top of the subscript to ensure it is at least SubSuperscriptGapMin: This is first done by continuing to shift the superscript up as long as the SuperBottom 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.

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:

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 UnderExtraDescender 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 UnderExtraDescender 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 a horizontal operator with stretchy="true" (or a horizontal 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 UnderExtraDescender are zero.

3. 3.

   In other cases we proceed as follows. There are not any specific conditions to satisfy on OverShift or UnderShift. OverExtraAscender and OverExtraAscender are respectively set to OverbarExtraAscender and UnderExtraDescender. We set UnderGap to UnderbarVerticalGap if the underscript is not an accent and to zero otherwise. We set OverGap to OverbarVerticalGap if the overscript is not an accent and generally to zero otherwise. However, if overscript is an accent and if the base ascent is at most AccentBaseHeight then we actually set OverGap to their nonnegative difference.

Remark: For accent overscripts and bases with ascents that are at most AccentBaseHeight, the rule from [OpenFontFormat3] [TeXBook] is actually to align the baselines of the overscripts and of the bases. This assumes that accent glyphs are designed in such a way that their ink bottoms are more or less AccentBaseHeight above their baselines. Hence, the previous rule will guarantee that all the overscript bottoms are aligned while still avoiding collision with the bases. However, MathML can have arbitrary accent overscripts so we provide a more general and simpler rule above: Ensure that the bottom of overscript is at least AccentBaseHeight above the baseline of the base.

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.

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:

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.