MathML Core

This specification defines a core subset of Mathematical Markup Language, or MathML, that is suitable for browser implementation. MathML is a markup language for describing mathematical notation and capturing both its structure and content. The goal of MathML is to enable mathematics to be served, received, and processed on the World Wide Web, just as HTML has enabled this functionality for text.

MathML Fundamentals

Elements and attributes

The term MathML element refers to any element in the MathML namespace. The MathML element defined in this specification are called the MathML Core elements and are listed below. Any MathML element that is not listed below is called an Unknown MathML element.

<annotation>
<annotation-xml>
<maction>
<math>
<merror>
<mfrac>
<mi>
<mmultiscripts>
<mn>
<mo>
<mover>
<mpadded>
<mphantom>
<mprescripts>
<mroot>
<mrow>
<ms>
<mspace>
<msqrt>
<mstyle>
<msub>
<msubsup>
<msup>
<mtable>
<mtd>
<mtext>
<mtr>
<munder>
<munderover>
<none>
<semantics>

The grouping elements are <maction>, <math>, <merror> <mphantom>, <mprescripts>, <mrow>, <mstyle>, <none>, <semantics> and unknown MathML elements.

The scripted elements are <mmultiscripts>, <mover>, <msub>, <msubsup>, <msup>, <munder> and <munderover>.

The radical elements are <mroot> and <msqrt>.

The attributes defined in this specification have no namespace and are called MathML attributes:

Global attributes
Legacy maction attributes
mo attributes
mpadded attributes
mspace attributes
munderover attributes
mtd attributes
encoding
display
linethickness

The Top-Level `<math>` Element

MathML specifies a single top-level or root <math> element, which encapsulates each instance of MathML markup within a document. All other MathML content must be contained in a <math> element.

The <math> element accepts the attributes described in as well as the following attribute:

display

The display attribute, if present, must be an ASCII case-insensitive match to block or inline. The user agent stylesheet described in contains rules for this attribute that affect the default values for the display (block math or inline math) and math-style (normal or compact) properties. If the display attribute is absent or has an invalid value, the User Agent stylesheet treats it the same as inline.

If the element does not have its computed display property equal to block math or inline math then it is laid out according to the CSS specification where the corresponding value is described. Otherwise the layout algorithm of the <mrow> element is used to produce a box. That MathML box is used as the content for the layout of the element, as described by CSS for display: block (if the computed value is block math) or display: inline (if the computed value is inline math). Additionally, if the computed display property is equal to block math then that MathML box is rendered horizontally centered within the content box.

T_EX's display mode $$...$$ and inline mode $...$ correspond to display="block" and display="inline" respectively.

In the following example, a <math> formula is rendered in display mode on a new line and taking full width, with the math content centered within the container:

$math example (display)$

As a comparison, the same formula would look as follows in inline mode. The formula is embedded in the paragraph of text without forced line breaking. The baselines specified by the layout algorithm of the <mrow> are used for vertical alignement. Note that the middle of sum and equal symbols or fractions are all aligned, but not with the alphabetical baseline of the surrounding text.

$math example (inline)$

Because good mathematical rendering requires use of mathematical fonts, the user agent stylesheet should set the font-family to the math value on the <math> element instead of inheriting it. Additionally, several CSS properties that can be set on a parent container such as font-style, font-weight, direction or text-indent etc are not expected to apply to the math formula and so the user agent stylesheet has rules to reset them by default.

Types for MathML Attribute Values

unsigned-integer: An <integer> value as defined in [[CSS-VALUES-3]], whose first character is neither U+002D HYPHEN-MINUS character (-) nor U+002B PLUS SIGN (+).
length-percentage: A <length-percentage> value as defined in [[CSS-VALUES-3]]
color: A <color> value as defined in [[CSS-COLOR-3]]
boolean: A string that is an ASCII case-insensitive match to true or false.

Global Attributes

The following attributes are common to and may be specified on all MathML elements:

class
data-*
dir
displaystyle
id
mathbackground
mathcolor
mathsize
mathvariant
nonce
scriptlevel
style
tabindex
on* event handler attributes

Attributes common to HTML and MathML elements

The id, class, style, data-*, nonce and tabindex attributes have the same syntax and semantic as defined for id, class, style, data-*, nonce and tabindex attributes on HTML elements.

The dir attribute, if present, must be an ASCII case-insensitive match to ltr or rtl. In that case, the user agent is expected to treat the attribute as a presentational hint setting the element's direction property to the corresponding value. More precisely, an ASCII case-insensitive match to rtl is mapped to rtl while an ASCII case-insensitive match to ltr is mapped to ltr.

The dir attribute is used to set the directionality of math formulas, which is often rtl in Arabic speaking world. However, languages written from right to left often embed math written from left to right and so the user agent stylesheet resets the direction property accordingly on the <math> elements.

In the following example, the dir attribute is used to render "𞸎 plus 𞸑 raised to the power of (٢ over, 𞸟 plus ١)" from right-to-left.

All MathML elements support event handler content attributes, as described in event handler content attributes in HTML.

All event handler content attributes noted by HTML as being supported by all HTMLElements are supported by all MathML elements as well, as defined in the MathMLElement IDL.

Legacy MathML Style Attributes

The mathcolor and mathbackground attributes, if present, must have a value that is a color. In that case, the user agent is expected to treat these attributes as a presentational hint setting the element's color and background-color properties to the corresponding values. The mathcolor attribute describes the foreground fill color of MathML text, bars etc while the mathbackground attribute describes the background color of an element.

The mathsize attribute, if present, must have a value that is a valid length-percentage. In that case, the user agent is expected to treat the attribute as a presentational hint setting the element's font-size property to the corresponding value. The mathsize property indicates indicates the desired height of glyphs in math formulas but also scale other parts (spacing, shifts, line thickness of bars etc) accordingly.

The above attributes are implemented for compatibility with full MathML. Authors whose only target is MathML Core are encouraged to use CSS for styling.

The `mathvariant` attribute

The mathvariant attribute, if present, must be an ASCII case-insensitive match to one of: normal, bold, italic, bold-italic, double-struck, bold-fraktur, script, bold-script, fraktur, sans-serif, bold-sans-serif, sans-serif-italic, sans-serif-bold-italic, monospace, initial, tailed, looped, or stretched. In that case, the user agent is expected to treat the attribute as a presentational hint setting the element's text-transform property to the corresponding value. More precisely, an ASCII case-insensitive match to normal is mapped to none while any other valid value is mapped to its ASCII lowercased value, prefixed with math-.

The mathvariant attribute defines logical classes of token elements. Each class provides a collection of typographically-related symbolic tokens with specific meaning within a given mathematical expression. For mathvariant values other than normal, this is done by using glyphs of Mathematical Alphanumeric Symbols [[UNICODE]].

In the following example, the mathvariant attribute is used to render different A letters. Note that by default variables use mathematical italic.

mathvariant values other than normal are implemented for compatibility with full MathML and legacy editors that can't access characters in Plane 1 of Unicode. Authors are encouraged to use the corresponding Unicode characters. The normal value is still important to cancel automatic italic of the <mi> element.

It is sometimes needed to distinguish between Chancery and Roundhand style for MATHEMATICAL SCRIPT characters. These are notably used in LaTeX for the \mathcal and \mathscr commands.

One way to do that is to rely on Chapter 23.4 Variation Selectors of Unicode which describes a way to specify selection of particular glyph variants [[UNICODE]]. Indeed, the StandardizedVariants.txt file from the Unicode Character Database indicates that variant selectors U+FE00 and U+FE01 can be used on capital script to specify Chancery and Roundhand respectively.

Alternatively, some mathematical fonts rely on salt or ssXY properties from [[OPEN-FONT-FORMAT]] to provide both styles. Page authors may use the font-variant-alternates property with corresponding OpenType font features to access these glyphs.

The `displaystyle` and `scriptlevel` attributes

The displaystyle attribute, if present, must have a value that is a boolean. In that case, the user agent is expected to treat the attribute as a presentational hint setting the element's math-style property to the corresponding value. More precisely, an ASCII case-insensitive match to true is mapped to normal while an ASCII case-insensitive match to false is mapped to compact. This attribute indicates whether formulas should try to minimize the logical height (value is false) or not (value is true) e.g. by changing the size of content or the layout of scripts.

The scriptlevel attribute, if present, must have value +<U>, -<U> or <U> where <U> is an unsigned-integer. In that case the user agent is expected to treat the scriptlevel attribute as a presentational hint setting the element's math-depth property to the corresponding value. More precisely, +<U>, -<U> and <U> are respectively mapped to add(<U>) add(<-U>) and <U>.

displaystyle and scriptlevel values are automatically adjusted within MathML elements. To fully implement these attributes, additional CSS properties must be specified in the user agent stylesheet as described in . In particular, for all MathML elements a default font-size: math is specified to ensure that scriptlevel changes are taken into account.

In this example, a <munder> element is used to attach a script "A" to a base "∑". By default, the summation symbol is rendered with the font-size inherited from its parent and the A as a scaled down subscript. If displaystyle is true, the summation symbol is drawn bigger and the "A" becomes an underscript. If scriptlevel is reset to 0 on the "A", then it will use the same font-size as the top-level math root.

T_EX's \displaystyle, \textstyle, \scriptstyle, and \scriptscriptstyle correspond to displaystyle and scriptlevel as true and 0, false and 0, false and 1, and false and 2, respectively.

Integration in the Web Platform

HTML and SVG

When parsing HTML documents user agents must treat any tag name corresponding to a MathML Core Element as belonging to the MathML namespace.

Users agents must allow mixing HTML, SVG and MathML elements as allowed by sections HTML integration point, MathML integration point, tree construction dispatcher, MathML and SVG from [[HTML]].

When evaluating the SVG requiredExtensions attribute, user agents must claim support for the language extension identified by the MathML namespace.

In this example, inline MathML and SVG elements are used inside a HTML document. SVG elements <switch> and <foreignObject> (with proper <requiredExtensions>) are used to embed a MathML formula with a text fallback, inside a diagram. HTML input element is used within the <mtext> include an interactive input field inside a mathematical formula.

The <math> element can be used at position permitted for flow content (e.g. a <foreignObject> element) or phrasing content.
Any phrasing content can be used inside <mi>, <mo>, <mn>, <ms> and <mtext> elements.
The <svg> element can be used inside <annotation-xml> elements.
Any flow content can be used inside <annotation-xml> elements with encoding application/xhtml+xml or text/html.

CSS styling

