Mathematical Markup Language (MathML) Version 4.0

To describe the MathML-specific syntax of attribute values, the following conventions and notations are used for most attributes in the present document.

The ‘types’ described above, except for string, may be combined into composite patterns using the following operators. The whole attribute value must be delimited by single (') or double (") quotation marks in the marked up document. Note that double quotation marks are often used in this specification to mark up literal expressions; an example is the "-" in line 5 of the table above.

In the table below a form f means an instance of a type described in the table above. The combining operators are shown in order of precedence from highest to lowest:

The notation we have chosen here is in the style of the syntactical notation of the RelaxNG used for MathML's basic schema, A. Parsing MathML.

Since some applications are inconsistent about normalization of whitespace, for maximum interoperability it is advisable to use only a single whitespace character for separating parts of a value. Moreover, leading and trailing whitespace in attribute values should be avoided.

For most numerical attributes, only those in a subset of the expressible values are sensible; values outside this subset are not errors, unless otherwise specified, but rather are rounded up or down (at the discretion of the renderer) to the closest value within the allowed subset. The set of allowed values may depend on the renderer, and is not specified by MathML.

If a numerical value within an attribute value syntax description is declared to allow a minus sign ('-'), e.g., number or integer, it is not a syntax error when one is provided in cases where a negative value is not sensible. Instead, the value should be handled by the processing application as described in the preceding paragraph. An explicit plus sign ('+') is not allowed as part of a numerical value except when it is specifically listed in the syntax (as a quoted '+' or "+"), and its presence can change the meaning of the attribute value (as documented with each attribute which permits it).

Most presentation elements have attributes that accept values representing lengths to be used for size, spacing or similar properties. [MathML-Core] accepts lengths only in the <length-percentage> syntax defined in [CSS-VALUES-3]. MathML Full extends length syntax by accepting also a namedspace being one of:

In addition, the attributes on mpadded allow three pseudo-units, height, depth, and width (taking the place of one of the usual CSS units) denoting the original dimensions of the content.

MathML 3 also allowed a deprecated usage with lengths specified as a number without a unit. This was interpreted as a multiple of the reference value. This form is considered invalid in MathML 4.

Default values for MathML attributes are, in general, given along with the detailed descriptions of specific elements in the text. Default values shown in plain text in the tables of attributes for an element are literal, but when italicized are descriptions of how default values can be computed.

Default values described as inherited are taken from the rendering environment, as described in 3.3.4 Style Change <mstyle>, or in some cases (which are described individually) taken from the values of other attributes of surrounding elements, or from certain parts of those values. The value used will always be one which could have been specified explicitly, had it been known; it will never depend on the content or attributes of the same element, only on its environment. (What it means when used may, however, depend on those attributes or the content.)

Default values described as automatic should be computed by a MathML renderer in a way which will produce a high-quality rendering; how to do this is not usually specified by the MathML specification. The value computed will always be one which could have been specified explicitly, had it been known, but it will usually depend on the element content and possibly on the context in which the element is rendered.

Other italicized descriptions of default values which appear in the tables of attributes are explained individually for each attribute.

The single or double quotes which are required around attribute values in an XML start tag are not shown in the tables of attribute value syntax for each element, but are around attribute values in examples in the text, so that the pieces of code shown are correct.

Note that, in general, there is no mechanism in MathML to simulate the effect of not specifying attributes which are inherited or automatic. Giving the words inherited or automatic explicitly will not work, and is not generally allowed. Furthermore, the mstyle element (3.3.4 Style Change <mstyle>) can even be used to change the default values of presentation attributes for its children.

Note also that these defaults describe the behavior of MathML applications when an attribute is not supplied; they do not indicate a value that will be filled in by an XML parser, as is sometimes mandated by DTD-based specifications.

In general, there are a number of properties of MathML rendering that may be thought of as overall properties of a document, or at least of sections of a large document. Examples might be mathsize (the math font size: see 3.2.2 Mathematics style attributes common to token elements), or the behavior in setting limits on operators such as integrals or sums (e.g., movablelimits or displaystyle), or upon breaking formulas over lines (e.g. linebreakstyle); for such attributes see several elements in 3.2 Token Elements. These may be thought to be inherited from some such containing scope. Just above we have mentioned the setting of default values of MathML attributes as inherited or automatic; there is a third source of global default values for behavior in rendering MathML, a MathML operator dictionary. A default example is provided in B. Operator Dictionary. This is also discussed in 3.2.5.6.1 The operator dictionary and examples are given in 3.2.5.2.1 Dictionary-based attributes.

The elements listed in the following table as requiring 1* argument (msqrt, mstyle, merror, mpadded, mphantom, menclose, mtd, mscarry, and math) conceptually accept a single argument, but actually accept any number of children. If the number of children is 0 or is more than 1, they treat their contents as a single inferred mrow formed from all their children, and treat this mrow as the argument.

For example,

<msqrt>
  <mo> - </mo>
  <mn> 1 </mn>
</msqrt>

is treated as if it were

<msqrt>
  <mrow>
    <mo> - </mo>
    <mn> 1 </mn>
  </mrow>
</msqrt>

This feature allows MathML data not to contain (and its authors to leave out) many mrow elements that would otherwise be necessary.

For convenience, here is a table of each element's argument count requirements and the roles of individual arguments when these are distinguished. An argument count of 1* indicates an inferred mrow as described above. Although the math element is not a presentation element, it is listed below for completeness.

The overall directionality for a formula, basically the direction of the Layout Schemata, is specified by the dir attribute on the containing math element (see 2.2 The Top-Level <math> Element). The default is ltr. When dir=rtl is used, the layout is simply the mirror image of the conventional European layout. That is, shifts up or down are unchanged, but the progression in laying out is from right to left.

For example, in a RTL layout, sub- and superscripts appear to the left of the base; the surd for a root appears at the right, with the bar continuing over the base to the left. The layout details for elements whose behavior depends on directionality are given in the discussion of the element. In those discussions, the terms leading and trailing are used to specify a side of an object when which side to use depends on the directionality; i.e. leading means left in LTR but right in RTL. The terms left and right may otherwise be safely assumed to mean left and right.

The overall directionality is usually set on the math, but may also be switched for an individual subexpression by using the dir attribute on mrow or mstyle elements. When not specified, all elements inherit the directionality of their container.

The text directionality comes into play for the MathML token elements that can contain text (mtext, mo, mi, mn and ms) and is determined by the Unicode properties of that text. A token element containing exclusively LTR or RTL characters is displayed straightforwardly in the given direction. When a mixture of directions is involved, such as RTL Arabic and LTR numbers, the Unicode bidirectional algorithm [Bidi] should be applied. This algorithm specifies how runs of characters with the same direction are processed and how the runs are (re)ordered. The base, or initial, direction is given by the overall directionality described above (3.1.5.1 Overall Directionality of Mathematics Formulas) and affects how weakly directional characters are treated and how runs are nested. (The dir attribute is thus allowed on token elements to specify the initial directionality that may be needed in rare cases.) Any mglyph or malignmark elements appearing within a token element are effectively neutral and have no effect on ordering.

The important thing to notice is that the bidirectional algorithm is applied independently to the contents of each token element; each token element is an independent run of characters.

Other features of Unicode and scripts that should be respected are ‘mirroring’ and ‘glyph shaping’. Some Unicode characters are marked as being mirrored when presented in a RTL context; that is, the character is drawn as if it were mirrored or replaced by a corresponding character. Thus an opening parenthesis, ‘(’, in RTL will display as ‘)’. Conversely, the solidus (/ U+002F) is not marked as mirrored. Thus, an Arabic author that desires the slash to be reversed in an inline division should explicitly use reverse solidus (\ U+005C) or an alternative such as the mirroring DIVISION SLASH (U+2215).

Additionally, calligraphic scripts such as Arabic blend, or connect sequences of characters together, changing their appearance. As this can have a significant impact on readability, as well as aesthetics, it is important to apply such shaping if possible. Glyph shaping, like directionality, applies to each token element's contents individually.

Note that for the transfinite cardinals represented by Hebrew characters, the code points U+2135-U+2138 (ALEF SYMBOL, BET SYMBOL, GIMEL SYMBOL, DALET SYMBOL) should be used in MathML, not the alphabetic look-alike code points. These code points are strong left-to-right.

MathML provides support for both automatic and manual (forced) linebreaking of expressions to break excessively long expressions into several lines. All such linebreaks take place within mrow (including inferred mrow; see 3.1.3.1 Inferred <mrow>s) or mfenced. The breaks typically take place at mo elements and also, for backwards compatibility, at mspace. Renderers may also choose to place automatic linebreaks at other points such as between adjacent mi elements or even within a token element such as a very long mn element. MathML does not provide a means to specify such linebreaks, but if a renderer chooses to linebreak at such a point, it should indent the following line according to the indentation attributes that are in effect at that point.

Automatic linebreaking occurs when the containing math element has overflow=linebreak and the display engine determines that there is not enough space available to display the entire formula. The available width must therefore be known to the renderer. Like font properties, one is assumed to be inherited from the environment in which the MathML element lives. If no width can be determined, an infinite width should be assumed. Inside of an mtable, each column has some width. This width may be specified as an attribute or determined by the contents. This width should be used as the line wrapping width for linebreaking, and each entry in an mtable is linewrapped as needed.

Forced linebreaks are specified by using linebreak=newline on an mo or mspace element. Both automatic and manual linebreaking can occur within the same formula.

Automatic linebreaking of subexpressions of mfrac, msqrt, mroot and menclose and the various script elements is not required. Renderers are free to ignore forced breaks within those elements if they choose.

Attributes on mo and possibly on mspace elements control linebreaking and indentation of the following line. The aspects of linebreaking that can be controlled are:

• Where — attributes determine the desirability of a linebreak at a specific operator or space, in particular whether a break is required or inhibited. These can only be set on mo and mspace elements. (See 3.2.5.2.2 Linebreaking attributes.)

• Operator Display/Position — when a linebreak occurs, determines whether the operator will appear at the end of the line, at the beginning of the next line, or in both positions; and how much vertical space should be added after the linebreak. These attributes can be set on mo elements or inherited from mstyle or math elements. (See 3.2.5.2.2 Linebreaking attributes.)

• Indentation — determines the indentation of the line following a linebreak, including indenting so that the next line aligns with some point in a previous line. These attributes can be set on mo elements or inherited from mstyle or math elements. (See 3.2.5.2.3 Indentation attributes.)

When a math element appears in an inline context, it may obey whatever paragraph flow rules are employed by the document's text rendering engine. Such rules are necessarily outside of the scope of this specification. Alternatively, it may use the value of the math element's overflow attribute. (See 2.2.1 Attributes.)

Additionally, the mglyph element may be used within Token elements to represent non-standard symbols as images.

Presentation elements also accept all the Global Attributes specified by [MathML-Core].

These attributes include the following two attributes that are primarily intended for visual media. They are not expected to affect the intended semantics of displayed expressions, but are for use in highlighting or drawing attention to the affected subexpressions. For example, a red "x" is not assumed to be semantically different than a black "x", in contrast to variables with different mathvariant values (see 3.2.2 Mathematics style attributes common to token elements).

Since MathML expressions are often embedded in a textual data format such as HTML, the MathML renderer should inherit the foreground color used in the context in which the MathML appears. Note, however, that MathML (in contrast to [MathML-Core]) doesn't specify the mechanism by which style information is inherited from the rendering environment. See 3.2.2 Mathematics style attributes common to token elements for more details.

Note that the suggested MathML visual rendering rules do not define the precise extent of the region whose background is affected by the mathbackground attribute, except that, when the content does not have negative dimensions and its drawing region should not overlap with other drawing due to surrounding negative spacing, should lie behind all the drawing done to render the content, and should not lie behind any of the drawing done to render surrounding expressions. The effect of overlap of drawing regions caused by negative spacing on the extent of the region affected by the mathbackground attribute is not defined by these rules.

MathML can be combined with other formats as described in 7.4 Combining MathML and Other Formats. The recommendation is to embed other formats in MathML by extending the MathML schema to allow additional elements to be children of the mtext element or other leaf elements as appropriate to the role they serve in the expression (see 3.2.3 Identifier <mi>, 3.2.4 Number <mn>, and 3.2.5 Operator, Fence, Separator or Accent <mo>). The directionality, font size, and other font attributes should inherit from those that would be used for characters of the containing leaf element (see 3.2.2 Mathematics style attributes common to token elements).

Here is an example of embedding SVG inside of mtext in an HTML context:

<mtable>
 <mtr>
  <mtd>
   <mtext><input type="text" placeholder="what shape is this?"/></mtext>
  </mtd>
 </mtr>
 <mtr>
  <mtd>
   <mtext>
    <svg xmlns="http://www.w3.org/2000/svg" width="4cm" height="4cm" viewBox="0 0 400 400">
     <rect x="1" y="1" width="398" height="398" style="fill:none; stroke:blue"/>
     <path d="M 100 100 L 300 100 L 200 300 z" style="fill:red; stroke:blue; stroke-width:3"/>
    </svg>
   </mtext>
  </mtd>
 </mtr>
</mtable>

An 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. A typical graphical renderer would render an mi element as its content (see 3.2.1 Token Element Content Characters, <mglyph/>), with no extra spacing around it (except spacing associated with neighboring elements).

Not all mathematical identifiers are represented by mi elements — for example, subscripted or primed variables should be represented using msub or msup respectively. Conversely, arbitrary text playing the role of a term (such as an ellipsis in a summed series) should be represented using an mi element.

It should be stressed that mi is a presentation element, and as such, it only indicates that its content should be rendered as an identifier. In the majority of cases, the contents of an mi will actually represent a mathematical identifier such as a variable or function name. However, as the preceding paragraph indicates, the correspondence between notations that should render as identifiers and notations that are actually intended to represent mathematical identifiers is not perfect. For an element whose semantics is guaranteed to be that of an identifier, see the description of ci in 4. Content Markup.

mi elements accept the attributes listed in 3.2.2 Mathematics style attributes common to token elements, but in one case with a different default value:

Note that for purposes of determining equivalences of Math Alphanumeric Symbol characters (see 8.2 Mathematical Alphanumeric Symbols) the value of the mathvariant attribute should be resolved first, including the special defaulting behavior described above.

An 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. A typical graphical renderer would render an mn element as its content (see 3.2.1 Token Element Content Characters, <mglyph/>), with no extra spacing around them (except spacing from neighboring elements such as mo). mn elements are typically rendered in an unslanted font.

The mathematical concept of a number can be quite subtle and involved, depending on the context. As a consequence, not all mathematical numbers should be represented using mn; examples of mathematical numbers that should be represented differently are shown below, and include complex numbers, ratios of numbers shown as fractions, and names of numeric constants.

Conversely, since mn is a presentation element, there are a few situations where it may be desirable to include arbitrary text in the content of an mn that should merely render as a numeric literal, even though that content may not be unambiguously interpretable as a number according to any particular standard encoding of numbers as character sequences. As a general rule, however, the mn element should be reserved for situations where its content is actually intended to represent a numeric quantity in some fashion. For an element whose semantics are guaranteed to be that of a particular kind of mathematical number, see the description of cn in 4. Content Markup.

mn elements accept the attributes listed in 3.2.2 Mathematics style attributes common to token elements.

Many mathematical numbers should be represented using presentation elements other than mn alone; this includes complex numbers, negative numbers, ratios of numbers shown as fractions, and names of numeric constants.

<mrow>
  <mn> 2 </mn>
  <mo> + </mo>
  <mrow>
    <mn> 3 </mn>
    <mo> &#x2062;<!--InvisibleTimes--> </mo>
    <mi> ⅈ </mi>
  </mrow>
</mrow>

<mfrac> <mn> 1 </mn> <mn> 2 </mn> </mfrac>

<mrow><mo>-</mo><mn>2</mn></mrow>

<mi> π </mi>

<mi> ⅇ </mi>

An 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. We will use the term "operator" in this chapter to refer to operators in this broad sense.

Typical graphical renderers show all mo elements as the content (see 3.2.1 Token Element Content Characters, <mglyph/>), with additional spacing around the element determined by its attributes and further described below. Renderers without access to complete fonts for the MathML character set may choose to render an mo element as not precisely the characters in its content in some cases. For example, <mo> ≤ </mo> might be rendered as <= to a terminal. However, as a general rule, renderers should attempt to render the content of an mo element as literally as possible. That is, <mo> ≤ </mo> and <mo> &lt;= </mo> should render differently. The first one should render as a single character representing a less-than-or-equal-to sign, and the second one as the two-character sequence <=.

A key feature of the mo element is that its default attribute values are set on a case-by-case basis from an operator dictionary as explained below. In particular, default value for stretch, symmetric and accent can usually be found in the operator dictionary and therefore need not be specified on each mo element.

Note that some mathematical operators are represented not by mo elements alone, but by mo elements embellished with (for example) surrounding superscripts; this is further described below. Conversely, as presentation elements, mo elements can contain arbitrary text, even when that text has no standard interpretation as an operator; for an example, see the discussion Mixing text and mathematics in 3.2.6 Text <mtext>. See also 4. Content Markup for definitions of MathML content elements that are guaranteed to have the semantics of specific mathematical operators.

Note also that linebreaking, as discussed in 3.1.7 Linebreaking of Expressions, usually takes place at operators (either before or after, depending on local conventions). Thus, mo accepts attributes to encode the desirability of breaking at a particular operator, as well as attributes describing the treatment of the operator and indentation in case a linebreak is made at that operator.

mo elements accept the attributes listed in 3.2.2 Mathematics style attributes common to token elements and the additional attributes listed here. Since the display of operators is so critical in mathematics, the mo element accepts a large number of attributes; these are described in the next three subsections.

Most attributes get their default values from an enclosing mstyle element, math element, from the containing document, or from 3.2.5.6.1 The operator dictionary. When a value that is listed as inherited is not explicitly given on an mo, mstyle element, math element, or found in the operator dictionary for a given mo element, the default value shown in parentheses is used.

Certain operators that are invisible in traditional mathematical notation should be represented using specific characters (or entity references) within mo elements, rather than simply by nothing. The characters used for these invisible operators are:

<mrow>
  <mi> f </mi>
  <mo> &#x2061;<!--ApplyFunction--> </mo>
  <mrow>
    <mo> ( </mo>
    <mi> x </mi>
    <mo> ) </mo>
  </mrow>
</mrow>

<mrow>
  <mi> sin </mi>
  <mo> &#x2061;<!--ApplyFunction--> </mo>
  <mi> x </mi>
</mrow>

<mrow>
  <mi> x </mi>
  <mo> &#x2062;<!--InvisibleTimes--> </mo>
  <mi> y </mi>
</mrow>

<msub>
  <mi> m </mi>
  <mrow>
    <mn> 1 </mn>
    <mo> &#x2063;<!--InvisibleComma--> </mo>
    <mn> 2 </mn>
  </mrow>
</msub>

<mrow>
  <mn> 2 </mn>
  <mo> &#x2064; </mo>
  <mfrac>
    <mn> 3 </mn>
    <mn> 4 </mn>
  </mfrac>
</mrow>

Typical visual rendering behaviors for mo elements are more complex than for the other MathML token elements, so the rules for rendering them are described in this separate subsection.

Note that, like all rendering rules in MathML, these rules are suggestions rather than requirements. The description below is given to make the intended effect of the various rendering attributes as clear as possible. Detailed layout rules for browser implementations for operators are given in MathML Core.

Four attributes govern whether and how an operator (perhaps embellished) stretches so that it matches the size of other elements: stretchy, symmetric, maxsize, and minsize. If an operator has the attribute stretchy=true, then it (that is, each character in its content) obeys the stretching rules listed below, given the constraints imposed by the fonts and font rendering system. In practice, typical renderers will only be able to stretch a small set of characters, and quite possibly will only be able to generate a discrete set of character sizes.

There is no provision in MathML for specifying in which direction (horizontal or vertical) to stretch a specific character or operator; rather, when stretchy=true it should be stretched in each direction for which stretching is possible and reasonable for that character. It is up to the renderer to know in which directions it is reasonable to stretch a character, if it can stretch the character. Most characters can be stretched in at most one direction by typical renderers, but some renderers may be able to stretch certain characters, such as diagonal arrows, in both directions independently.

The minsize and maxsize attributes limit the amount of stretching (in either direction). These two attributes are given as multipliers of the operator's normal size in the direction or directions of stretching, or as absolute sizes using units. For example, if a character has maxsize=300%, then it can grow to be no more than three times its normal (unstretched) size.

The symmetric attribute governs whether the height and depth above and below the axis of the character are forced to be equal (by forcing both height and depth to become the maximum of the two). An example of a situation where one might set symmetric=false arises with parentheses around a matrix not aligned on the axis, which frequently occurs when multiplying non-square matrices. In this case, one wants the parentheses to stretch to cover the matrix, whereas stretching the parentheses symmetrically would cause them to protrude beyond one edge of the matrix. The symmetric attribute only applies to characters that stretch vertically (otherwise it is ignored).

If a stretchy mo element is embellished (as defined earlier in this section), the mo element at its core is stretched to a size based on the context of the embellished operator as a whole, i.e. to the same size as if the embellishments were not present. For example, the parentheses in the following example (which would typically be set to be stretchy by the operator dictionary) will be stretched to the same size as each other, and the same size they would have if they were not underlined and overlined, and furthermore will cover the same vertical interval:

<mrow>
  <munder>
    <mo> ( </mo>
    <mo> _ </mo>
  </munder>
  <mfrac>
    <mi> a </mi>
    <mi> b </mi>
  </mfrac>
  <mover>
    <mo> ) </mo>
    <mo> ‾ </mo>
  </mover>
</mrow>

Note that this means that the stretching rules given below must refer to the context of the embellished operator as a whole, not just to the mo element itself.

<mrow>
  <mo maxsize="100%">(</mo>
  <mfrac>
    <msup><mi>a</mi><mn>2</mn></msup>
    <msup><mi>b</mi><mn>2</mn></msup>
  </mfrac>
  <mo maxsize="100%">)</mo>
</mrow>

<mrow>
  <mi> x </mi>
  <munder>
    <mo> → </mo>
    <mtext> maps to </mtext>
  </munder>
  <mi> y </mi>
</mrow>

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

Note that text with a clearly defined notational role might be more appropriately marked up using mi or mo.

An mtext element can also contain renderable whitespace, i.e. invisible characters that are intended to alter the positioning of surrounding elements. In non-graphical media, such characters are intended to have an analogous effect, such as introducing positive or negative time delays or affecting rhythm in an audio renderer. However, see 2.1.7 Collapsing Whitespace in Input.

mtext elements accept the attributes listed in 3.2.2 Mathematics style attributes common to token elements.

See also the warnings about the legal grouping of space-like elements in 3.2.7 Space <mspace/>, and about the use of such elements for tweaking in [MathML-Notes].

An mspace empty element represents a blank space of any desired size, as set by its attributes. It can also be used to make linebreaking suggestions to a visual renderer. Note that the default values for attributes have been chosen so that they typically will have no effect on rendering. Thus, the mspace element is generally used with one or more attribute values explicitly specified.

Note the warning about the legal grouping of space-like elements given below, and the warning about the use of such elements for tweaking in [MathML-Notes]. See also the other elements that can render as whitespace, namely mtext, mphantom, and maligngroup.

In addition to the attributes listed below, mspace elements accept the attributes described in 3.2.2 Mathematics style attributes common to token elements, but note that mathvariant and mathcolor have no effect and that mathsize only affects the interpretation of units in sizing attributes (see 2.1.5.2 Length Valued Attributes). mspace also accepts the indentation attributes described in 3.2.5.2.3 Indentation attributes.

Linebreaking was originally specified on mspace in MathML2, but much greater control over linebreaking and indentation was add to mo in MathML 3. Linebreaking on mspace is deprecated in MathML 4.

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. For example, space-like elements are handled specially in the suggested rendering rules for mo given in 3.2.5 Operator, Fence, Separator or Accent <mo>. The following MathML elements are defined to be space-like:

• an mtext, mspace, maligngroup, or malignmark element;

• an mstyle, mphantom, or mpadded element, all of whose direct sub-expressions are space-like;

• a semantics element whose first argument exists and is space-like;

• an maction element whose selected sub-expression exists and is space-like;

• an mrow all of whose direct sub-expressions 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.

Authors who insert space-like elements or mphantom elements into an existing MathML expression should note that such elements are counted as arguments, in elements that require a specific number of arguments, or that interpret different argument positions differently.

Therefore, space-like elements inserted into such a MathML element should be grouped with a neighboring argument of that element by introducing an mrow for that purpose. For example, to allow for vertical alignment on the right edge of the base of a superscript, the expression

<msup>
  <mi> x </mi>
  <malignmark edge="right"/>
  <mn> 2 </mn>
</msup>

is illegal, because msup must have exactly 2 arguments; the correct expression would be:

<msup>
  <mrow>
    <mi> x </mi>
    <malignmark edge="right"/>
  </mrow>
  <mn> 2 </mn>
</msup>

See also the warning about tweaking in [MathML-Notes].

The ms element is used to represent string literals in expressions meant to be interpreted by computer algebra systems or other systems containing programming languages. By default, string literals are displayed surrounded by double quotes, with no extra spacing added around the string. As explained in 3.2.6 Text <mtext>, ordinary text embedded in a mathematical expression should be marked up with mtext, or in some cases mo or mi, but never with ms.

Note that the string literals encoded by ms are made up of characters, mglyphs and malignmarks rather than ASCII strings. For example, <ms>&amp;</ms> represents a string literal containing a single character, &, and <ms>&amp;amp;</ms> represents a string literal containing 5 characters, the first one of which is &.

The content of ms elements should be rendered with visible escaping of certain characters in the content, including at least the left and right quoting characters, and preferably whitespace other than individual space characters. The intent is for the viewer to see that the expression is a string literal, and to see exactly which characters form its content. For example, <ms>double quote is "</ms> might be rendered as "double quote is \"".

Like all token elements, ms does trim and collapse whitespace in its content according to the rules of 2.1.7 Collapsing Whitespace in Input, so whitespace intended to remain in the content should be encoded as described in that section.

ms elements accept the attributes listed in 3.2.2 Mathematics style attributes common to token elements, and additionally:

An mrow element is used to group together any number of sub-expressions, usually consisting of one or more mo elements acting as operators on one or more other expressions that are their operands.

Several elements automatically treat their arguments as if they were contained in an mrow element. See the discussion of inferred mrows in 3.1.3 Required Arguments. See also mfenced (3.3.8 Expression Inside Pair of Fences <mfenced>), which can effectively form an mrow containing its arguments separated by commas.

mrow elements are typically rendered visually as a horizontal row of their arguments, left to right in the order in which the arguments occur within a context with LTR directionality, or right to left within a context with RTL directionality. The dir attribute can be used to specify the directionality for a specific mrow, otherwise it inherits the directionality from the context. For aural agents, the arguments would be rendered audibly as a sequence of renderings of the arguments. The description in 3.2.5 Operator, Fence, Separator or Accent <mo> of suggested rendering rules for mo elements assumes that all horizontal spacing between operators and their operands is added by the rendering of mo elements (or, more generally, embellished operators), not by the rendering of the mrows they are contained in.

MathML provides support for both automatic and manual linebreaking of expressions (that is, to break excessively long expressions into several lines). All such linebreaks take place within mrows, whether they are explicitly marked up in the document, or inferred (see 3.1.3.1 Inferred <mrow>s), although the control of linebreaking is effected through attributes on other elements (see 3.1.7 Linebreaking of Expressions).

mrow elements accept the attribute listed below in addition to those listed in 3.1.9 Mathematics attributes common to presentation elements.

Sub-expressions should be grouped by the document author in the same way as they are grouped in the mathematical interpretation of the expression; that is, according to the underlying syntax tree of the expression. Specifically, operators and their mathematical arguments should occur in a single mrow; more than one operator should occur directly in one mrow only when they can be considered (in a syntactic sense) to act together on the interleaved arguments, e.g. for a single parenthesized term and its parentheses, for chains of relational operators, or for sequences of terms separated by + and -. A precise rule is given below.

Proper grouping has several purposes: it improves display by possibly affecting spacing; it allows for more intelligent linebreaking and indentation; and it simplifies possible semantic interpretation of presentation elements by computer algebra systems, and audio renderers.

Although improper grouping will sometimes result in suboptimal renderings, and will often make interpretation other than pure visual rendering difficult or impossible, any grouping of expressions using mrow is allowed in MathML syntax; that is, renderers should not assume the rules for proper grouping will be followed.

The mfrac element is used for fractions. It can also be used to mark up fraction-like objects such as binomial coefficients and Legendre symbols. The syntax for mfrac is

<mfrac> numerator denominator </mfrac>

The mfrac element sets displaystyle to false, or if it was already false increments scriptlevel by 1, within numerator and denominator. (See 3.1.6 Displaystyle and Scriptlevel.)

mfrac elements accept the attributes listed below in addition to those listed in 3.1.9 Mathematics attributes common to presentation elements. The fraction line, if any, should be drawn using the color specified by mathcolor.

Thicker lines (e.g. linethickness="thick") might be used with nested fractions; a value of "0" renders without the bar such as for binomial coefficients.

In a RTL directionality context, the numerator leads (on the right), the denominator follows (on the left) and the diagonal line slants upwards going from right to left (see 3.1.5.1 Overall Directionality of Mathematics Formulas for clarification). Although this format is an established convention, it is not universally followed; for situations where a forward slash is desired in a RTL context, alternative markup, such as an mo within an mrow should be used.

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

<msqrt> base </msqrt>
<mroot> base index </mroot>

The mroot element requires exactly 2 arguments. However, msqrt accepts a single argument, possibly being an inferred mrow of multiple children; see 3.1.3 Required Arguments. The mroot element increments scriptlevel by 2, and sets displaystyle to false, within index, but leaves both attributes unchanged within base. The msqrt element leaves both attributes unchanged within its argument. (See 3.1.6 Displaystyle and Scriptlevel.)

Note that in a RTL directionality, the surd begins on the right, rather than the left, along with the index in the case of mroot.

msqrt and mroot elements accept the attributes listed in 3.1.9 Mathematics attributes common to presentation elements. The surd and overbar should be drawn using the color specified by mathcolor.

The mstyle element is used to make style changes that affect the rendering of its contents. As a presentation element, it accepts the attributes described in 3.1.9 Mathematics attributes common to presentation elements. Additionally, it can be given any attribute accepted by any other presentation element, except for the attributes described below. Finally, the mstyle element can be given certain special attributes listed in the next subsection.

The mstyle element accepts a single argument, possibly being an inferred mrow of multiple children; see 3.1.3 Required Arguments.

Loosely speaking, the effect of the mstyle element is to change the default value of an attribute for the elements it contains. Style changes work in one of several ways, depending on the way in which default values are specified for an attribute. The cases are:

• Some attributes, such as displaystyle or scriptlevel (explained below), are inherited from the surrounding context when they are not explicitly set. Specifying such an attribute on an mstyle element sets the value that will be inherited by its child elements. Unless a child element overrides this inherited value, it will pass it on to its children, and they will pass it to their children, and so on. But if a child element does override it, either by an explicit attribute setting or automatically (as is common for scriptlevel), the new (overriding) value will be passed on to that element's children, and then to their children, etc, unless it is again overridden.

• Other attributes, such as linethickness on mfrac, have default values that are not normally inherited. That is, if the linethickness attribute is not set on the mfrac element, it will normally use the default value of medium, even if it was contained in a larger mfrac element that set this attribute to a different value. For attributes like this, specifying a value with an mstyle element has the effect of changing the default value for all elements within its scope. The net effect is that setting the attribute value with mstyle propagates the change to all the elements it contains directly or indirectly, except for the individual elements on which the value is overridden. Unlike in the case of inherited attributes, elements that explicitly override this attribute have no effect on this attribute's value in their children.

• Another group of attributes, such as stretchy and form, are computed from operator dictionary information, position in the enclosing mrow, and other similar data. For these attributes, a value specified by an enclosing mstyle overrides the value that would normally be computed.

Note that attribute values inherited from an mstyle in any manner affect a descendant element in the mstyle's content only if that attribute is not given a value by the descendant element. On any element for which the attribute is set explicitly, the value specified overrides the inherited value. The only exception to this rule is when the attribute value is documented as specifying an incremental change to the value inherited from that element's context or rendering environment.

Note also that the difference between inherited and non-inherited attributes set by mstyle, explained above, only matters when the attribute is set on some element within the mstyle's contents that has descendants also setting it. Thus it never matters for attributes, such as mathsize, which can only be set on token elements (or on mstyle itself).

MathML specifies that when the attributes height, depth or width are specified on an mstyle element, they apply only to mspace elements, and not to the corresponding attributes of mglyph, mpadded, or mtable. Similarly, when rowalign or columnalign are specified on an mstyle element, they apply only to the mtable element, and not the mtr, mtd, and maligngroup elements. When the lspace attribute is set with mstyle, it applies only to the mo element and not to mpadded. To be consistent, the voffset attribute of the mpadded element can not be set on mstyle. When the align attribute is set with mstyle, it applies only to the munder, mover, and munderover elements, and not to the mtable and mstack elements. The attributes src and alt on mglyph, and actiontype on maction, cannot be set on mstyle.

As a presentation element, mstyle directly accepts the mathcolor and mathbackground attributes. Thus, the mathbackground specifies the color to fill the bounding box of the mstyle element itself; it does not specify the default background color. This is an incompatible change from MathML 2, but it is more useful and intuitive. Since the default for mathcolor is inherited, this is no change in its behavior.

As stated above, mstyle accepts all attributes of all MathML presentation elements which do not have required values. That is, all attributes which have an explicit default value or a default value which is inherited or computed are accepted by the mstyle element. This group of attributes is not accepted in MathML Core.

mstyle elements accept the attributes listed in 3.1.9 Mathematics attributes common to presentation elements.

Additionally, mstyle can be given the following special attributes that are implicitly inherited by every MathML element as part of its rendering environment:

If scriptlevel is changed incrementally by an mstyle element that also sets certain other attributes, the overall effect of the changes may depend on the order in which they are processed. In such cases, the attributes in the following list should be processed in the following order, regardless of the order in which they occur in the XML-format attribute list of the mstyle start tag: scriptsizemultiplier, scriptminsize, scriptlevel, mathsize.

The merror element displays its contents as an error message. This might be done, for example, by displaying the contents in red, flashing the contents, or changing the background color. The contents can be any expression or expression sequence.

merror accepts a single argument possibly being an inferred mrow of multiple children; see 3.1.3 Required Arguments.

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. Since it is anticipated that preprocessors that parse input syntaxes designed for easy hand entry will be developed to generate MathML, it is important that they have the ability to indicate that a syntax error occurred at a certain point. See D.2 Handling of Errors.

The suggested use of merror for reporting syntax errors is for a preprocessor to replace the erroneous part of its input with an merror element containing a description of the error, while processing the surrounding expressions normally as far as possible. By this means, the error message will be rendered where the erroneous input would have appeared, had it been correct; this makes it easier for an author to determine from the rendered output what portion of the input was in error.

No specific error message format is suggested here, but as with error messages from any program, the format should be designed to make as clear as possible (to a human viewer of the rendered error message) what was wrong with the input and how it can be fixed. If the erroneous input contains correctly formatted subsections, it may be useful for these to be preprocessed normally and included in the error message (within the contents of the merror element), taking advantage of the ability of merror to contain arbitrary MathML expressions rather than only text.

merror elements accept the attributes listed in 3.1.9 Mathematics attributes common to presentation elements.

An mpadded element renders the same as its child content, but with the size of the child's bounding box and the relative positioning point of its content modified according to mpadded's attributes. It does not rescale (stretch or shrink) its content. The name of the element reflects the typical use of mpadded to add padding, or extra space, around its content. However, mpadded can be used to make more general adjustments of size and positioning, and some combinations, e.g. negative padding, can cause the content of mpadded to overlap the rendering of neighboring content. See [MathML-Notes] for warnings about several potential pitfalls of this effect.

The mpadded element accepts a single argument which may be an inferred mrow of multiple children; see 3.1.3 Required Arguments.

It is suggested that audio renderers add (or shorten) time delays based on the attributes representing horizontal space (width and lspace).

mpadded elements accept the attributes listed below in addition to those specified in 3.1.9 Mathematics attributes common to presentation elements.

Note: while [MathML-Core] supports the above attributes, it only allows the value to be a valid <length-percentage>. Increments with the optional "+" or "-" signs are not supported in MathML Core nor are pseudo-units.

The pseudo-unit syntax symbol is described below. Also, height, depth and width attributes are referred to as size attributes, while lspace and voffset attributes are position attributes.

These attributes specify the size of the bounding box of the mpadded element relative to the size of the bounding box of its child content, and specify the position of the child content of the mpadded element relative to the natural positioning of the mpadded element. The typographical layout parameters determined by these attributes are described in the next subsection. Depending on the form of the attribute value, a dimension may be set to a new value, or specified relative to the child content's corresponding dimension. Values may be given as multiples or percentages of any of the dimensions of the normal rendering of the child content using so-called pseudo-units, or they can be set directly using standard units, see 2.1.5.2 Length Valued Attributes.

If the value of a size attribute begins with a + or - sign, it specifies an increment or decrement to the corresponding dimension by the following length value. Otherwise the corresponding dimension is set directly to the following length value. Note that since a leading minus sign indicates a decrement, the size attributes (height, depth, width) cannot be set directly to negative values. In addition, specifying a decrement that would produce a net negative value for these attributes has the same effect as setting the attribute to zero. In other words, the effective bounding box of an mpadded element always has non-negative dimensions. However, negative values are allowed for the relative positioning attributes lspace and voffset.

Length values (excluding any sign) can be specified in several formats. Each format begins with an unsigned-number, which may be followed by a % sign (effectively scaling the number) and an optional pseudo-unit, by a pseudo-unit alone, or by a unit (excepting %). The possible pseudo-units are the keywords height, depth, and width. They represent the length of the same-named dimension of the mpadded element's child content.

For any of these length formats, the resulting length is the product of the number (possibly including the %) and the following pseudo-unit, unit, namedspace or the default value for the attribute if no such unit or space is given.

Some examples of attribute formats using pseudo-units (explicit or default) are as follows: depth="100%height" and depth="1.0height" both set the depth of the mpadded element to the height of its content. depth="105%" sets the depth to 1.05 times the content's depth, and either depth="+100%" or depth="200%" sets the depth to twice the content's depth.

The rules given above imply that all of the following attribute settings have the same effect, which is to leave the content's dimensions unchanged:

<mpadded width="+0em"> ... </mpadded>
<mpadded width="+0%"> ... </mpadded>
<mpadded width="-0em"> ... </mpadded>
<mpadded width="-0height"> ... </mpadded>
<mpadded width="100%"> ... </mpadded>
<mpadded width="100%width"> ... </mpadded>
<mpadded width="1width"> ... </mpadded>
<mpadded width="1.0width"> ... </mpadded>
<mpadded> ... </mpadded>

Note that the examples in the Version 2 of the MathML specification showed spaces within the attribute values, suggesting that this was the intended format. Formally, spaces are not allowed within these values, but implementers may wish to ignore such spaces to maximize backward compatibility.

The content of an mpadded element defines a fragment of mathematical notation, such as a character, fraction, or expression, that can be regarded as a single typographical element with a natural positioning point relative to its natural bounding box.

The size of the bounding box of an mpadded element is defined as the size of the bounding box of its content, except as modified by the mpadded element's height, depth, and width attributes. The natural positioning point of the child content of the mpadded element is located to coincide with the natural positioning point of the mpadded element, except as modified by the lspace and voffset attributes. Thus, the size attributes of mpadded can be used to expand or shrink the apparent bounding box of its content, and the position attributes of mpadded can be used to move the content relative to the bounding box (and hence also neighboring elements). Note that MathML doesn't define the precise relationship between "ink", bounding boxes and positioning points, which are implementation specific. Thus, absolute values for mpadded attributes may not be portable between implementations.

The height attribute specifies the vertical extent of the bounding box of the mpadded element above its baseline. Increasing the height increases the space between the baseline of the mpadded element and the content above it, and introduces padding above the rendering of the child content. Decreasing the height reduces the space between the baseline of the mpadded element and the content above it, and removes space above the rendering of the child content. Decreasing the height may cause content above the mpadded element to overlap the rendering of the child content, and should generally be avoided.

The depth attribute specifies the vertical extent of the bounding box of the mpadded element below its baseline. Increasing the depth increases the space between the baseline of the mpadded element and the content below it, and introduces padding below the rendering of the child content. Decreasing the depth reduces the space between the baseline of the mpadded element and the content below it, and removes space below the rendering of the child content. Decreasing the depth may cause content below the mpadded element to overlap the rendering of the child content, and should generally be avoided.

The width attribute specifies the horizontal distance between the positioning point of the mpadded element and the positioning point of the following content. Increasing the width increases the space between the positioning point of the mpadded element and the content that follows it, and introduces padding after the rendering of the child content. Decreasing the width reduces the space between the positioning point of the mpadded element and the content that follows it, and removes space after the rendering of the child content. Setting the width to zero causes following content to be positioned at the positioning point of the mpadded element. Decreasing the width should generally be avoided, as it may cause overprinting of the following content.

The lspace attribute ("leading" space; see 3.1.5.1 Overall Directionality of Mathematics Formulas) specifies the horizontal location of the positioning point of the child content with respect to the positioning point of the mpadded element. By default they coincide, and therefore absolute values for lspace have the same effect as relative values. Positive values for the lspace attribute increase the space between the preceding content and the child content, and introduce padding before the rendering of the child content. Negative values for the lspace attributes reduce the space between the preceding content and the child content, and may cause overprinting of the preceding content, and should generally be avoided. Note that the lspace attribute does not affect the width of the mpadded element, and so the lspace attribute will also affect the space between the child content and following content, and may cause overprinting of the following content, unless the width is adjusted accordingly.

The voffset attribute specifies the vertical location of the positioning point of the child content with respect to the positioning point of the mpadded element. Positive values for the voffset attribute raise the rendering of the child content above the baseline. Negative values for the voffset attribute lower the rendering of the child content below the baseline. In either case, the voffset attribute may cause overprinting of neighboring content, which should generally be avoided. Note that the voffset attribute does not affect the height or depth of the mpadded element, and so the voffset attribute will also affect the space between the child content and neighboring content, and may cause overprinting of the neighboring content, unless the height or depth is adjusted accordingly.

MathML renderers should ensure that, except for the effects of the attributes, the relative spacing between the contents of the mpadded element and surrounding MathML elements would not be modified by replacing an mpadded element with an mrow element with the same content, even if linebreaking occurs within the mpadded element. MathML does not define how non-default attribute values of an mpadded element interact with the linebreaking algorithm.

The mphantom element renders invisibly, but with the same size and other dimensions, including baseline position, that its contents would have if they were rendered normally. mphantom can be used to align parts of an expression by invisibly duplicating sub-expressions.

The mphantom element accepts a single argument possibly being an inferred mrow of multiple children; see 3.1.3 Required Arguments.

Note that it is possible to wrap both an mphantom and an mpadded element around one MathML expression, as in <mphantom><mpadded attribute-settings> ... </mpadded></mphantom>, to change its size and make it invisible at the same time.

MathML renderers should ensure that the relative spacing between the contents of an mphantom element and the surrounding MathML elements is the same as it would be if the mphantom element were replaced by an mrow element with the same content. This holds even if linebreaking occurs within the mphantom element.

For the above reason, mphantom is not considered space-like (3.2.7 Space <mspace/>) unless its content is space-like, since the suggested rendering rules for operators are affected by whether nearby elements are space-like. Even so, the warning about the legal grouping of space-like elements may apply to uses of mphantom.

mphantom elements accept the attributes listed in 3.1.9 Mathematics attributes common to presentation elements (the mathcolor has no effect).

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

For example, <mfenced> <mi>x</mi> </mfenced> renders as (x) and is equivalent to

<mrow> <mo> ( </mo> <mi>x</mi> <mo> ) </mo> </mrow>

and <mfenced> <mi>x</mi> <mi>y</mi> </mfenced> renders as (x, y) and is equivalent to

<mrow>
  <mo> ( </mo>
  <mrow> <mi>x</mi> <mo>,</mo> <mi>y</mi> </mrow>
  <mo> ) </mo>
</mrow>

Individual fences or separators are represented using mo elements, as described in 3.2.5 Operator, Fence, Separator or Accent <mo>. Thus, any mfenced element is completely equivalent to an expanded form described below. While mfenced might be more convenient for authors or authoring software, only the expanded form is supported in [MathML-Core]. A renderer that supports this recommendation is required to render either of these forms in exactly the same way.

In general, an mfenced element can contain zero or more arguments, and will enclose them between fences in an mrow; if there is more than one argument, it will insert separators between adjacent arguments, using an additional nested mrow around the arguments and separators for proper grouping (3.3.1 Horizontally Group Sub-Expressions <mrow>). The general expanded form is shown below. The fences and separators will be parentheses and comma by default, but can be changed using attributes, as shown in the following table.

mfenced elements accept the attributes listed below in addition to those specified in 3.1.9 Mathematics attributes common to presentation elements. The delimiters and separators should be drawn using the color specified by mathcolor.

A generic mfenced element, with all attributes explicit, looks as follows:

<mfenced open="opening-fence"
         close="closing-fence"
         separators="sep#1 sep#2 ... sep#(n-1)" >
  arg#1
  ...
  arg#n
</mfenced>

In an RTL directionality context, since the initial text direction is RTL, characters in the open and close attributes that have a mirroring counterpart will be rendered in that mirrored form. In particular, the default values will render correctly as a parenthesized sequence in both LTR and RTL contexts.

The general mfenced element shown above is equivalent to the following expanded form:

<mrow>
  <mo fence="true"> opening-fence </mo>
  <mrow>
    arg#1
    <mo separator="true"> sep#1 </mo>
    ...
    <mo separator="true"> sep#(n-1) </mo>
    arg#n
  </mrow>
  <mo fence="true"> closing-fence </mo>
</mrow>

Each argument except the last is followed by a separator. The inner mrow is added for proper grouping, as described in 3.3.1 Horizontally Group Sub-Expressions <mrow>.

When there is only one argument, the above form has no separators; since <mrow> arg#1 </mrow> is equivalent to arg#1 (as described in 3.3.1 Horizontally Group Sub-Expressions <mrow>), this case is also equivalent to:

<mrow>
  <mo fence="true"> opening-fence </mo>
    arg#1
  <mo fence="true"> closing-fence </mo>
</mrow>

If there are too many separator characters, the extra ones are ignored. If separator characters are given, but there are too few, the last one is repeated as necessary. Thus, the default value of separators="," is equivalent to separators=",,", separators=",,,", etc. If there are no separator characters provided but some are needed, for example if separators=" " or "" and there is more than one argument, then no separator elements are inserted at all — that is, the elements <mo separator="true"> sep#i </mo> are left out entirely. Note that this is different from inserting separators consisting of mo elements with empty content.

Finally, for the case with no arguments, i.e.

<mfenced open="opening-fence"
 close="closing-fence"
 separators="anything" >
</mfenced>

the equivalent expanded form is defined to include just the fences within an mrow:

<mrow>
  <mo fence="true"> opening-fence </mo>
  <mo fence="true"> closing-fence </mo>
</mrow>

Note that not all fenced expressions can be encoded by an mfenced element. Such exceptional expressions include those with an embellished separator or fence or one enclosed in an mstyle element, a missing or extra separator or fence, or a separator with multiple content characters. In these cases, it is necessary to encode the expression using an appropriately modified version of an expanded form. As discussed above, it is always permissible to use the expanded form directly, even when it is not necessary. In particular, authors cannot be guaranteed that MathML preprocessors won't replace occurrences of mfenced with equivalent expanded forms.

Note that the equivalent expanded forms shown above include attributes on the mo elements that identify them as fences or separators. Since the most common choices of fences and separators already occur in the operator dictionary with those attributes, authors would not normally need to specify those attributes explicitly when using the expanded form directly. Also, the rules for the default form attribute (3.2.5 Operator, Fence, Separator or Accent <mo>) cause the opening and closing fences to be effectively given the values form="prefix" and form="postfix" respectively, and the separators to be given the value form="infix".

Note that it would be incorrect to use mfenced with a separator of, for instance, +, as an abbreviation for an expression using + as an ordinary operator, e.g.

<mrow>
  <mi>x</mi> <mo>+</mo> <mi>y</mi> <mo>+</mo> <mi>z</mi>
</mrow>

This is because the + signs would be treated as separators, not infix operators. That is, it would render as if they were marked up as <mo separator="true">+</mo>, which might therefore render inappropriately.

The menclose element renders its content inside the enclosing notation specified by its notation attribute. menclose accepts a single argument possibly being an inferred mrow of multiple children; see 3.1.3 Required Arguments.

menclose elements accept the attributes listed below in addition to those specified in 3.1.9 Mathematics attributes common to presentation elements. The notations should be drawn using the color specified by mathcolor.

The values allowed for notation are open-ended. Conforming renderers may ignore any value they do not handle, although renderers are encouraged to render as many of the values listed below as possible.

Any number of values can be given for notation separated by whitespace; all of those given and understood by a MathML renderer should be rendered. Each should be rendered as if the others were not present; they should not nest one inside of the other. For example, notation="circle box" should result in circle and a box around the contents of menclose; the circle and box may overlap. This is shown in the first example below. Of the predefined notations, only phasorangle is affected by the directionality (see 3.1.5.1 Overall Directionality of Mathematics Formulas):

When notation is specified as actuarial, the contents are drawn enclosed by an actuarial symbol. A similar result can be achieved with the value top right.

The values box, roundedbox, and circle should enclose the contents as indicated by the values. The amount of distance between the box, roundedbox, or circle, and the contents are not specified by MathML, and left to the renderer. In practice, paddings on each side of 0.4em in the horizontal direction and .5ex in the vertical direction seem to work well.

The values left, right, top and bottom should result in lines drawn on those sides of the contents. The values northeastarrow, updiagonalstrike, downdiagonalstrike, verticalstrike and horizontalstrike should result in the indicated strikeout lines being superimposed over the content of the menclose, e.g. a strikeout that extends from the lower left corner to the upper right corner of the menclose element for updiagonalstrike, etc.

The value northeastarrow is a recommended value to implement because it can be used to implement TeX's \cancelto command. If a renderer implements other arrows for menclose, it is recommended that the arrow names are chosen from the following full set of names for consistency and standardization among renderers:

• uparrow

• rightarrow

• downarrow

• leftarrow

• northwestarrow

• southwestarrow

• southeastarrow

• northeastarrow

• updownarrow

• leftrightarrow

• northwestsoutheastarrow

• northeastsouthwestarrow

The value madruwb should generate an enclosure representing an Arabic factorial (‘madruwb’ is the transliteration of the Arabic مضروب for factorial). This is shown in the third example below.

The baseline of an menclose element is the baseline of its child (which might be an implied mrow).

The msub element attaches a subscript to a base using the syntax

<msub> base subscript </msub>

It increments scriptlevel by 1, and sets displaystyle to false, within subscript, but leaves both attributes unchanged within base. (See 3.1.6 Displaystyle and Scriptlevel.)

msub elements accept the attributes listed below in addition to those specified in 3.1.9 Mathematics attributes common to presentation elements.

The msup element attaches a superscript to a base using the syntax

<msup> base superscript </msup>

It increments scriptlevel by 1, and sets displaystyle to false, within superscript, but leaves both attributes unchanged within base. (See 3.1.6 Displaystyle and Scriptlevel.)

msup elements accept the attributes listed below in addition to those specified in 3.1.9 Mathematics attributes common to presentation elements.

The msubsup element is used to attach both a subscript and superscript to a base expression.

<msubsup> base subscript superscript </msubsup>

It increments scriptlevel by 1, and sets displaystyle to false, within subscript and superscript, but leaves both attributes unchanged within base. (See 3.1.6 Displaystyle and Scriptlevel.)

Note that both scripts are positioned tight against the base as shown here $x_1^2$ versus the staggered positioning of nested scripts as shown here ${x_1}^2$; the latter can be achieved by nesting an msub inside an msup.

msubsup elements accept the attributes listed below in addition to those specified in 3.1.9 Mathematics attributes common to presentation elements.

The munder element attaches an accent or limit placed under a base using the syntax

<munder> base underscript </munder>

It always sets displaystyle to false within the underscript, but increments scriptlevel by 1 only when accentunder is false. Within base, it always leaves both attributes unchanged. (See 3.1.6 Displaystyle and Scriptlevel.)

If base is an operator with movablelimits=true (or an embellished operator whose mo element core has movablelimits=true), and displaystyle=false, then underscript is drawn in a subscript position. In this case, the accentunder attribute is ignored. This is often used for limits on symbols such as U+2211 (entity sum).

munder elements accept the attributes listed below in addition to those specified in 3.1.9 Mathematics attributes common to presentation elements.