User agents must support various CSS features mentioned in this specification, including new ones described in . They must follow the computation rule for display: contents.

In this example, the MathML formula inherits the CSS color of its parent and uses the font-family specified via the style attribute.

All documents containing MathML Core elements must include CSS rules described in as part of user-agent level style sheet defaults.

The following CSS features are not supported and must be ignored:

Vertical math layout: writing-mode is treated as horizontal-tb on all MathML elements.
Line breaking inside math formulas: white-space is treated as nowrap on all MathML elements.
Sizes: width, height, inline-size and block-size are treated as auto on elements with computed display value block math or inline math.
Floats: float and clear are treated as none on all MathML elements.
Alignment properties: align-content, justify-content, align-self, justify-self have no effect on MathML elements.

These features might be handled in future versions of this document. For now, authors are discouraged from setting a different value for these properties as that might lead to backward incompatibility issues.

DOM and Javascript

User agents supporting Web application APIs must ensure that they keep the visual rendering of MathML synchronized with the [[DOM]] tree, in particular perform necessary updates when MathML attributes are modified dynamically.

All the nodes representing MathML elements in the DOM must implement, and expose to scripts, the following MathMLElement interface.

The GlobalEventHandlers, DocumentAndElementEventHandlers and HTMLOrForeignElement interfaces are defined in [[HTML]].

Each IDL attribute of the MathMLElement interface reflects the corresponding MathML content attribute.

In the following example, a MathML formula is used to render the fraction "α over 2". When clicking the red α, it is changed into a blue β.

Rename HTMLOrSVGElement and define MathMLElement in [[HTML]].

Text layout

Because math fonts generally contain very tall glyphs such as big integrals, using typographic metrics is important to avoid excessive line spacing of text. As a consequence, user agents must take into account the USE_TYPO_METRICS flag from the OS/2 table [[OPEN-FONT-FORMAT]] when performing text layout.

Focus

MathML provides the ability for authors to allow for interactivity in supporting interactive user agents using the same concepts, approach and guidance to Focus as described in HTML, with modifications or clarifications regarding application for MathML as described in this section.

When an element is focused, all applicable CSS focus-related pseudo-classes as defined in Selectors Level 3 apply, as defined in that specification.

The contents of embedded <math> elements (including HTML elements inside token elements), contribute to the sequential focus order of the containing owner HTML document (combined sequential focus order).

Presentation Markup

Visual formatting model

Box Model

The default display property is described in :

For the <math> root, it is equal to inline math or block math according to the value of the display attribute.
For Tabular MathML elements <mtable>, <mtr>, <mtd> it is respectively equal to inline-table, table-row and table-cell.
For the all but the first children of the <maction> and <semantics> elements, it is equal to none.
For all the other MathML elements it is equal to block math.

In order to specify math layout in different writing modes, this specification uses concepts from [[CSS-WRITING-MODES-3]]:

abstract dimensions: block dimension, inline dimension, block axis, inline axis, block size, inline size.
flow-relative directions: inline-start, inline-end, block-start.
line-relative directions: line-left, line-over, line-under.

Unless specified otherwise, the figures in this specification use a writing mode of horizontal-lr and ltr. See , and for examples of other writing modes that are sometimes used for math layout.

MathML boxes have several parameters in order to perform layout in a way that is compatible with CSS but also to take into account very accurate positions and spacing within math formulas. Each math box has the following parameters:

Inline metrics. min-content inline size, max-content inline size and inline size from CSS. See .

Generic Box Model for MathML elements
Block metrics. The block size, first baseline set and last baseline set. The following baselines are defined for MathML boxes:
1. The alphabetic baseline which typically aligns with the bottom of uppercase Latin glyphs. The algebric distance from the alphabetic baseline to the line-over edge of the box is the called line-ascent. The algebric distance from the line-under edge to the alphabetic baseline of the box is the called line-descent.
2. The mathematical baseline also called math axis which typically aligns with the fraction bar, middle of fences and binary operators. It is shifted away from the alphabetic baseline by AxisHeight towards the line-over.
3. The ink-over baseline, indicating the line-over theorical limit of the content drawn, excluding any extra space. If not specified, it is aligned with the line-over edge. The algebric distance from the alphabetic baseline to the ink-over baseline is called the ink line-ascent.
4. The ink-under baseline, indicating the line-under theorical limit of the content drawn, excluding any extra space. If not specified, it is aligned with the line-under edge. The algebric distance from the ink-under baseline to the alphabetic baseline is called the ink line-descent.
For math layout, it is very important to rely on the ink extent when positioning text. This is not the case for more complex notations (e.g. square root). Although ink-ascent and ink-descent are defined for all MathML elements they are really only used for the token elements. In other cases, they just match normal ascent and descent.
Unless specified otherwise, the last baseline set is equal to the first baseline set for MathML boxes.
An optional italic correction which provides a measure of how much the text of a box is slanted along the inline axis. See .

Examples of italic correction for italic f and large integral

If it is requested during calculation of min-content inline size and max-content inline size or during layout then 0 is used as a fallback value.
An optional top accent attachment which provides a reference offset on the inline axis of a box that should be used when positioning that box as an accent. See .

Example of top accent attachment for a circumflex accent

If it is requested during calculation of min-content inline size (respectively max-content inline size) then half the min-content inline size (respectively max-content inline size) is used as a fallback value. If it is requested during layout then half the inline size of the box is used as a fallback value.

Given a MathML box, the following offsets are defined:

The inline offset of a child box is the offset between the inline-start edge of the parent box and the inline-start edge of the child box.
The block offset of a child box is the offset between the block-start edge of the parent box and the block-start edge of the child box.
The line-left offset of a child box is the offset between the line-left edge of the parent box and the line-left edge of the child box.

Box model for writing mode `horizontal-tb` and `rtl` that may be used in e.g. Arabic math.

Box model for writing mode `vertical-lr` and `ltr` that may be used in e.g. Mongolian math.

Box model for writing mode `vertical-rl` and `ltr` that may be used in e.g. Japanese math.

The position of child boxes and graphical items inside a MathML box are expressed using the inline offset and block offset. For convenience, the layout algorithms may describe offsets using flow-relative directions, line-relative directions or the alphabetic baseline. It is always possible to pass from one description to the other because position of child boxes are always performed after the metrics of the box and of its child boxes are calculated.

Here are examples of offsets obtained from line-relative metrics:

The inline offset of a child box is the line-left offset if the CSS property direction is ltr and is the inline size of the box − (line-left offset + inline size of the child box) otherwise.
The block offset of the alphabetic baseline of a box is the line-ascent if the CSS property writing-mode is horizontal-lr, vertical-rl or sideways-rl and is the line-descent otherwise.

Improve definition of ink ascent/descent?

Layout Algorithms

The layout algorithms described in this chapter for MathML boxes have the following structure:

Calculation of min-content inline size and max-content inline size of the content.
Box layout:
1. Layout of in-flow child boxes.
2. Calculation of inline size, ink line-ascent, ink line-descent, line-ascent and line-ascent of the content.
3. Calculation of offsets of child boxes within the content box as well as sizes and offsets of extra graphical items (bars, radical symbol, etc).
4. Layout and positioning of out-of-flow child boxes.

During box layout, the following extra steps must be performed:

After calculating the line-ascent and line-descent the block size is set to their sum.
The box metrics, offsets, baselines, italic correction and top accent attachment of the content box are set to the one calculated for the content.
The box metrics and offsets of the padding box are obtained from the content box by taking into account the corresponding padding properties as described in CSS.

The baselines of the padding box are the same as the one of the content box.

If the content box has a top accent attachment then the padding box has the same property, increased by the inline-start padding. If the content box has an italic correction then the padding box has the same property, increased by the inline-end padding.
The box metrics and offsets of the border box are obtained from the padding box by taking into account the corresponding border-width property as described in CSS.

In general, the baselines of the border box are the same as the one of the padding box. However, if the line-over border is positive then the ink-over baseline is set to the line-over edge of the border box and if the line-under border is positive then the ink-under baseline is set to the line-under edge of the border box.

If the padding box has a top accent attachment then the border box has the same property, increased by the border-width of its inline-start egde. If the padding box has an italic correction then the border box has the same property, increased by the border-width of its inline-end egde.
The box metrics and offsets of the margin box are obtained from the border box by taking into account the corresponding margin properties as described in CSS.

The baselines of the margin box are the same as the one of the border box.

If the padding box has a top accent attachment then the margin box has the same property, increased by the inline-start margin. If the padding box has an italic correction then the margin box has the same property, increased by the inline-end margin.

Per the description above, margin-collapsing does not apply to MathML elements.

During box layout, optional inline stretch size constraint and block stretch size constraint parameters may be used on embellished operators. The former indicates a target size that a core operator stretched along the inline axis should cover. The latter indicates an ink line-ascent and ink line-descent that a core operator stretched along the block axis should cover. Unless specified otherwise, these parameters are ignored during box layout and child boxes are laid out without any stretch size constraint.

Explain how out-of-flow elements are positioned.

Interpret width/height/inline-size/block-size?

Define what inline percentages resolve against

Define what block percentages resolve against

Stacking contexts

MathML elements can overlap due to various spacing rules. They can as well contain extra graphical items (bars, radical symbol, etc). A MathML element with computed style display: block math or display: inline math generates a new stacking context. The painting order of in-flow children of such a MathML element is exactly the same as block elements. The extra graphical items are painted after text and background (right after step 7.2.4 for display: inline math and right after step 7.2 for display: block math).

Token Elements

Token elements in presentation markup are broadly intended to represent the smallest units of mathematical notation which carry meaning. Tokens are roughly analogous to words in text. However, because of the precise, symbolic nature of mathematical notation, the various categories and properties of token elements figure prominently in MathML markup. By contrast, in textual data, individual words rarely need to be marked up or styled specially.

In practice, most MathML token elements just contain simple text for variables, numbers, operators etc and don't need sophisticated layout. However, it can contain contain text with line breaks or arbitrary HTML5 phrasing elements.

Text `<mtext>`

The <mtext> element is used to represent arbitrary text that should be rendered as itself. In general, the <mtext> element is intended to denote commentary text.

The <mtext> element accepts the attributes described in .

In the following example, <mtext> is used to put conditional words in a definition:

Layout of `<mtext>`

The mtext element is laid out as a block box and the min-content inline size, max-content inline size, inline size, block size, first baseline set and last baseline set are determined accordingly.

If the <mtext> element contains only text content without forced line break or soft wrap opportunity then in addition:

The ink-over baseline (respectively and ink-under baseline) is set to align with the line-over edge (respectively and ink-under baseline) of the ink bounding box of the text.
If the text content is made of a single glyph and this glyph has an entry an entry in the MathItalicsCorrectionInfo table then the specified value is used as the italic correction.
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.

Identifier `<mi>`

The <mi> element represents a symbolic name or arbitrary text that should be rendered as an identifier. Identifiers can include variables, function names, and symbolic constants.

The <mi> element accepts the attributes described in . Its layout algorithm is the same as the <mtext> element. The user agent stylesheet must contain the following property in order to implement automatic italic:

In the following example, <mi> is used to render variables and function names. Note that identifiers containing a single letter are italic by default.

Number `<mn>`

The <mn> element represents a "numeric literal" or other data that should be rendered as a numeric literal. Generally speaking, a numeric literal is a sequence of digits, perhaps including a decimal point, representing an unsigned integer or real number.

The <mn> element accepts the attributes described in . Its layout algorithm is the same as the <mtext> element.

In the following example, <mn> is used to write a decimal number.

Operator, Fence, Separator or Accent `<mo>`

The <mo> element represents an operator or anything that should be rendered as an operator. In general, the notational conventions for mathematical operators are quite complicated, and therefore MathML provides a relatively sophisticated mechanism for specifying the rendering behavior of an <mo> element.

As a consequence, in MathML the list of things that should "render as an operator" includes a number of notations that are not mathematical operators in the ordinary sense. Besides ordinary operators with infix, prefix, or postfix forms, these include fence characters such as braces, parentheses, and "absolute value" bars; separators such as comma and semicolon; and mathematical accents such as a bar or tilde over a symbol. This chapter uses the term "operator" to refer to operators in this broad sense.

The <mo> element accepts the attributes described in as well as the following attributes:

form
fence
separator
lspace
rspace
stretchy
symmetric
maxsize
minsize
largeop
movablelimits

This specification does not define any observable behavior that is specific to the fence and separator attributes.

Authors may use the fence and separator to describe specific semantics of operators. The default values may be determined from the Operators_fence and Operators_separator tables, or equivalently the human-readable version of the operator dictionary.

In the following example, the <mo> element is used for the binary operator +. Default spacing is symmetric around that operator. A tigher spacing is used if you rely on the form attribute to force it to be treated as a prefix operator. Spacing can also be specified explicitly using the lspace and rspace attributes.

Another use case is for big operator such as summation. When displaystyle is true, such an operator are drawn larger but one can change that with the largeop attribute. When displaystyle is false, underscript are actually rendered as subscript but one can change that with the movablelimits attribute.

Operators are also used for stretchy symbols such as fences, accents, arrows etc. In the following example, the vertical arrow stretches to the height of the <mspace> element. One can override default stretch behavior with the stretchy attribute e.g. to force an unstretched arrow. The symmetric attribute allows to indicate whether the operator should stretchy symmetrically above and below the baseline. Finally the minsize and maxsize attributes add additional constraints over the stretch size.

Note that the default properties of operators are dictionary-based, as explained in . For example a binary operator typically has default symmetric spacing around it while a fence is generally stretchy by default.

Embellished operators

A MathML Core element is an embellished operator if it is:

An <mo> element;
A scripted element or an <mfrac>, whose first in-flow child exists and is an embellished operator;
A grouping element or <mpadded>, whose in-flow children consist (in any order) of one embellished operator and zero or more space-like elements.

The core operator of an embellished operator is the <mo> element defined recursively as follows:

The core operator of an <mo> element; is the element itself.
The core operator of an embellished scripted element or <mfrac> element is the core operator of its first in-flow child.
The core operator of an embellished grouping element or <mpadded> is the core operator of its unique embellished operator in-flow child.

The stretch axis of an embellished operator is inline if its core operator contains only text content made of a unique character c, and that character has inline intrinsic stretch axis. Otherwise, the stretch axis of the embellished operator is block.

Dictionary-based attributes

The form property of an embellished operator is either infix, prefix or postfix. The corresponding form attribute on the <mo> element, if present, must be an ASCII case-insensitive match to one of these values.

The algorithm for determining the form of an embellished operator is as follows:

If the form attribute is present and valid on the core operator, then its ASCII lowercased value is used;
If the embellished operator is the first in-flow child of a grouping element, <mpadded> or <msqrt> with more than one in-flow child (ignoring all space-like children) then it has form prefix;
Or, if the embellished operator is the last in-flow child of a grouping element, <mpadded> or <msqrt> with more than one in-flow child (ignoring all space-like children) then it has form postfix;
Or, if the embellished operator is an in-flow child of a scripted element, other than the first in-flow child, then it has form postfix;
Otherwise, the embellished operator has form infix.

The stretchy, symmetric, largeop, movablelimits, properties of an embellished operator are either false or true. In the latter case, it is said that the embellished operator has the property. The corresponding attributes on the <mo> element, if present, must be a boolean.

The lspace, rspace, minsize properties of an embellished operator are length-percentage. The maxsize property of an embellished operator is either a length-percentage or ∞. The lspace, rspace, minsize and maxsize attributes on the <mo> element, if present, must be a length-percentage.

The algorithm for determining the properties of an embellished operator is as follows:

If the corresponding stretchy, symmetric, largeop, movablelimits, lspace, rspace, maxsize or minsize attribute is present and valid on the core operator, then the ASCII lowercased value of this property is used;
Otherwise, run the algorithm for determining the form of an embellished operator;
If the core operator contains only text content Content, then set Category to the result of the algorithm to determine the category of an operator (Content, Form) where Form is the form calculated at the previous step.
If Category is Default and the form of embellished operator was not explicitly specified as an attribute on its core operator, then
1. Set Category to the result of the algorithm to determine the category of an operator (Content, Form) where Form is infix.
2. If Category is Default, then run the algorithm again with Form set to prefix.
3. If Category is Default, then run the algorithm again with Form set to postfix.
Run the algorithm to set the properties of an operator from its category Category.

When used during layout, the values of stretchy, symmetric, largeop, movablelimits, lspace, rspace, minsize are obtained by the algorithm for determining the properties of an embellished operator with the following extra resolutions:

Percentage values for lspace, rspace are interpreted relative to the value read from the dictionary or to the fallback value above.
Interpretation of percentage values for minsize and maxsize are described in .
Font-relative lengths for lspace, rspace, minsize and maxsize rely on the font style of the core operator, not the one of the embellished operator.

Layout of operators

If the <mo> element does not have its computed display property equal to block math or inline math then it is laid out according to the CSS specification where the corresponding value is described. Otherwise, the layout below is performed.

The text of the operator must only be painted if the visibility of the <mo> element is visible. In that case, it must be painted with the color of the <mo> element.

Operators are laid out as follows:

If the content of the <mo> element is not made of a single character c then fallback to the layout algorithm of .
If the operator has the stretchy property:
- If the stretch axis of the operator is inline then
  1. If it is not possible to shape a stretchy glyph corresponding to c in the inline direction with the first available font then fallback to the layout algorithm of .
  2. The min-content inline size and max-content inline size of the content are set to the one obtained by the layout algorithm of .
  3. If there is not any inline stretch size constraint T_inline then fallback to the layout algorithm of .
  4. The inline size and (ink) block metrics of the content are given by algorithm to shape a stretchy glyph to inline dimension T_inline.
  5. The painting of the operator is performed by the algorithm to shape a stretchy glyph stretched to inline dimension T_inline and at position determined by the previous box metrics.
- Otherwise, the stretch axis of the operator is block. The following steps are performed:
  1. If it is not possible to shape a stretchy glyph corresponding to c in the block direction with the first available font then fallback to the layout algorithm of .
  2. The min-content inline size and max-content inline size of the content are set to the preferred inline size of a glyph stretched along the block axis.
  3. If there is not any block stretch size constraint (U_ascent, U_descent) then fallback to the layout algorithm of .
  4. If the operator has the symmetric property then set the target sizes T_ascent and T_descent to S_ascent and S_descent respectively:
    - S_ascent = max( U_ascent − AxisHeight, U_descent + AxisHeight ) + AxisHeight
    - S_descent = max( U_ascent − AxisHeight, U_descent + AxisHeight ) − AxisHeight
    Otherwise set them to U_ascent and U_descent respectively.
  5. Let minsize and maxsize be the minsize and maxsize properties on the operator. Percentage values are intepreted relative to T = T_ascent + T_descent. If minsize < 0 then set minsize to 0. If maxsize < minsize then set maxsize to minsize. Then 0 ≤ minsize ≤ maxsize:
    - If T ≤ 0 then set T_ascent to minsize / 2 and then set T_descent to minsize − T_ascent
    - Otherwise, if 0 < T < minsize then first multiply T_ascent by minsize / T and then set T_descent to minsize - T_ascent.
    - Otherwise, if maxsize < T then first multiply T_ascent by maxsize / T and then set T_descent to maxsize − T_ascent.
  6. The inline size, ink line-ascent, ink line-descent, line-ascent and line-descent of the content are obtained by the algorithm to shape a stretchy glyph to block dimension T_ascent + T_descent. The inline size of the content is the width of the stretchy glyph. The stretchy glyph is shifted towards the line-under by a value Δ so that its center aligns with the center of the target: the ink ascent of the content is the ascent of the stretchy glyph − Δ and the ink descent of the content is the descent of the stretchy glyph + Δ. These centers have coordinates "½(ascent − descent)" so Δ = [(ascent of stretchy glyph − descent of stretchy glyph) − (T_ascent − T_descent)] / 2.
  7. The painting of the operator is performed by the algorithm to shape a stretchy glyph stretched to block dimension T_ascent + T_descent and at position determined by the previous box metrics shifted by Δ towards the line-over.
  Base size, size variants and glyph assembly for the left brace
If the operator has the largeop property and if math-style on the <mo> element is normal, then:
1. Use the MathVariants table to try and find a glyph of height at least DisplayOperatorMinHeight If none is found, fallback to the largest non-base glyph. If none is found, fallback to the layout algorithm of .
2. The min-content inline size, max-content inline size, inline size and block metrics of the content are given by the glyph found.
3. Paint the glyph.
Base and displaystyle sizes of the summation symbol
Other fallback to the layout algorithm of .

If the algorithm to shape a stretchy glyph has been used for one of the step above, then the italic correction of the content is set to the value returned by that algorithm.

If maxsize is equal to its default value ∞ then minsize ≤ maxsize is satisfied but maxsize < T is not.

Space `<mspace>`

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

The <mspace> element accepts the attributes described in as well as the following attributes:

width
height
depth

The mspace@width, mspace@height, mspace@depth, if present, must have a value that is a valid length-percentage. An unspecified attribute, a percentage value, or an invalid value is interpreted as 0. If one of the requested values calculated is negative then it is treated as 0.

In the following example, <mspace> is used to force spacing within the formula (a 1px blue border is added to easily visualize the space):

If the <mspace> element does not have its computed display property equal to block math or inline math then it is laid out according to the CSS specification where the corresponding value is described. Otherwise, the <mspace> element is laid out as shown on . The min-content inline size and max-content inline size of the content are equal to the requested inline size. The inline size, line-ascent and line-descent of the content are respectively the requested inline size, line-ascent and line-descent.

The terminology height/depth comes from [[MATHML3]], itself inspired from [[TEXBOOK]].

Definition of space-like elements

A number of MathML presentation elements are "space-like" in the sense that they typically render as whitespace, and do not affect the mathematical meaning of the expressions in which they appear. As a consequence, these elements often function in somewhat exceptional ways in other MathML expressions.

A MathML Core element is a space-like element if it is:

An <mtext> or <mspace>;
Or a grouping element or <mpadded> all of whose in-flow children are space-like.

Note that an <mphantom> is not automatically defined to be space-like, unless its content is space-like. This is because operator spacing is affected by whether adjacent elements are space-like. Since the <mphantom> element is primarily intended as an aid in aligning expressions, operators adjacent to an <mphantom> should behave as if they were adjacent to the contents of the <mphantom>, rather than to an equivalently sized area of whitespace.

String Literal `<ms>`

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

The <ms> element accepts the attributes described in . Its layout algorithm is the same as the <mtext> element.

In the following example, <ms> is used to write a literal string of characters:

In MathML3, it was possible to use the lquote and rquote attributes to respectively specify the strings to use as opening and closing quotes. These are no longer supported and the quotes must instead be specified as part of the text of the <ms> element. One can add CSS rules to legacy documents in order to preserve visual rendering. For example, in left-to-right direction:

General Layout Schemata

Besides tokens there are several families of MathML presentation elements. One family of elements deals with various "scripting" notations, such as subscript and superscript. Another family is concerned with matrices and tables. The remainder of the elements, discussed in this section, describe other basic notations such as fractions and radicals, or deal with general functions such as setting style properties and error handling.

Group Sub-Expressions `<mrow>`

The <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".

In the following example, <mrow> is used to group a sum "1 + 2/3" as a fraction numerator (first child of <mfrac>) and to construct a fenced expression (first child of <msup>) that is raised to the power of 5. Note that <mrow> alone does not add visual fences around its grouped content, one has to explicitly specify them using the <mo> element.

Within the <mrow> elements, one can see that vertical alignment of children (according to the alphabetic baseline or the mathematical baseline) is properly performed, fences are vertically stretched and spacing around the binary + operator automatically calculated.

The <mrow> element accepts the attributes described in . An <mrow> element with in-flow children child₁, child₂, … child_N is laid out as show on . The child boxes are put in a row one after the other with all their alphabetic baselines aligned.

Because the box model ensure alignment of alphabetic baselines, fraction bars or symmetric stretchy operators will also be aligned along the math axis in the typical case when AxisHeight is the same for all in-flow children.

Algorithm for stretching operators along the block axis

Symmetric and non-symmetric stretching of operators along the block axis

The algorithm for stretching operators along the block axis consists in the following steps:

If there is a block stretch size constraint or an inline stretch size constraint then the element being laid out is an embellished operator. Layout the one in-flow child that is an embellished operator with the same stretch size constraint and all the other in-flow children without any stretch size constraint and stop.
Otherwise, split the list of in-flow children into a first list L_ToStretch containing embellished operators with a stretchy property and block stretch axis ; and a second list L_NotToStretch.
Perform layout without any stretch size constraint on all the items of L_NotToStretch. If L_ToStretch is empty then stop. If L_NotToStretch is empty, perform layout with stretch size constraint 0 on all the items of L_ToStretch.
Calculate the unconstrained target sizes U_ascent and U_descent as respectively the maximum ink ascent and maximum ink descent of the margin boxes of in-flow children that have been laid out in the previous step.
Layout or relayout all the elements of L_ToStretch with block stretch size constraint (U_ascent, U_descent).

Layout of `<mrow>`

A child box is slanted if it is not an embellished operator and has nonzero italic correction.

Large operators may have nonzero italic correction but that one is used when attaching scripts. More generally, all embellished operator are treated as non-slanted since the spacing around them is calculated as specified by lspace and rspace.

The min-content inline size (respectively max-content inline size) are calculated using the following algorithm:

Set add-space to true if the element is a <math> or is not an embellished operator; and to false otherwise.
Set inline-offset to 0.
Set previous-italic-correction to 0.
For each in-flow child:
1. If the child is not slanted, then increment inline-offset by previous-italic-correction.
2. If the child is an embellished operators and add-space is true then increment inline-offset by its lspace property.
3. Increment inline-offset by the min-content inline size (respectively max-content inline size) of the child's margin box.
4. If the child is slanted then set previous-italic-correction to its italic correction. Otherwise set it to 0.
5. If the child is an embellished operators and add-space is true then increment inline-offset by its rspace property.
Increment inline-offset by previous-italic-correction.
Return inline-offset.

The in-flow children are laid out using the algorithm for stretching operators along the block axis.

The inline size of the content is calculated like the min-content inline size and max-content inline size of the content, using the inline size of the in-flow children's margin boxes instead.

The ink line-ascent (respectively line-ascent) of the content is the maximum of the ink line-ascents (respectively line-ascents) of all the in-flow children's margin boxes. Similarly, the ink line-descent (respectively line-descent) of the content is the maximum of the ink line-descents (respectively ink line-ascents) of all the in-flow children's margin boxes.

The in-flow children are positioned using the following algorithm:

Set add-space to true if the element is a <math> or is not an embellished operator; and to false otherwise.
Set inline-offset to 0.
Set previous-italic-correction to 0.
For each in-flow child:
1. If the child is not slanted, then increment inline-offset by previous-italic-correction.
2. If the child is an embellished operators and add-space is true then increment inline-offset by its lspace property.
3. Set the inline offset of the child to inline-offset and its block offset such that the alphabetic baseline of the child is aligned with the alphabetic baseline.
4. Increment inline-offset by the inline size of the child's margin box.
5. If the child is slanted then set previous-italic-correction to its italic correction. Otherwise set it to 0.
6. If the child is an embellished operators and add-space is true then increment inline-offset by its rspace property.

The italic correction of the content is set to the italic correction of the last in-flow child, which is the final value of previous-italic-correction.

Fractions `<mfrac>`

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.

If the <mfrac> element does not have its computed display property equal to block math or inline math then it is laid out according to the CSS specification where the corresponding value is described. Otherwise, the layout below is performed.

The <mfrac> element accepts the attributes described in as well as the following attribute:

linethickness

The linethickness attribute indicates the fraction line thickness to use for the fraction bar. If present, it must have a value that is a valid length-percentage. If the attribute is absent or has an invalid value, FractionRuleThickness is used as the default value. A percentage is interpreted relative to that default value. A negative value is interpreted as 0.

The following example contains four fractions with different linethickness values. The bars are always aligned with the middle of plus and minus signs. The numerator and denominator are horizontally centered. The fractions that are not in displaystyle use smaller gaps and font-size.

$mfrac example$

The <mfrac> element sets displaystyle to false, or if it was already false increments scriptlevel by 1, within its children. It sets math-shift to compact within its second child. To avoid visual confusion between the fraction bar and another adjacent items (e.g. minus sign or another fraction's bar), a default 1-pixel space is added around the element. The user agent stylesheet must contain the following rules:

If the <mfrac> element has less or more than two in-flow children, its layout algorithm is the same as the <mrow> element. Otherwise, the first in-flow child is called numerator, the second in-flow child is called denominator and the layout algorithm is explained below.

In practice, an <mfrac> element has two children that are in-flow. Hence the CSS rules basically performs scriptlevel, displaystyle and math-shift changes for the numerator and denominator.

Fraction with nonzero line thickness

If the fraction line thickness is nonzero, the <mfrac> element is laid out as shown on . The fraction bar must only be painted if the visibility of the <mfrac> element is visible. In that case, the fraction bar must be painted with the color of the <mfrac> element.

The min-content inline size (respectively max-content inline size) of content is the maximum between the min-content inline size (respectively max-content inline size) of the numerator's margin box and the min-content inline size (respectively max-content inline size) of the denominator's margin box.

If there is an inline stretch size constraint or a block stretch size constraint then the numerator is also laid out with the same stretch size constraint otherwise it is laid out without any stretch size constraint. The denominator is always laid out without any stretch size constraint.

The inline size of the content is the maximum between the inline size of the numerator's margin box and the inline size of the denominator's margin box.

NumeratorShift is the maximum between:

FractionNumeratorShiftUp (respectively FractionNumeratorDisplayStyleShiftUp) if the math-style is compact (respectively normal).
The AxisHeight + half the fraction line thickness + FractionNumeratorGapMin (respectively FractionNumDisplayStyleGapMin) if the math-style is compact (respectively normal) + the ink line-descent of the numerator's margin box.

DenominatorShift is the maximum between:

FractionDenominatorShiftDown (respectively FractionDenominatorDisplayStyleShiftDown) if the math-style is compact (respectively normal).
Half the fraction line thickness + FractionDenominatorGapMin (respectively FractionDenomDisplayStyleGapMin) if the math-style is compact (respectively normal) + the ink line-ascent of the denominator's margin box − the AxisHeight.

The line-ascent of the content is the maximum between:

Numerator Shift + the line-ascent of the numerator's margin box.
−Denominator Shift + the line-ascent of the denominator's margin box
AxisHeight plus half the fraction line thickness.

The line-descent of the content is the maximum between:

−Numerator Shift + the line-descent of the numerator's margin box.
Denominator Shift + the line-descent of the denominator's margin box.
−AxisHeight plus half the fraction line thickness.
0

The inline offset of the numerator (respectively denominator) is the half the inline size of the content − half the inline size of the numerator's margin box (respectively denominator's margin box).

The alphabetic baseline of the numerator (respectively denominator) is shifted away from the alphabetic baseline by a distance of NumeratorShift (respectively DenominatorShift ) towards the line-over (respectively line-under).

The inline size of the fraction bar is the inline size of the content and its inline offset is 0. The center of the fraction bar is shifted away from the alphabetic baseline by a distance of AxisHeight towards the line-over. Its block size is the fraction line thickness.

Fraction with zero line thickness

If the fraction line thickness is zero, the <mfrac> element is instead laid out as shown on .

Box model for the `<mfrac>` element without bar

The min-content inline size, max-content inline size and inline size of the content are calculated the same as in .

If there is an inline stretch size constraint or a block stretch size constraint then the numerator is also laid out with the same stretch size constraint and otherwise it is laid out without any stretch size constraint. The denominator is always laid out without any stretch size constraint.

If the math-style is compact then TopShift and BottomShift are respectively set to StackTopShiftUp and StackBottomShiftDown. Otherwise math-style is normal and they are respectively set to StackTopDisplayStyleShiftUp and StackBottomDisplayStyleShiftDown.

The Gap is defined to be (BottomShift − the ink line-ascent of the denominator's margin box) + (TopShift − the ink line-descent of the numerator's margin box). If math-style is compact then GapMin is StackGapMin otherwise math-style is normal and it is StackDisplayStyleGapMin. If Δ = GapMin − Gap is positive then TopShift and BottomShift are respectively increased by Δ/2 and Δ − Δ/2.

The line-ascent of the content is the maximum between:

TopShift + the line-ascent of the numerator's margin box.
−BottomShift + the line-ascent of the denominator's margin box.

The line-descent of the content is the maximum between:

−TopShift + the line-descent of the numerator's margin box.
BottomShift + the line-descent of the denominator's margin box.
0

The inline offsets of the numerator and denominator are calculated the same as in .

The alphabetic baseline of the numerator (respectively denominator) is shifted away from the alphabetic baseline by a distance of TopShift (respectively − BottomShift) towards the line-over (respectively line-under).

Radicals `<msqrt>`, `<mroot>`

The radical elements construct an expression with a root symbol √ with a line over the content. 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 <msqrt> and <mroot> elements accept the attributes described in .

The following example contains a square root written with <msqrt> and a cube root written with <mroot>. Note that <msqrt> has several children and the square root applies to all of them. <mroot> has exactly two children: it is a root of index the second child (the number 3), applied to the first child (the square root). Also note these elements only change the font-size within the <mroot> index, but it is scaled down more than within the numerator and denumerator of the fraction.

The <msqrt> and <mroot> elements sets math-shift to compact. The <mroot> element sets increments scriptlevel by 2, and sets displaystyle to "false" in all but its first child. The user agent stylesheet must contain the following rule in order to implement that behavior:

If the <msqrt> or <mroot> element do not have their computed display property equal to block math or inline math then they are laid out according to the CSS specification where the corresponding value is described. Otherwise, the layout below is performed.

If the <mroot> has less or more than two in-flow children, its layout algorithm is the same as the <mrow> element. Otherwise, the first in-flow child is called mroot base and the second in-flow child is called mroot index and its layout algorithm is explained below.

In practice, an <mroot> element has two children that are in-flow. Hence the CSS rules basically performs scriptlevel and displaystyle changes for the index.

The children of the <msqrt> element are laid out using the algorithm of the <mrow> element to produce a box that is also called the msqrt base. In particular, the algorithm for stretching operators along the block axis is used.

Radical symbol

The radical symbol must only be painted if the visibility of the <msqrt> or <mroot> element is visible. In that case, the radical symbol must be painted with the color of that element.

The radical glyph is the glyph obtained for the character U+221A SQUARE ROOT.

The radical gap is given by RadicalVerticalGap if the math-style is compact and RadicalDisplayStyleVerticalGap if the math-style is normal.

The radical target size for the stretchy radical glyph is the sum of RadicalRuleThickness, radical gap and the ink height of the base.

The box metrics of the radical glyph and painting of the surd are given by the algorithm to shape a stretchy glyph to block dimension the target size for the radical glyph.

Square root

The <msqrt> element is laid out as shown on .

The min-content inline size (respectively max-content inline size) of the content is the sum of the preferred inline size of a glyph stretched along the block axis for the radical glyph and of the min-content inline size (respectively max-content inline size) of the msqrt base's margin box.

The inline size of the content is the sum of the advance width of the box metrics of the radical glyph and of the inline size of the msqrt base's margin's box.

The line-ascent of the content is the maximum between:

The line-ascent of the msqrt base's margin box.
The sum of the ink line-ascent of the msqrt base, the radical gap, the RadicalRuleThickness and RadicalExtraAscender.

The line-descent of the content is the maximum between:

The line-descent of the msqrt base's margin box.
The sum of the line-ascent and line-descent for the box metrics of the radical glyph and of the RadicalExtraAscender, minus the line-ascent of the content.

The inline size of the overbar is the inline size of the msqrt base's margin's box. The inline offsets of the msqrt base and overbar are also the same and equal to the width of the box metrics of the radical glyph.

The alphabetic baseline of the msqrt base is aligned with the alphabetic baseline. The block size of the overbar is RadicalRuleThickness. Its vertical center is shifted away from the alphabetic baseline by a distance towards the line-over equal to the line-ascent of the content, minus the RadicalExtraAscender, minus half the RadicalRuleThickness.

Finally, the painting of the surd is performed:

At inline offset 0.
At block offset shifted away from the line-over edge of the overbar towards the line-under by a distance given by the ascent of the box metrics of the radical glyph.

Root with index

The <mroot> element is laid out as shown on . The mroot index is first ignored and the mroot base and radical glyph are laid out as shown on figure using the same algorithm as in in order to produce a margin box B (represented in green).

The min-content inline size (respectively max-content inline size) of the content is the sum of max(0, RadicalKernBeforeDegree), the mroot index's min-content inline size (respectively max-content inline size) of the mroot index's margin box, max(−min-content inline size, RadicalKernAfterDegree) (respectively max(−max-content inline size, RadicalKernAfterDegree)) and of the min-content inline size (respectively max-content inline size) of B.

Using the same clamping, AdjustedRadicalKernBeforeDegree and AdjustedRadicalKernAfterDegree are respectively defined as max(0, RadicalKernBeforeDegree) and is max(−inline size of the index's margin box, RadicalKernAfterDegree).

The inline size of the content is the sum of AdjustedRadicalKernBeforeDegree, the inline size of the index's margin box, AdjustedRadicalKernAfterDegree and of the inline size of B.

The line-ascent of the content is the maximum between:

−the line-descent of B + RadicalDegreeBottomRaisePercent × the block size of B + the line-ascent of the index's margin box
The line-ascent of B

The line-descent of the content is the maximum between:

the line-descent of B − RadicalDegreeBottomRaisePercent × the block size of B + the line-ascent of the index's margin box
The line-descent of B

The inline offset of the index is AdjustedRadicalKernBeforeDegree. The inline-offset of the mroot base is the same + the inline size of the index's margin box.

The alphabetic baseline of B is aligned with the alphabetic baseline. The alphabetic baseline of the index is shifted away from the line-under edge by a distance of RadicalDegreeBottomRaisePercent × the block size of B + the line-descent of the index's margin box.

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 inline-start space and that the root index will overlap the surd.

Style Change `<mstyle>`

Historically, the <mstyle> element was introduced to make style changes that affect the rendering of its contents.

The <mstyle> element accepts the attributes described in . Its layout algorithm is the same as the <mrow> element.

<mstyle> is implemented for compatibility with full MathML. Authors whose only target is MathML Core are encouraged to use CSS for styling.

In the following example, <mstyle> is used to set the scriptlevel and displaystyle. Observe this is respectively affecting the font-size and placement of subscripts of their descendants. In MathML Core, one could just have used <mrow> elements instead.

Error Message `<merror>`

The <merror> element displays its contents as an ”error message”. The intent of this element is to provide a standard way for programs that generate MathML from other input to report syntax errors in their input.

In the following example, <merror> is used to indicate a parsing error for some LaTeX-like input:

The <merror> element accepts the attributes described in . Its layout algorithm is the same as the <mrow> element. The user agent stylesheet must contain the following rule in order to visually highlight the error message:

Adjust Space Around Content `<mpadded>`

The <mpadded> element renders the same as its in-flow child content, but with the size and relative positioning point of its content modified according to <mpadded>’s attributes.

The <mpadded> element accepts the attributes described in as well as the following attributes:

width
height
depth
lspace
voffset

The mpadded@width, mpadded@height, mpadded@depth, mpadded@lspace and mpadded@voffset if present, must have a value that is a valid length-percentage.

In the following example, <mpadded> is used to tweak spacing around a fraction (a blue background is used to visualize it). Without attributes, it behaves like an <mrow> but the attributes allow to specify the size of the box (width, height, depth) and position of the fraction within that box (lspace and voffset).

Inner box and requested parameters

In-flow children of the <mpadded> element are laid out using the algorithm of the <mrow> element to produce the mpadded inner box for the content with parameters called inner inline size, inner line-ascent and inner line-descent. The requested <mpadded> parameters are determined as follows:

If the width (respectively height, depth, lspace, voffset) attribute is absent, invalid or a length-percentage then the requested width (respectively height, depth, lspace, voffset) is the inner inline size (respectively inner line-ascent, inner line-descent, 0, 0).
Otherwise the requested width (respectively height, depth, lspace, voffset) is the resolved value of the width attribute (respectively height, depth, lspace, voffset attributes). If one of the requested width, depth, height or lspace values is negative then it is treated as 0.

Negative voffset values are not clamped to 0.

Layout of `<mpadded>`

If the <mpadded> element does not have its computed display property equal to block math or inline math then it is laid out according to the CSS specification where the corresponding value is described. Otherwise, it is laid out as shown on .

The min-content inline size (respectively max-content inline size) of the content is the requested width calculated in but using the min-content inline size (respectively max-content inline size) of the mpadded inner box instead of the "inner inline size".

The inline size of the content is the requested width calculated in .

The line-ascent of the content is the requested height. The line-descent of the content is the requested depth.

The mpadded inner box is placed so that its alphabetic baseline is shifted away from the alphabetic baseline by the requested voffset towards the line-over.

Making Sub-Expressions Invisible `<mphantom>`

Historically, the <mphantom> element was introduced to render its content invisibly, but with the same metrics size and other dimensions, including alphabetic baseline position that its contents would have if they were rendered normally.

In the following example, <mphantom> is used to ensure alignment of corresponding parts of the numerator and denominator of a fraction:

The <mphantom> element accepts the attributes described in . Its layout algorithm is the same as the <mrow> element. The user agent stylesheet must contain the following rule in order to hide the content:

<mphantom> is implemented for compatibility with full MathML. Authors whose only target is MathML Core are encouraged to use CSS for styling.

Script and Limit Schemata

The elements described in this section position one or more scripts around a base. Attaching various kinds of scripts and embellishments to symbols is a very common notational device in mathematics. For purely visual layout, a single general-purpose element could suffice for positioning scripts and embellishments in any of the traditional script locations around a given base. However, in order to capture the abstract structure of common notation better, MathML provides several more specialized scripting elements.

In addition to sub/superscript elements, MathML has overscript and underscript elements that place scripts above and below the base. These elements can be used to place limits on large operators, or for placing accents and lines above or below the base.

Subscripts and Superscripts `<msub>`, `<msup>`, `<msubsup>`

The <msub>, <msup> and <msubsup> elements are used to attach subscript and superscript to a MathML expression. They accept the attributes described in .

The following example, shows basic use of subscripts and superscripts. The font-size is automatically scaled down within the scripts.

If the <msub>, <msup> or <msubsup> elements do not have their computed display property equal to block math or inline math then they are laid out according to the CSS specification where the corresponding value is described. Otherwise, the layout below is performed.

Children of `<msub>`, `<msup>`, `<msubsup>`

If the <msub> element has less or more than two in-flow children, its layout algorithm is the same as the <mrow> element. Otherwise, the first in-flow child is called the msub base, the second in-flow child is called the msub subscript and the layout algorithm is explained in .

If the <msup> element has less or more than two in-flow children, its layout algorithm is the same as the <mrow> element. Otherwise, the first in-flow child is called the msup base, the second in-flow child is called the msup superscript and the layout algorithm is explained in .

If the <msubsup> element has less or more than three in-flow children, its layout algorithm is the same as the <mrow> element. Otherwise, the first in-flow child is called the msubsup base, the second in-flow child is called the msubsup subscript, its third in-flow child is called the msubsup superscript and the layout algorithm is explained in .

Base with subscript

The <msub> element is laid out as shown on . LargeOpItalicCorrection is the italic correction of the msub base if it is an embellished operator with the largeop property and 0 otherwise.

The min-content inline size (respectively max-content inline size) of the content is the min-content inline size (respectively max-content inline size) inline size of the msub base's margin box − LargeOpItalicCorrection + min-content inline size (respectively max-content inline size) of the msub subscript's margin box + SpaceAfterScript.

If there is an inline stretch size constraint or a block stretch size constraint then the msub base is also laid out with the same stretch size contraint and otherwise it is laid out without any stretch size constraint. The scripts are always laid out without any stretch size constraint.

The inline size of the content is the inline size of the msub base's margin box − LargeOpItalicCorrection + the inline size of the msub subscript's margin box + SpaceAfterScript.

SubShift is the maximum between:

SubscriptShiftDown
the ink line-ascent of the subscript's margin box − SubscriptTopMax
SubscriptBaselineDropMin + the ink line-descent of the msub base's margin box

The line-ascent of the content is the maximum between:

The line-ascent of the msub base's margin box.
The line-ascent of the subcript's margin box − SubShift.

The line-descent of the content is the maximum between:

The line-descent of the msub base's margin box.
The line-descent of the subcript's margin box + SubShift.

The inline offset of the msub base is 0 and the inline offset of the msub subscript is the inline size of the msub base's margin box − LargeOpItalicCorrection.

The msub base is placed so that its alphabetic baseline matches the alphabetic baseline. The msub subscript is placed so that its alphabetic baseline is shifted away from the alphabetic baseline by SubShift towards the line-under.

Base with superscript

The <msup> element is laid out as shown on . ItalicCorrection is the italic correction of the msup base if it is not an embellished operator with the largeop property and 0 otherwise.

The min-content inline size (respectively max-content inline size) of the content is the min-content inline size (respectively max-content inline size) of the msup base's margin box + ItalicCorrection + the min-content inline size (respectively max-content inline size) of the msup superscript's margin box + SpaceAfterScript.

If there is an inline stretch size constraint or a block stretch size constraint then the msup base is also laid out with the same stretch size contraint and otherwise it is laid out without any stretch size constraint. The scripts are always laid out without any stretch size constraint.

The inline size of the content is the inline size of the msup base's margin box + ItalicCorrection + the inline size of the msup superscript's margin box + SpaceAfterScript.

SuperShift is the maximum between:

The value SuperscriptShiftUpCramped if the element has a computed math-shift property equal to compact, or SuperscriptShiftUp otherwise.
SuperscriptBottomMin + the ink line-descent of the superscript's margin box
The ink line-ascent of the msup base's margin box − SuperscriptBaselineDropMax

The line-ascent of the content is the maximum between:

The line-ascent of the msup base's margin box.
The line-ascent of the supercript's margin box + SuperShift.

The line-descent of the content is the maximum between:

The line-descent of the msup base's margin box.
The line-descent of the supercript's margin box − SuperShift.

The inline offset of the msup base is 0 and the inline offset of msup superscript is the inline size of the msup base's margin box + ItalicCorrection.

The msup base is placed so that its alphabetic baseline matches the alphabetic baseline. The msup superscript is placed so that its alphabetic baseline is shifted away from the alphabetic baseline by SuperShift towards the line-over.

Base with subscript and superscript

The <msubsup> element is laid out as shown on . LargeOpItalicCorrection and SubShift are set as in . ItalicCorrection and SuperShift are set as in .

The min-content inline size (respectively max-content inline size and inline size) of the content is the maximum between the min-content inline size (respectively max-content inline size and inline size) of the content calculated in and .

If there is an inline stretch size constraint or a block stretch size constraint then the msubsup base is also laid out with the same stretch size contraint and otherwise it is laid out without any stretch size constraint. The scripts are always laid out without any stretch size constraint.

SubSuperGap is the gap between the two scripts along the block axis and is defined by (SubShift − the ink line-ascent of the msubsup subscript's margin box) + (SuperShift − the ink line-descent of the msubsup superscript's margin box). If SubSuperGap is not at least SubSuperscriptGapMin then the following steps are performed to ensure that the condition holds:

Let Δ be SuperscriptBottomMaxWithSubscript − (SuperShift − the ink line-descent of the msubsup superscript's margin box). If Δ > 0 then set Δ to the minimum between Δ set SubSuperscriptGapMin − SubSuperGap and increase SuperShift (and so SubSuperGap too) by Δ.
Let Δ be SubSuperscriptGapMin − SubSuperGap. If Δ > 0 then increase SubscriptShift (and so SubSuperGap too) by Δ.

The ink line-ascent (respectively line-ascent, ink line-descent, line-descent) of the content is set to the maximum of the ink line-ascent (respectively line-ascent, ink line-descent, line-descent) of the content calculated in in and but using the adjusted values SubShift and SuperShift above.

The inline offset and block offset of the msubsup base and scripts are performed the same as described in and .

Even when the msubsup subscript (respectively msubsup superscript) is an empty box, <msubsup> does not generally render the same as (respectively ) because of the additional constraint on SubSuperGap. Moreover, positioning the empty msubsup subscript (respectively msubsup superscript) may also change the total size.

In order to keep the algorithm simple, no attempt is made to handle empty scripts in a special way.

Underscripts and Overscripts `<munder>`, `<mover>`, `<munderover>`

The <munder>, <mover> and <munderover> elements are used to attach accents or limits placed under or over a MathML expression.

The <munderover> element accepts the attribute described in as well as the following attributes:

accent
accentunder

Similarly, the <mover> element (respectively <munder> element) accepts the attribute described in as well as the accent attribute (respectively the accentunder attribute).

accent, accentunder, attributes, if present, must have values that are booleans. If these attributes are absent or invalid, they are treated as equal to false. User agents must implement them as described in .

The following example, shows basic use of under and over scripts. The font-size is automatically scaled down within the scripts, unless they are meant to be accents.

If the <munder>, <mover> or <munderover> elements do not have their computed display property equal to block math or inline math then they are laid out according to the CSS specification where the corresponding value is described. Otherwise, the layout below is performed.

Children of `<munder>`, `<mover>`, `<munderover>`

If the <munder> element has less or more than two in-flow children, its layout algorithm is the same as the <mrow> element. Otherwise, the first in-flow child is called the munder base and the second in-flow child is called the munder underscript.

If the <mover> element has less or more than two in-flow children, its layout algorithm is the same as the <mrow> element. Otherwise, the first in-flow child is called the mover base and the second in-flow child is called the mover overscript.

If the <munderover> element has less or more than three in-flow children, its layout algorithm is the same as the <mrow> element. Otherwise, the first in-flow child is called the munderover base, the second in-flow child is called the munderover underscript and its third in-flow child is called the munderover overscript.

If the <munder>, <mover> or <munderover> elements have a computed math-style property equal to compact and their base is an embellished operator with the movablelimits property, then their layout algorithms are respectively the same as the ones described for <msub>, <msup> and <msubsup> in , and .

Otherwise, the <mover>, <mover> and <munderover> layout algorithms are respectively described in , and

Algorithm for stretching operators along the inline axis

The algorithm for stretching operators along the inline axis is as follows.

If there is an inline stretch size constraint or block stretch size constraint then the element being laid out is an embellished operator. Layout the base with the same stretch size constraint.
Split the list of in-flow children that have not been laid out yet into a first list L_ToStretch containing embellished operators with a stretchy property and inline stretch axis ; and a second list L_NotToStretch.
Perform layout without any stretch size constraint on all the items of L_NotToStretch. If L_ToStretch is empty then stop. If L_NotToStretch is empty, perform layout with stretch size constraint 0 on all the items of L_ToStretch.
Calculate the target size T to the maximum inline size of the margin boxes of child boxes that have been laid out in the previous step.
Layout or relayout all the elements of L_ToStretch with inline stretch size constraint T.

Base with underscript

The <munder> element is laid out as shown on . LargeOpItalicCorrection is the italic correction of the munder base if it is an embellished operator with the largeop property and 0 otherwise.

The min-content inline size (respectively max-content inline size) of the content are calculated like the inline size of the content below but replacing the inline sizes of the munder base's margin box and munder underscript's margin box with the min-content inline size (respectively max-content inline size) of the munder base's margin box and munder underscript's margin box.

The in-flow children are laid out using the algorithm for stretching operators along the inline axis.

The inline size of the content is calculated by determining the absolute difference between:

The maximum of:
- Half the inline size of the munder base's margin box.
- Half the inline size of the munder underscript's margin box − half LargeOpItalicCorrection.
The minimum of:
- −Half the inline size of the munder base's margin box.
- −Half the inline size of the munder underscript's margin box − half LargeOpItalicCorrection.

If m is the minimum calculated in the second item above then the inline offset of the munder base is −m − half the inline size of the base's margin box. The inline offset of the munder underscript is −m − half the inline size of the munder underscript's margin box − half LargeOpItalicCorrection.

Parameters UnderShift and UnderExtraDescender are determined by considering three cases in the following order:

The munder base is an embellished operator with the largeop property. UnderShift is the maximum of
- LowerLimitBaselineDropMin
- LowerLimitGapMin + the ascent of the munder underscript.
UnderExtraDescender is 0.
The munder base is an embellished operator with the stretchy property and stretch axis inline. UnderShift is the maximum of:
- StretchStackBottomShiftDown
- StretchStackGapAboveMin + the ascent of the munder underscript.
UnderExtraDescender is 0.
Otherwise, UnderShift is equal to UnderbarVerticalGap if the accentunder attribute is not an ASCII case-insensitive match to true and to zero otherwise. UnderExtraAscender is UnderbarExtraDescender.

The line-ascent of the content is the maximum between:

The line-ascent of the munder base's margin box.
The line-ascent of the munder underscript's margin box − UnderShift.

The line-descent of the content is the maximum between:

The line-descent of the munder base's margin box.
The line-descent of the munder underscript's margin box + UnderShift + UnderExtraAscender.

The alphabetic baseline of the munder base is aligned with the alphabetic baseline. The alphabetic baseline of the munder underscript is shifted away from the alphabetic baseline and towards the line-under by a distance equal to the ink line-descent of the munder base's margin box + UnderShift.

Base with overscript

The <mover> element is laid out as shown on . LargeOpItalicCorrection is the italic correction of the mover base if it is an embellished operator with the largeop property and 0 otherwise.

The min-content inline size (respectively max-content inline size) of the content are calculated like the inline size of the content below but replacing the inline sizes of the mover base's margin box and mover overscript's margin box with the min-content inline size (respectively max-content inline size) of the mover base's margin box and mover overscript's margin box.

The in-flow children are laid out using the algorithm for stretching operators along the inline axis.

The TopAccentAttachment is the top accent attachment of the mover overscript or half the inline size of the mover overscript's margin box if it is undefined.

The inline size of the content is calculated by applying the algorithm for stretching operators along the inline axis for layout and determining the absolute difference between:

The maximum of:
- Half the inline size of the mover base's margin box.
- The inline size of the mover overscript's margin box − TopAccentAttachment + half LargeOpItalicCorrection.
The minimum of:
- −Half the inline size of the mover base's margin box.
- −TopAccentAttachment + half LargeOpItalicCorrection.

If m is the minimum calculated in the second item above then the inline offset of the mover base is −m − half the inline size of the base's margin. The inline offset of the mover overscript is −m − half the inline size of the mover overscript's margin box + half LargeOpItalicCorrection.

Parameters OverShift and OverExtraDescender are determined by considering three cases in the following order:

The mover base is an embellished operator with the largeop property. OverShift is the maximum of
- UpperLimitBaselineRiseMin
- UpperLimitGapMin + the descent of the mover overscript.
OverExtraAscender is 0.
The mover base is an embellished operator with the stretchy property and stretch axis inline. OverShift is the maximum of:
- StretchStackTopShiftUp
- StretchStackGapBelowMin + the descent of the mover overscript.
OverExtraDescender is 0.
Otherwise, OverShift is equal to
1. OverbarVerticalGap if the accent attribute is not an ASCII case-insensitive match to true.
2. Or AccentBaseHeight minus the line-ascent of the mover base's margin box if this difference is nonnegative.
3. Or 0 otherwise.
OverExtraAscender is OverbarExtraAscender.

For accent overscripts and bases with line-ascents that are at most AccentBaseHeight, the rule from [[OPEN-FONT-FORMAT]] [[?TEXBOOK]] is actually to align the alphabetic 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 alphabetic 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 a more general and simpler rule is provided above: Ensure that the bottom of overscript is at least AccentBaseHeight above the alphabetic baseline of the base.

The line-ascent of the content is the maximum between:

The line-ascent of the mover base's margin box.
The line-ascent of the mover overscript's margin box + OverShift + OverExtraAscender.

The line-descent of the content is the maximum between:

The line-descent of the mover base's margin box.
The line-descent of the mover overscript's margin box − OverShift.

The alphabetic baseline of the mover base is aligned with the alphabetic baseline. The alphabetic baseline of the mover overscript is shifted away from the alphabetic baseline and towards the line-over by a distance equal to the ink line-ascent of the base + OverShift.

Base with underscript and overscript

The general layout of <munderover> is shown on . The LargeOpItalicCorrection, UnderShift, UnderExtraDescender, OverShift, OverExtraDescender parameters are calculated the same as in and .

Box model for the `<munderover>` element

The min-content inline size, max-content inline size and inline size of the content are calculated as an absolute difference between a maximum inline offset and minimum inline offset. These extrema are calculated by taking the extremum value of the corresponding extrema calculated in and . The inline offsets of the munderover base, munderover underscript and munderover overscript are calculated as in these sections but using the new minimum m (minimum of the corresponding minima).

Like in these sections, the in-flow children are laid out using the algorithm for stretching operators along the inline axis.

The line-ascent and line-descent of the content are also calculated by taking the extremum value of the extrema calculated in and .

Finally, the alphabetic baselines of the munderover base, munderover underscript and munderover overscript are calculated as in sections and .

When the underscript (respectively overscript) is an empty box, the base and overscript (respectively underscript) are laid out similarly to (respectively ) but the position of the empty underscript (respectively overscript) may add extra space. In order to keep the algorithm simple, no attempt is made to handle empty scripts in a special way.

Prescripts and Tensor Indices `<mmultiscripts>`

Presubscripts and tensor notations are represented the <mmultiscripts> with hints given by the <mprescripts> (to distinguish postscripts and prescripts) and <none> elements (to indicate empty scripts). These element accept the attributes described in .

The following example, shows basic use of prescripts and postscripts, involving <none> and <mprescripts>. The font-size is automatically scaled down within the scripts.

If the <mmultiscripts>, <mprescripts> or <none> elements do not have their computed display property equal to block math or inline math then they are laid out according to the CSS specification where the corresponding value is described. Otherwise, the layout below is performed.

The empty <mprescripts> and <none> elements are laid out as an <mrow> element.

A valid <mmultiscripts> element contains the following in-flow children:

A first in-flow child, called the mmultiscripts base, that is not a an <mprescripts> element.
Followed by an even number of in-flow children called mmultiscripts postscripts, none of them being a <mprescripts> element. These scripts form a (possibly empty) list subscript, superscript, subscript, superscript, subscript, superscript, etc. Each consecutive couple of children subscript, superscript is called a subscript/superscript pair.
Optionally followed by an <mprescripts> element and an even number of in-flow children called mmultiscripts prescripts, none of them being a <mprescripts> element. These scripts form a (possibly empty) list of subscript/superscript pair.

If an <mmultiscripts> element is not valid then it is laid out the same as the <mrow> element. Otherwise the layout algorithm is explained below.

The <none> element is preserved for backward compatibility reasons but is actually not taken into account in the layout algorithm.

Base with prescripts and postscripts

The <mmultiscripts> element is laid out as shown on . For each subscript/superscript pair of mmultiscripts postscripts, the ItalicCorrection LargeOpItalicCorrection are defined as in and .

Box model for the `<mmultiscripts>` element

The min-content inline size (respectively max-content inline size) of the content is calculated the same as the inline size of the content below, but replacing "inline size" with "min-content inline size" (respectively "max-content inline size") for the mmultiscripts base's margin box and scripts's margin boxes.

If there is an inline stretch size constraint or a block stretch size constraint the mmultiscripts base is also laid out with the same stretch size constraint. Otherwise it is laid out without any stretch size constraint. The other elements are always laid out without any stretch size constraint.

The inline size of the content is calculated with the following algorithm:

Set inline-offset to 0.
For each subscript/superscript pair of mmultiscripts prescripts, increment inline-offset by SpaceAfterScript + the maximum of
- The inline size of the subscript's margin box.
- The inline size of the superscript's margin box.
Increment inline-offset by the inline size of the mmultiscripts base's margin box and set inline-size to inline-offset.
For each subscript/superscript pair of mmultiscripts postscripts, modify inline-size to be at least:
- x + the inline size of the subscript's margin box + LargeOpItalicCorrection.
- x + the inline size of the superscript's margin box − ItalicCorrection.
Increment inline-offset to the maximum of:
- the inline size of the subscript's margin box.
- the inline size of the superscript's margin box.
Increment inline-offset by SpaceAfterScript.
Return inline-size

SubShift (respectively SuperShift) is calculated by taking the maximum of all subshifts (respectively supershifts) of each subscript/superscript pair as described in .

The line-ascent of the content is calculated by taking the maximum of all the line-ascent of each subscript/superscript pair as described in but using the SubShift and SuperShift values calculated above.

The line-descent of the content is calculated by taking the maximum of all the line-descent of each subscript/superscript pair as described in but using the SubShift and SuperShift values calculated above.

Finally, the placement of the in-flow children is performed using the following algorithm:

Set inline-offset to 0.
For each subscript/superscript pair of mmultiscripts prescripts:
1. Increment inline-offset by SpaceAfterScript.
2. Set pair-inline-size to the maximum of
  - the inline size of the subscript's margin box.
  - the inline size of the superscript's margin box.
3. Place the subscript at inline-start position inline-offset + pair-inline-size − the inline size of the subscript's margin box.
4. Place the superscript at inline-start position inline-offset + pair-inline-size − the inline size of the superscript's margin box.
5. Place the subscript (respectively superscript) so its alphabetic baseline is shifted away from the alphabetic baseline by SubShift (respectively SuperShift) towards the line-under (respectively line-over).
6. Increment inline-offset by pair-inline-size.
Place the mmultiscripts base and <mprescripts> boxes at inline offsets inline-offset and with their alphabetic baselines aligned with the alphabetic baseline.
For each subscript/superscript pair of mmultiscripts postscripts:
1. Set pair-inline-size to the maximum of
  - the inline size of the subscript's margin box.
  - the inline size of the superscript's margin box.
2. Place the subscript at inline-start position inline-offset − LargeOpItalicCorrection.
3. Place the superscript at inline-start position inline-offset + ItalicCorrection.
4. Place the subscript (superscript) so its alphabetic baseline is shifted away from the alphabetic baseline by SubShift (respectively SuperShift) towards the line-under (respectively line-over).
5. Increment inline-offset by pair-inline-size
6. Increment inline-offset by SpaceAfterScript.

An <mmultiscripts> with only one subscript/superscript pair of mmultiscripts postscripts is laid out the same as a <msubsup> with the same in-flow children. However, as noticed for <msubsup>, if additionally the subscript (respectively superscript) is an empty box then it is not necessarily laid out the same as an <msub> (respectively <msup>) element. In order to keep the algorithm simple, no attempt is made to handle empty or <none> scripts in a special way.

Displaystyle, scriptlevel and math-shift in scripts

For all scripted elements, the rule of thumb is to set displaystyle to false and to increment scriptlevel in all child elements but the first one. However, an <mover> (respectively <munderover>) element with an accent attribute that is an ASCII case-insensitive match to true does not increment scriptlevel within its second child (respectively third child). Similarly, <mover> and <munderover> elements with an accentunder attribute that is an ASCII case-insensitive match to true do not increment scriptlevel within their second child.

<mmultiscripts> sets math-shift to compact on its children at even position if they are before an <mprescripts>, and on those at odd position if they are after an <mprescripts>. The <msub> and <msubsup> elements set math-shift to compact on their second child. An <mover> and <munderover> elements with an accent attribute that is an ASCII case-insensitive match to true also sets math-shift to compact within their first child.

The must contain the following style in order to implement this behavior:

In practice, all the children of the MathML elements described in this section are in-flow and the <mprescripts> is empty. Hence the CSS rules essentially performs automatic displaystyle and scriptlevel changes for the scripts ; and math-shift changes for subscripts and sometimes the base.

Tabular Math

Matrices, arrays and other table-like mathematical notation are marked up using <mtable> <mtr> <mtd> elements. These elements are similar to the <table>, <tr> and <td> elements of [[HTML]].

The following example, how tabular layout allows to write a matrix. Note that it is vertically centered with the fraction bar and the middle of the equal sign.

Table or Matrix `<mtable>`

The <mtable> is laid out as an inline-table and sets displaystyle to false. The user agent stylesheet must contain the following rules in order to implement these properties:

The mtable element is as a CSS table and the min-content inline size, max-content inline size, inline size, block size, first baseline set and last baseline set sets are determined accordingly. The center of the table is aligned with the math axis.

Row in Table or Matrix `<mtr>`

The <mtr> is laid out as table-row. The user agent stylesheet must contain the following rules in order to implement that behavior:

The <mtr> accepts the attributes described in .

Entry in Table or Matrix `<mtd>`

The <mtd> is laid out as a table-cell with content centered in the cell and a default padding. The user agent stylesheet must contain the following rules:

The <mtd> accepts the attributes described in as well as the following attributes:

columnspan
rowspan

The columnspan (respectively rowspan) attribute has the same syntax and semantic as the colspan (respectively rowspan) attribute on the <td> element from [[HTML]].

The name for the column spanning attribute is columnspan as in [[MathML3]] and not colspan as in [[HTML]].

Enlivening Expressions

Historically, the <maction> element provides a mechanism for binding actions to expressions.

The <maction> element accepts the attributes described in as well as the following attributes:

actiontype
selection

This specification does not define any observable behavior that is specific to the actiontype and selection attributes.

The following example, shows the "toggle" action type from [[MathML3]] where the renderer alternately displays the selected subexpression, starting from "one third" and cycling through them when there is a click on the selected subexpression ("one quarter", "one half", "one third", etc). This is not part of MathML Core but can be implemented using JavaScript and CSS polyfills. The default behavior is just to render the first child.

The layout algorithm of the <maction> element the same as the <mrow> element. The user agent stylesheet must contain the following rules in order to hide all but its first child element, which is the default behavior for the legacy actiontype values:

<maction> is implemented for compatibility with full MathML. Authors whose only target is MathML Core are encouraged to use other HTML, CSS and JavaScript mechanisms to implement custom actions. They may rely on maction attributes defined in [[MathML3]].

Semantics and Presentation

The <semantics> element is the container element that associates annotations with a MathML expression. Typically, the <semantics> element has as its first child element a MathML expression to be annotated while subsequent child elements represent text annotations within an <annotation> element, or more complex markup annotations within an <annotation-xml> element.

The following example, shows how the fraction "one half" can be annotated with a textual annotation (LaTeX) or an XML annotation (content MathML). These annotations are not intended to be rendered by the user agent.

The <semantics> element accepts the attributes described in . Its layout algorithm is the same as the <mrow> element. The user agent stylesheet must contain the following rule in order to only render the annotated MathML expression:

The <annotation-xml> and <annotation> element accepts the attributes described in as well as the following attribute:

encoding

This specification does not define any observable behavior that is specific to the encoding attribute.

The layout algorithm of the <annotation-xml> and <annotation> element is the same as the <mtext> element.

Authors can use the encoding attribute to distinguish annotations for HTML integration point, clipboard copy, alternative rendering, etc. In particular, CSS can be used to render alternative annotations e.g.

            /* Hide the annotated child. */
            semantics > :first-child { display: none; }
             /* Show all text annotations. */
            semantics > annotation { display: inline; }
            /* Show all HTML annotations. */
            semantics > annotation-xml[encoding="text/html" i],
            semantics > annotation-xml[encoding="application/xhtml+xml" i] {
              display: inline-block;
            }

Name:	`math-style`
Value:	`normal \| compact`
Initial:	`normal`
Applies to:	All elements
Inherited:	yes
Percentages:	n/a
Media:	visual
Computed value:	specified keyword
Canonical order:	n/a
Animation type:	not animatable

Name:	`math-shift`
Value:	`normal \| compact`
Initial:	`normal`
Applies to:	All elements
Inherited:	yes
Percentages:	n/a
Media:	visual
Computed value:	specified keyword
Canonical order:	n/a
Animation type:	not animatable

Name:	`math-depth`
Value:	`auto-add \| add(<integer>) \| <integer>`
Initial:	`0`
Applies to:	All elements
Inherited:	yes
Percentages:	n/a
Media:	visual
Computed value:	an integer, see below
Canonical order:	n/a
Animation type:	not animatable

Introduction

MathML Fundamentals

Elements and attributes

The Top-Level <math> Element

Types for MathML Attribute Values

Global Attributes

Attributes common to HTML and MathML elements

Legacy MathML Style Attributes

The mathvariant attribute

The displaystyle and scriptlevel attributes

Integration in the Web Platform

HTML and SVG

CSS styling

DOM and Javascript

Text layout

Focus

Presentation Markup

Visual formatting model

Box Model

Layout Algorithms

Stacking contexts

Token Elements

Text <mtext>

Layout of <mtext>

Identifier <mi>

Number <mn>

Operator, Fence, Separator or Accent <mo>

Embellished operators

Dictionary-based attributes

Layout of operators

Space <mspace>

Definition of space-like elements

String Literal <ms>

General Layout Schemata

Group Sub-Expressions <mrow>

Algorithm for stretching operators along the block axis

Layout of <mrow>

Fractions <mfrac>

Fraction with nonzero line thickness

Fraction with zero line thickness

Radicals <msqrt>, <mroot>

Radical symbol

Square root

Root with index

Style Change <mstyle>

Error Message <merror>

Adjust Space Around Content <mpadded>

Inner box and requested parameters

Layout of <mpadded>

Making Sub-Expressions Invisible <mphantom>

Script and Limit Schemata

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

Children of <msub>, <msup>, <msubsup>

Base with subscript

Base with superscript

Base with subscript and superscript

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

Children of <munder>, <mover>, <munderover>

Algorithm for stretching operators along the inline axis

Base with underscript

Base with overscript

Base with underscript and overscript

Prescripts and Tensor Indices <mmultiscripts>

Base with prescripts and postscripts

Displaystyle, scriptlevel and math-shift in scripts

Tabular Math

Table or Matrix <mtable>

Row in Table or Matrix <mtr>

Entry in Table or Matrix <mtd>

Enlivening Expressions

Semantics and Presentation

CSS Extensions for Math Layout

The display: block math and display: inline math value

New text-transform values

The math-style property

The math-shift property

New value math-depth property

OpenType MATH table

Layout constants (MathConstants)

Glyph information (MathGlyphInfo)

The Top-Level `<math>` Element

The `mathvariant` attribute

The `displaystyle` and `scriptlevel` attributes

Text `<mtext>`

Layout of `<mtext>`

Identifier `<mi>`

Number `<mn>`

Operator, Fence, Separator or Accent `<mo>`

Space `<mspace>`

String Literal `<ms>`

Group Sub-Expressions `<mrow>`

Layout of `<mrow>`

Fractions `<mfrac>`

Radicals `<msqrt>`, `<mroot>`

Style Change `<mstyle>`

Error Message `<merror>`

Adjust Space Around Content `<mpadded>`

Layout of `<mpadded>`

Making Sub-Expressions Invisible `<mphantom>`

Subscripts and Superscripts `<msub>`, `<msup>`, `<msubsup>`

Children of `<msub>`, `<msup>`, `<msubsup>`

Underscripts and Overscripts `<munder>`, `<mover>`, `<munderover>`

Children of `<munder>`, `<mover>`, `<munderover>`

Prescripts and Tensor Indices `<mmultiscripts>`

Table or Matrix `<mtable>`

Row in Table or Matrix `<mtr>`

Entry in Table or Matrix `<mtd>`

The `display: block math` and `display: inline math` value

New `text-transform` values

The `math-style` property

The `math-shift` property

New value `math-depth` property

OpenType `MATH` table

Layout constants (`MathConstants`)

Glyph information (`MathGlyphInfo`)

Size variants for operators (`MathVariants`)

The `GlyphAssembly` table

New `text-transform` Mappings

`bold-script` mappings

`bold-italic` mappings

`tailed` mappings

`bold` mappings

`fraktur` mappings

`script` mappings

`monospace` mappings

`initial` mappings

`sans-serif` mappings

`double-struck` mappings

`looped` mappings

`stretched` mappings

`italic` mappings

`bold-fraktur` mappings

`sans-serif-bold-italic` mappings

`sans-serif-italic` mappings

`bold-sans-serif` mappings