2.1.5.1 Syntax notation used in the MathML specification

To describe the MathML-specific syntax of attribute values, the following conventions and notations are used for most attributes in the present document. We use below the notation beginning with U+ that is recommended by Unicode for referring to Unicode characters [see [Unicode], page xxviii].

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, Appendix 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).

2.1.5.2 Length Valued Attributes

Most presentation elements have attributes that accept values representing lengths to be used for size, spacing or similar properties. The syntax of a length is specified as

There should be no space between the number and the unit of a length.

The possible units and namedspaces, along with their interpretations, are shown below. Note that although the units and their meanings are taken from CSS, the syntax of lengths is not identical. A few MathML elements have length attributes that accept additional keywords; these are termed pseudo-units and specified in the description of those particular elements; see, for instance, Section 3.3.6 Adjust Space Around Content <mpadded>.

A trailing "%" represents a percent of a reference value; unless otherwise stated, the reference value is the default value. The default value, or how it is obtained, is listed in the table of attributes for each element along with the reference value when it differs from the default. (See also Section 2.1.5.4 Default values of attributes.) A number without a unit is intepreted as a multiple of the reference value. This form is primarily for backward compatibility and should be avoided, prefering explicit units for clarity.

In some cases, the range of acceptable values for a particular attribute may be restricted; implementations are free to round up or down to the closest allowable value.

The possible units in MathML are:

Some additional aspects of units are discussed further below, in Section 2.1.5.2.1 Additional notes about units.

The following constants, namedspaces, may also be used where a length is needed; they are typically used for spacing or padding between tokens. Recommended default values for these constants are shown; the actual spacing used is implementation specific.

2.1.5.3 Color Valued Attributes

The color, or background color, of presentation elements may be specified as a color using the following syntax:

A color is specified either by "#" followed by hexadecimal values for the red, green, and blue components, with no intervening whitespace, or by an html-color-name. The color components can be either 1-digit or 2-digit, but must all have the same number of digits; the component ranges from 0 (component not present) to FF (component fully present). Note that, for example, by the digit-doubling rule specified under Colors in [CSS21] #123 is a short form for #112233.

Color values can also be specified as an html-color-name, one of the color-name keywords defined in [HTML4] ("aqua", "black", "blue", "fuchsia", "gray", "green", "lime", "maroon", "navy", "olive", "purple", "red", "silver", "teal", "white", and "yellow"). Note that the color name keywords are not case-sensitive, unlike most keywords in MathML attribute values, for compatibility with CSS and HTML.

When a color is applied to an element, it is the color in which the content of tokens is rendered. Additionally, when inherited from a surrounding element or from the environment in which the complete MathML expression is embedded, it controls the color of all other drawing due to MathML elements, including the lines or radical signs that can be drawn in rendering mfrac, mtable, or msqrt.

When used to specify a background color, the keyword "transparent" is also allowed. The recommended MathML visual rendering rules do not define the precise extent of the region whose background is affected by using the background attribute on an element, except that, when the element's content does not have negative dimensions and its drawing region is not overlapped by other drawing due to surrounding negative spacing, this region should lie behind all the drawing done to render the content of the element, but 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 background attribute is not defined by these rules.

2.1.5.4 Default values of attributes

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 Section 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 (Section 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 Section 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 Section 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 Appendix C Operator Dictionary. This is also discussed in Section 3.2.5.7.1 The operator dictionary and examples are given in Section 3.2.5.2.1 Dictionary-based attributes.

2.3.1.1 MathML Test Suite and Validator

As the previous examples show, to be useful, the concept of MathML conformance frequently involves a judgment about what parts of the language are meaningfully implemented, as opposed to parts that are merely processed in a technically correct way with respect to the definitions of conformance. This requires some mechanism for giving a quantitative statement about which parts of MathML are meaningfully implemented by a given application. To this end, the W3C Math Working Group has provided a test suite.

The test suite consists of a large number of MathML expressions categorized by markup category and dominant MathML element being tested. The existence of this test suite makes it possible, for example, to characterize quantitatively the hypothetical computer algebra interface mentioned above by saying that it is a MathML-input-conformant processor which meaningfully implements MathML content markup, including all of the expressions in the content markup section of the test suite.

Developers who choose not to implement parts of the MathML specification in a meaningful way are encouraged to itemize the parts they leave out by referring to specific categories in the test suite.

For MathML-output-conformant processors, information about currently available tools to validate MathML is maintained at the W3C MathML Validator. Developers of MathML-output-conformant processors are encouraged to verify their output using this validator.

Customers of MathML applications who wish to verify claims as to which parts of the MathML specification are implemented by an application are encouraged to use the test suites as a part of their decision processes.

2.3.1.2 Deprecated MathML 1.x and MathML 2.x Features

MathML 3.0 contains a number of features of earlier MathML which are now deprecated. The following points define what it means for a feature to be deprecated, and clarify the relation between deprecated features and current MathML conformance.

1. In order to be MathML-output-conformant, authoring tools may not generate MathML markup containing deprecated features.

2. In order to be MathML-input-conformant, rendering and reading tools must support deprecated features if they are to be in conformance with MathML 1.x or MathML 2.x. They do not have to support deprecated features to be considered in conformance with MathML 3.0. However, all tools are encouraged to support the old forms as much as possible.

3. In order to be MathML-round-trip-conformant, a processor need only preserve MathML equivalence on expressions containing no deprecated features.

2.3.1.3 MathML Extension Mechanisms and Conformance

MathML 3.0 defines three basic extension mechanisms: the mglyph element provides a way of displaying glyphs for non-Unicode characters, and glyph variants for existing Unicode characters; the maction element uses attributes from other namespaces to obtain implementation-specific parameters; and content markup makes use of the definitionURL attribute, as well as Content Dictionaries and the cd attribute, to point to external definitions of mathematical semantics.

These extension mechanisms are important because they provide a way of encoding concepts that are beyond the scope of MathML 3.0 as presently explicitly specified, which allows MathML to be used for exploring new ideas not yet susceptible to standardization. However, as new ideas take hold, they may become part of future standards. For example, an emerging character that must be represented by an mglyph element today may be assigned a Unicode code point in the future. At that time, representing the character directly by its Unicode code point would be preferable. This transition into Unicode has already taken place for hundreds of characters used for mathematics.

Because the possibility of future obsolescence is inherent in the use of extension mechanisms to facilitate the discussion of new ideas, MathML can reasonably make no conformance requirements concerning the use of extension mechanisms, even when alternative standard markup is available. For example, using an mglyph element to represent an 'x' is permitted. However, authors and implementers are strongly encouraged to use standard markup whenever possible. Similarly, maintainers of documents employing MathML 3.0 extension mechanisms are encouraged to monitor relevant standards activity (e.g., Unicode, OpenMath, etc.) and to update documents as more standardized markup becomes available.

3.1.2.1 Types of presentation elements

The presentation elements are divided into two classes. Token elements represent individual symbols, names, numbers, labels, etc. Layout schemata build expressions out of parts and can have only elements as content (except for whitespace, which they ignore). These are subdivided into General Layout, Script and Limit, Tabular Math and Elementary Math schemata. There are also a few empty elements used only in conjunction with certain layout schemata.

All individual "symbols" in a mathematical expression should be represented by MathML token elements. The primary MathML token element types are identifiers (e.g. variables or function names), numbers, and operators (including fences, such as parentheses, and separators, such as commas). There are also token elements used to represent text or whitespace that has more aesthetic than mathematical significance and other elements representing "string literals" for compatibility with computer algebra systems. Note that although a token element represents a single meaningful "symbol" (name, number, label, mathematical symbol, etc.), such symbols may be comprised of more than one character. For example sin and 24 are represented by the single tokens <mi>sin</mi> and <mn>24</mn> respectively.

In traditional mathematical notation, expressions are recursively constructed out of smaller expressions, and ultimately out of single symbols, with the parts grouped and positioned using one of a small set of notational structures, which can be thought of as "expression constructors". In MathML, expressions are constructed in the same way, with the layout schemata playing the role of the expression constructors. The layout schemata specify the way in which sub-expressions are built into larger expressions. The terminology derives from the fact that each layout schema corresponds to a different way of "laying out" its sub-expressions to form a larger expression in traditional mathematical typesetting.

3.1.2.2 Terminology for other classes of elements and their relationships

The terminology used in this chapter for special classes of elements, and for relationships between elements, is as follows: The presentation elements are the MathML elements defined in this chapter. These elements are listed in Section 3.1.9 Summary of Presentation Elements. The content elements are the MathML elements defined in Chapter 4 Content Markup.

A MathML expression is a single instance of any of the presentation elements with the exception of the empty elements none or mprescripts, or is a single instance of any of the content elements which are allowed as content of presentation elements (described in Section 5.3.2 Content Markup in Presentation Markup). A sub-expression of an expression E is any MathML expression that is part of the content of E, whether directly or indirectly, i.e. whether it is a "child" of E or not.

Since layout schemata attach special meaning to the number and/or positions of their children, a child of a layout schema is also called an argument of that element. As a consequence of the above definitions, the content of a layout schema consists exactly of a sequence of zero or more elements that are its arguments.

3.1.3.1 Inferred <mrow>s

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,

<mtd>
</mtd>

is treated as if it were

<mtd>
  <mrow>
  </mrow>
</mtd>

and

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

3.1.3.2 Table of argument requirements

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.

3.1.5.1 Overall Directionality of Mathematics Formulas

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 Section 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 behaviour 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; ie. 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 individual subformula by using the dir attribute on mrow or mstyle elements. When not specified, all elements inherit the directionality of their container.

3.1.5.2 Bidirectional Layout in Token Elements

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 used, such as RTL Arabic and LTR numbers, the Unicode bidirectional algorithm [Bidi] is 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 (Section 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 an 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.

Please 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. These are strong left-to-right.

3.1.7.1 Control of Linebreaks

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 Section 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 render 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 a 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 a 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 Section 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 Section 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 Section 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 Section 2.2.1 Attributes.)

3.1.7.2 Automatic Linebreaking Algorithm (Informative)

One method of linebreaking that works reasonably well is sometimes referred to as a "best-fit" algorithm. It works by computing a "penalty" for each potential break point on a line. The break point with the smallest penalty is chosen and the algorithm then works on the next line. Three useful factors in a penalty calculation are:

1. How much of the line width (after subtracting of the indent) is unused? The more unused, the higher the penalty.

2. How deeply nested is the breakpoint in the expression tree? The expression tree's depth is roughly similar to the nesting depth of mrows. The more deeply nested the break point, the higher the penalty.

3. Does a linebreak here make layout of the next line difficult? If the next line is not the last line and if the indentingstyle uses information about the linebreak point to determine how much to indent, then the amount of room left for linebreaking on the next line must be considered; i.e., linebreaks that leave very little room to draw the next line result in a higher penalty.

4. Whether "linebreak" has been specified: "nobreak" effectively sets the penalty to infinity, "badbreak" increases the penalty "goodbreak" decreases the penalty, and "newline" effectively sets the penalty to 0.

This algorithm takes time proportional to the number of token elements times the number of lines.

3.1.7.3 Linebreaking Algorithm for Inline Expressions (Informative)

A common method for breaking inline expressions that are too long for the space remaining on the current line is to pick an appropriate break point for the expression and place the expression up to that point on the current line and place the remainder of the expression on the following line. This can be done by:

1. Querying the text processing engine for the minimum and maximum amount of space available on the current line.

2. Using a variation of the automatic linebreaking algorithm given above), and/or using hints provided by linebreak attributes on mo or mspace elements, to choose a line break. The goal is that the first part of the formula fits "comfortably" on the current line while breaking at a point that results in keeping related parts of an expression on the same line.

3. The remainder of the formula begins on the next line, positioned both vertically and horizontally according to the paragraph flow; MathML's indentation attributes are ignored in this algorithm.

4. If the remainder does not fit on a line, steps 1 - 3 are repeated for the second and subsequent lines. Unlike the for the first line, some part of the expression must be placed these lines so that the algorithm terminates.

3.1.8.1 Warning: non-portability of "tweaking"

For particular expressions, authors may be tempted to use the mpadded, mspace, mphantom, and mtext elements to improve ("tweak") the spacing generated by a specific renderer.

Without explicit spacing rules, various MathML renders may use different spacing algorithms. Consequently, different MathML renderers may position symbols in different locations relative to each other. Say that renderer B, for example, provides improved spacing for a particular expression over renderer A. Authors are strongly warned that "tweaking" the layout for renderer A may produce very poor results in renderer B, very likely worse than without any explicit adjustment at all.

Even when a specific choice of renderer can be assumed, its spacing rules may be improved in successive versions, so that the effect of tweaking in a given MathML document may grow worse with time. Also, when style sheet mechanisms are extended to MathML, even one version of a renderer may use different spacing rules for users with different style sheets.

Therefore, it is suggested that MathML markup never use mpadded or mspace elements to tweak the rendering of specific expressions, unless the MathML is generated solely to be viewed using one specific version of one MathML renderer, using one specific style sheet (if style sheets are available in that renderer).

In cases where the temptation to improve spacing proves too strong, careful use of mpadded, mphantom, or the alignment elements (Section 3.5.5 Alignment Markers <maligngroup/>, <malignmark/>) may give more portable results than the direct insertion of extra space using mspace or mtext. Advice given to the implementers of MathML renderers might be still more productive, in the long run.

3.1.8.2 Warning: spacing should not be used to convey meaning

MathML elements that permit "negative spacing", namely mspace, mpadded, and mo, could in theory be used to simulate new notations or "overstruck" characters by the visual overlap of the renderings of more than one MathML sub-expression.

This practice is strongly discouraged in all situations, for the following reasons:

• it will give different results in different MathML renderers (so the warning about "tweaking" applies), especially if attempts are made to render glyphs outside the bounding box of the MathML expression;

• it is likely to appear much worse than a more standard construct supported by good renderers;

• such expressions are almost certain to be uninterpretable by audio renderers, computer algebra systems, text searches for standard symbols, or other processors of MathML input.

More generally, any construct that uses spacing to convey mathematical meaning, rather than simply as an aid to viewing expression structure, is discouraged. That is, the constructs that are discouraged are those that would be interpreted differently by a human viewer of rendered MathML if all explicit spacing was removed.

Consider using the mglyph element for cases such as this. If such spacing constructs are used in spite of this warning, they should be enclosed in a semantics element that also provides an additional MathML expression that can be interpreted in a standard way. See Section 5.1 Annotation Framework for further discussion.

The above warning also applies to most uses of rendering attributes to alter the meaning conveyed by an expression, with the exception of attributes on mi (such as mathvariant) used to distinguish one variable from another.

3.1.9.1 Token Elements

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

3.1.9.2 General Layout Schemata

3.1.9.3 Script and Limit Schemata

3.1.9.4 Tables and Matrices

3.1.9.5 Elementary Math Layout

3.1.9.6 Enlivening Expressions

3.2.1.1 Alphanumeric symbol characters

A large class of mathematical symbols are single letter identifiers typically used as variable names in formulas. Different font variants of a letter are treated as separate symbols. For example, a Fraktur 'g' might denote a Lie algebra, while a Roman 'g' denotes the corresponding Lie group. These letter-like symbols are traditionally typeset differently than the same characters appearing in text, using different spacing and ligature conventions. These characters must also be treated specially by style mechanisms, since arbitrary style transformations can change meaning in an expression.

For these reasons, Unicode contains more than nine hundred Math Alphanumeric Symbol characters corresponding to letter-like symbols. These characters are in the Secondary Multilingual Plane (SMP). See [Entities] for more information. As valid Unicode data, these characters are permitted in MathML and, as tools and fonts for them become widely available, we anticipate they will be the predominant way of denoting letter-like symbols.

MathML also provides an alternative encoding for these characters using only Basic Multilingual Plane (BMP) characters together with markup. MathML defines a correspondence between token elements with certain combinations of BMP character data and the mathvariant attribute and tokens containing SMP Math Alphanumeric Symbol characters. Processing applications that accept SMP characters are required to treat the corresponding BMP and attribute combinations identically. This is particularly important for applications that support searching and/or equality testing.

The mathvariant attribute is described in more detail in Section 3.2.2 Mathematics style attributes common to token elements, and a complete technical description of the corresponding characters is given in Section 7.5 Mathematical Alphanumeric Symbols.

3.2.1.2 Using images to represent symbols <mglyph/>

<mrow>
  <mi><mglyph src="my-braid-23" alt="2 3 braid"/></mi>
  <mo>+</mo>
  <mi><mglyph src="my-braid-132" alt="1 3 2 braid"/></mi>
  <mo>=</mo>
  <mi><mglyph src="my-braid-13" alt="1 3 braid"/></mi>
</mrow>

3.2.2.1 Deprecated style attributes on token elements

The MathML 1.01 style attributes listed below are deprecated in MathML 2 and 3. These attributes were aligned to CSS but, in rendering environments that support CSS, it is preferable to use CSS directly to control the rendering properties corresponding to these attributes, rather than the attributes themselves. However as explained above, direct manipulation of these rendering properties by whatever means should usually be avoided. As a general rule, whenever there is a conflict between these deprecated attributes and the corresponding attributes (Section 3.2.2 Mathematics style attributes common to token elements), the former attributes should be ignored.

The deprecated attributes are:

3.2.2.2 Embedding HTML in MathML

MathML can be combined with other formats as described in Section 6.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 Section 3.2.6.4 Mixing text and mathematics). The directionality, font size, and other font attributes should inherit from those that would be used for characters of the containing leaf element (see Section 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>

3.2.3.1 Description

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 Section 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) can be represented using an mi element, as shown in an example in Section 3.2.6.4 Mixing text and mathematics.

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 Chapter 4 Content Markup.

3.2.3.2 Attributes

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

Note that the deprecated fontstyle attribute defaults in the same way as mathvariant, depending on the content.

Note that for purposes of determining equivalences of Math Alphanumeric Symbol characters (See Section 7.5 Mathematical Alphanumeric Symbols and Section 3.2.1.1 Alphanumeric symbol characters) the value of the mathvariant attribute should be resolved first, including the special defaulting behavior described above.

3.2.3.3 Examples

<mi> x </mi>
<mi> D </mi>
<mi> sin </mi>
<mi mathvariant='script'> L </mi>
<mi></mi>

An mi element with no content is allowed; <mi></mi> might, for example, be used by an "expression editor" to represent a location in a MathML expression which requires a "term" (according to conventional syntax for mathematics) but does not yet contain one.

Identifiers include function names such as "sin". Expressions such as "sin x" should be written using the character U+2061 (which also has the entity names ⁡ and ⁡) as shown below; see also the discussion of invisible operators in Section 3.2.5 Operator, Fence, Separator or Accent <mo>.

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

Miscellaneous text that should be treated as a "term" can also be represented by an mi element, as in:

<mrow>
  <mn> 1 </mn>
  <mo> + </mo>
  <mi> &#x2026;<!--HORIZONTAL ELLIPSIS--> </mi>
  <mo> + </mo>
  <mi> n </mi>
</mrow>

When an mi is used in such exceptional situations, explicitly setting the mathvariant attribute may give better results than the default behavior of some renderers.

The names of symbolic constants should be represented as mi elements:

<mi> &#x3C0;<!--GREEK SMALL LETTER PI--> </mi>
<mi> &#x2148;<!--DOUBLE-STRUCK ITALIC SMALL I--> </mi>
<mi> &#x2147;<!--DOUBLE-STRUCK ITALIC SMALL E--> </mi>

3.2.4.1 Description

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 Section 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 Chapter 4 Content Markup.

3.2.4.2 Attributes

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

3.2.4.3 Examples

<mn> 2 </mn>
<mn> 0.123 </mn>
<mn> 1,000,000 </mn>
<mn> 2.1e10 </mn>
<mn> 0xFFEF </mn>
<mn> MCMLXIX </mn>
<mn> twenty one </mn>

3.2.4.4 Numbers that should not be written using <mn> alone

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

<mrow>
  <mn> 2 </mn>
  <mo> + </mo>
  <mrow>
    <mn> 3 </mn>
    <mo> &#x2062;<!--INVISIBLE TIMES--> </mo>
    <mi> &#x2148;<!--DOUBLE-STRUCK ITALIC SMALL I--> </mi>
  </mrow>
</mrow>
<mfrac> <mn> 1 </mn> <mn> 2 </mn> </mfrac>
<mi> &#x3C0;<!--GREEK SMALL LETTER PI--> </mi>
<mi> &#x2147;<!--DOUBLE-STRUCK ITALIC SMALL E--> </mi>

3.2.5.1 Description

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 Section 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> &le; </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> &le; </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 <=.

All operators, in the general sense used here, are subject to essentially the same rendering attributes and rules. Subtle distinctions in the rendering of these classes of symbols, when they exist, are supported using the Boolean attributes fence, separator and accent, which can be used to distinguish these cases.

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 values for fence, separator 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 Section 3.2.6 Text <mtext>. See also Chapter 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 Section 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 the a linebreak is made at that operator.

3.2.5.2 Attributes

mo elements accept the attributes listed in Section 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 the Section 3.2.5.7.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.

3.2.5.3 Examples with ordinary operators

<mo> + </mo>                    

<mo> &lt; </mo>                 

<mo> &#x2264;<!--LESS-THAN OR EQUAL TO--> </mo> 

<mo> &lt;= </mo>                

<mo> ++ </mo>                   

<mo> &#x2211;<!--N-ARY SUMMATION--> </mo> 

<mo> .NOT. </mo>                

<mo> and </mo>                  

<mo> &#x2062;<!--INVISIBLE TIMES--> </mo> 

<mo mathvariant='bold'> + </mo> 

3.2.5.4 Examples with fences and separators

Note that the mo elements in these examples don't need explicit fence or separator attributes, since these can be found using the operator dictionary as described below. Some of these examples could also be encoded using the mfenced element described in Section 3.3.8 Expression Inside Pair of Fences <mfenced>.

(a+b)

<mrow>
  <mo> ( </mo>
  <mrow>
    <mi> a </mi>
    <mo> + </mo>
    <mi> b </mi>
  </mrow>
  <mo> ) </mo>
</mrow>

[0,1)

<mrow>
  <mo> [ </mo>
  <mrow>
    <mn> 0 </mn>
    <mo> , </mo>
    <mn> 1 </mn>
  </mrow>
  <mo> ) </mo>
</mrow>

f(x,y)

<mrow>
  <mi> f </mi>
  <mo> &#x2061;<!--FUNCTION APPLICATION--> </mo>
  <mrow>
    <mo> ( </mo>
    <mrow>
      <mi> x </mi>
      <mo> , </mo>
      <mi> y </mi>
    </mrow>
    <mo> ) </mo>
  </mrow>
</mrow>

3.2.5.5 Invisible operators

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

The MathML representations of the examples in the above table are:

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

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

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

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

<mrow>
  <mn> 2 </mn>
  <mo> &#x2064;<!--INVISIBLE PLUS--> </mo>
  <mfrac>
    <mn> 3 </mn>
    <mn> 4 </mn>
  </mfrac>
</mrow>

The reasons for using specific mo elements for invisible operators include:

• such operators should often have specific effects on visual rendering (particularly spacing and linebreaking rules) that are not the same as either the lack of any operator, or spacing represented by mspace or mtext elements;

• these operators should often have specific audio renderings different than that of the lack of any operator;

• automatic semantic interpretation of MathML presentation elements is made easier by the explicit specification of such operators.

For example, an audio renderer might render f(x) (represented as in the above examples) by speaking "f of x", but use the word "times" in its rendering of xy. Although its rendering must still be different depending on the structure of neighboring elements (sometimes leaving out "of" or "times" entirely), its task is made much easier by the use of a different mo element for each invisible operator.

3.2.5.6 Names for other special operators

MathML also includes ⅆ (U+2146) for use in an mo element representing the differential operator symbol usually denoted by "d". The reasons for explicitly using this special character are similar to those for using the special characters for invisible operators described in the preceding section.

3.2.5.7 Detailed rendering rules for <mo> elements

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. Furthermore, no attempt is made to specify the rendering completely; rather, enough information is given to make the intended effect of the various rendering attributes as clear as possible.

<mfrac>
  <mo> &#x2146;<!--DOUBLE-STRUCK ITALIC SMALL D--> </mo>
  <mrow>
    <mo> &#x2146;<!--DOUBLE-STRUCK ITALIC SMALL D--> </mo>
    <mi> x </mi>
  </mrow>
</mfrac>

3.2.5.8 Stretching of operators, fences and accents

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> &#x5F;<!--LOW LINE--> </mo>
  </munder>
  <mfrac>
    <mi> a </mi>
    <mi> b </mi>
  </mfrac>
  <mover>
    <mo> ) </mo>
    <mo> &#x203E;<!--OVERLINE--> </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>
    <mi> a </mi> <mi> b </mi>
  </mfrac>
  <mo maxsize="100%"> ) </mo>
</mrow>

<mrow>
  <mi> x </mi>
  <munder>
    <mo> &#x2192;<!--RIGHTWARDS ARROW--> </mo>
    <mtext> maps to </mtext>
  </munder>
  <mi> y </mi>
</mrow>

3.2.5.9 Examples of Linebreaking

The following example demonstrates forced linebreaks and forced alignment:

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

  <mo id='eq1-equals'>=</mo>
  <mrow>
   <msup>
    <mrow> <mo>(</mo> <mrow> <mi>x</mi> <mo>+</mo> <mn>1</mn> </mrow> <mo>)</mo> </mrow>
    <mn>4</mn>
   </msup>
   <mo linebreak='newline' linebreakstyle='before'
                     indentalign='id' indenttarget='eq1-equals'>=</mo>
   <mrow>
    <msup> <mi>x</mi> <mn>4</mn> </msup>
    <mo id='eq1-plus'>+</mo>
    <mrow>  <mn>4</mn> <mo>&#x2062;<!--INVISIBLE TIMES--></mo> <msup> <mi>x</mi> <mn>3</mn> </msup>  </mrow>
    <mo>+</mo>
    <mrow>  <mn>6</mn> <mo>&#x2062;<!--INVISIBLE TIMES--></mo> <msup> <mi>x</mi> <mn>2</mn> </msup>  </mrow>

    <mo linebreak='newline' linebreakstyle='before'
                      indentalignlast='id' indenttarget='eq1-plus'>+</mo>
    <mrow>  <mn>4</mn> <mo>&#x2062;<!--INVISIBLE TIMES--></mo> <mi>x</mi>  </mrow>
    <mo>+</mo>
    <mn>1</mn>
   </mrow>
  </mrow>
 </mrow>

This displays as

Note that because indentalignlast defaults to "indentalign", in the above example indentalign could have been used in place of indentalignlast. Also, the specifying linebreakstyle='before' is not needed because that is the default value.

3.2.6.1 Description

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 some text with a clearly defined notational role might be more appropriately marked up using mi or mo; this is discussed further below.

An mtext element can be used to 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. This is not related to any whitespace in the source MathML consisting of blanks, newlines, tabs, or carriage returns; whitespace present directly in the source is trimmed and collapsed, as described in Section 2.1.7 Collapsing Whitespace in Input. Whitespace that is intended to be rendered as part of an element's content must be represented by entity references or mspace elements (unless it consists only of single blanks between non-whitespace characters).

3.2.6.2 Attributes

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

See also the warnings about the legal grouping of "space-like elements" in Section 3.2.7 Space <mspace/>, and about the use of such elements for "tweaking" in Section 3.1.8 Warning about fine-tuning of presentation.

3.2.6.3 Examples

<mtext> Theorem 1: </mtext>
<mtext> &#x2009;<!--THIN SPACE--> </mtext>
<mtext> &#x205F;&#x200A;<!--space of width 5/18 em-->&#x205F;&#x200A;<!--space of width 5/18 em--> </mtext>
<mtext> /* a comment */ </mtext>

3.2.6.4 Mixing text and mathematics

In some cases, text embedded in mathematics could be more appropriately represented using mo or mi elements. For example, the expression 'there exists such that f(x) <1' is equivalent to and could be represented as:

<mrow>
  <mo> there exists </mo>
  <mrow>
    <mrow>
      <mi> &#x3B4;<!--GREEK SMALL LETTER DELTA--> </mi>
      <mo> &gt; </mo>
      <mn> 0 </mn>
    </mrow>
    <mo> such that </mo>
    <mrow>
      <mrow>
        <mi> f </mi>
        <mo> &#x2061;<!--FUNCTION APPLICATION--> </mo>
        <mrow>
          <mo> ( </mo>
          <mi> x </mi>
          <mo> ) </mo>
        </mrow>
      </mrow>
      <mo> &lt; </mo>
      <mn> 1 </mn>
    </mrow>
  </mrow>
</mrow>

An example involving an mi element is: x+x²+···+xⁿ. In this example, ellipsis should be represented using an mi element, since it takes the place of a term in the sum; (see Section 3.2.3 Identifier <mi>).

On the other hand, expository text within MathML is best represented with an mtext element. An example of this is:

Theorem 1: if x > 1, then x² > x.

However, when MathML is embedded in HTML, or another document markup language, the example is probably best rendered with only the two inequalities represented as MathML at all, letting the text be part of the surrounding HTML.

Another factor to consider in deciding how to mark up text is the effect on rendering. Text enclosed in an mo element is unlikely to be found in a renderer's operator dictionary, so it will be rendered with the format and spacing appropriate for an "unrecognized operator", which may or may not be better than the format and spacing for "text" obtained by using an mtext element. An ellipsis entity in an mi element is apt to be spaced more appropriately for taking the place of a term within a series than if it appeared in an mtext element.

3.2.7.1 Description

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 Section 3.1.8 Warning about fine-tuning of presentation. See also the other elements that can render as whitespace, namely mtext, mphantom, and maligngroup.

3.2.7.2 Attributes

In addition to the attributes listed below, mspace elements accept the attributes described in Section 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 Section 2.1.5.2 Length Valued Attributes). mspace also accepts the indentation attributes described in Section 3.2.5.2.3 Indentation attributes.

Linebreaking was originally specified on mspace in MathML2, but controlling linebreaking on mo is to be preferred starting with MathML 3. MathML 3 adds new linebreaking attributes only to mo, not mspace. However, because a linebreak can be specified on mspace, control over the indentation that follows that break can be specified using the attributes listed in Section 3.2.5.2.3 Indentation attributes.

The value "indentingnewline" was defined in MathML2 for mspace; it is now deprecated. Its meaning is the same as newline, which is compatible with its earlier use when no other linebreaking attributes are specified. Note that linebreak values on adjacent mo and mspace elements do not interact; a "nobreak" on an mspace will not, in itself, inhibit a break on an adjacent mo element.

3.2.7.3 Examples

<mspace height="3ex" depth="2ex"/>

<mrow>
  <mi>a</mi>
  <mo id="firstop">+</mo>
  <mi>b</mi>
  <mspace linebreak="newline" indentalign="id" indenttarget="firstop"/>
  <mo>+</mo>
  <mi>c</mi>
</mrow>

In the last example, mspace will cause the line to end after the "b" and the following line to be indented so that the "+" that follows will align with the "+" with id="firstop".

3.2.7.4 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. For example, space-like elements are handled specially in the suggested rendering rules for mo given in Section 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;

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

3.2.7.5 Legal grouping of space-like elements

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 Section 3.1.8 Warning about fine-tuning of presentation.

3.2.8.1 Description

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 Section 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 Section 2.1.7 Collapsing Whitespace in Input, so whitespace intended to remain in the content should be encoded as described in that section.

3.2.8.2 Attributes

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

3.3.1.1 Description

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

Several elements automatically treat their arguments as if they were contained in an mrow element. See the discussion of inferred mrows in Section 3.1.3 Required Arguments. See also mfenced (Section 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 Section 3.2.5 Operator, Fence, Separator or Accent <mo> of suggested rendering rules for mo elements assumes that all horizontal spacing between operators and their operands is added by the rendering of mo elements (or, more generally, embellished operators), not by the rendering of the mrows they are contained in.

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

3.3.1.2 Attributes

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

3.3.1.3 Proper grouping of sub-expressions using <mrow>

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.

3.3.1.4 Examples

As an example, 2x+y-z should be written as:

<mrow>
  <mrow>
    <mn> 2 </mn>
    <mo> &#x2062;<!--INVISIBLE TIMES--> </mo>
    <mi> x </mi>
  </mrow>
  <mo> + </mo>
  <mi> y </mi>
  <mo> - </mo>
  <mi> z </mi>
</mrow>

The proper encoding of (x, y) furnishes a less obvious example of nesting mrows:

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

In this case, a nested mrow is required inside the parentheses, since parentheses and commas, thought of as fence and separator "operators", do not act together on their arguments.

3.3.2.1 Description

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 Section 3.1.6 Displaystyle and Scriptlevel.)

3.3.2.2 Attributes

mfrac elements accept the attributes listed below in addition to those listed in Section 3.1.10 Mathematics style 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. These cases are shown below:

An example illustrating the bevelled form is shown below:

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

3.3.2.3 Examples

The examples shown above can be represented in MathML as:

<mrow>
   <mo> ( </mo>
   <mfrac linethickness="0">
      <mi> a </mi>
      <mi> b </mi>
   </mfrac>
   <mo> ) </mo>
</mrow>
<mfrac linethickness="200%">
   <mfrac>
      <mi> a </mi>
      <mi> b </mi>
   </mfrac>
   <mfrac>
      <mi> c </mi>
      <mi> d </mi>
   </mfrac>
</mfrac>

<mfrac>
   <mn> 1 </mn>
   <mrow>
      <msup>
         <mi> x </mi>
         <mn> 3 </mn>
       </msup>
       <mo> + </mo>
       <mfrac>
         <mi> x </mi>
         <mn> 3 </mn>
       </mfrac>
   </mrow>
</mfrac>
<mo> = </mo>
<mfrac bevelled="true">
   <mn> 1 </mn>
   <mrow>
      <msup>
         <mi> x </mi>
         <mn> 3 </mn>
       </msup>
       <mo> + </mo>
       <mfrac>
         <mi> x </mi>
         <mn> 3 </mn>
       </mfrac>
   </mrow>
</mfrac>

A more generic example is:

<mfrac>
   <mrow>
      <mn> 1 </mn>
      <mo> + </mo>
      <msqrt>
         <mn> 5 </mn>
      </msqrt>
   </mrow>
   <mn> 2 </mn>
</mfrac>

3.3.3.1 Description

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

3.3.3.2 Attributes

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

3.3.4.1 Description

The mstyle element is used to make style changes that affect the rendering of its contents. Firstly, as a presentation element, it accepts the attributes described in Section 3.1.10 Mathematics style 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 Section 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 "1", 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, columnalign, or groupalign are specified on an mstyle element, they apply only to the mtable element, and not the mtr, mlabeledtr, 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 deprecated fontfamily attribute is specified on an mstyle element, it does not apply to the mglyph element. The deprecated index attribute cannot 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 required 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 we feel it is more useful and intuitive. Since the default for mathcolor is inherited, this is no change in its behaviour.

3.3.4.2 Attributes

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.

mstyle elements accept the attributes listed in Section 3.1.10 Mathematics style 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.

3.3.4.3 Examples

The example of limiting the stretchiness of a parenthesis shown in the section on <mo>,

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

can be rewritten using mstyle as:

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

3.3.5.1 Description

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 Section 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 Section 2.3.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.

3.3.5.2 Attributes

merror elements accept the attributes listed in Section 3.1.10 Mathematics style attributes common to presentation elements.

3.3.5.3 Example

If a MathML syntax-checking preprocessor received the input

<mfraction>
   <mrow> <mn> 1 </mn> <mo> + </mo> <msqrt> <mn> 5 </mn> </msqrt> </mrow>
   <mn> 2 </mn>
</mfraction>

which contains the non-MathML element mfraction (presumably in place of the MathML element mfrac), it might generate the error message

<merror>
   <mtext> Unrecognized element: mfraction;
           arguments were:  </mtext>
   <mrow> <mn> 1 </mn> <mo> + </mo> <msqrt> <mn> 5 </mn> </msqrt> </mrow>
   <mtext>  and  </mtext>
   <mn> 2 </mn>
</merror>

Note that the preprocessor's input is not, in this case, valid MathML, but the error message it outputs is valid MathML.

3.3.6.1 Description

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 Section 3.1.8 Warning about fine-tuning of presentation 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 Section 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).

3.3.6.2 Attributes

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

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

3.3.6.3 Meanings of size and position attributes

See Appendix D Glossary for definitions of some of the typesetting terms used here.

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 Section 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 t he 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 effects of the size and position attributes are illustrated below. The following diagram illustrates the use of lspace and voffset to shift the position of child content without modifying the mpadded bounding box.

The corresponding MathML is:

<mrow>
  <mi>x</mi>
  <mpadded lspace="0.2em" voffset="0.3ex">
    <mi>y</mi>
  </mpadded>
  <mi>z</mi>
</mrow>

The next diagram illustrates the use of width, height and depth to modifying the mpadded bounding box without changing the relative position of the child content.

The corresponding MathML is:

<mrow>
  <mi>x</mi>
  <mpadded width="+90%width" height="+0.3ex" depth="+0.3ex">
    <mi>y</mi>
  </mpadded>
  <mi>z</mi>
</mrow>

The final diagram illustrates the generic use of mpadded to modify both the bounding box and relative position of child content.

The corresponding MathML is:

<mrow>
  <mi>x</mi>
  <mpadded lspace="0.3em" width="+0.6em">
    <mi>y</mi>
  </mpadded>
  <mi>z</mi>
</mrow>

3.3.7.1 Description

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 Section 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 (Section 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.

3.3.7.2 Attributes

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

3.3.7.3 Examples

There is one situation where the preceding rules for rendering an mphantom may not give the desired effect. When an mphantom is wrapped around a subsequence of the arguments of an mrow, the default determination of the form attribute for an mo element within the subsequence can change. (See the default value of the form attribute described in Section 3.2.5 Operator, Fence, Separator or Accent <mo>.) It may be necessary to add an explicit form attribute to such an mo in these cases. This is illustrated in the following example.

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

<mfrac>
  <mrow>
    <mi> x </mi>
    <mo> + </mo>
    <mi> y </mi>
    <mo> + </mo>
    <mi> z </mi>
  </mrow>
  <mrow>
    <mi> x </mi>
    <mphantom>
      <mo form="infix"> + </mo>
      <mi> y </mi>
    </mphantom>
    <mo> + </mo>
    <mi> z </mi>
  </mrow>
</mfrac>

This would render as something like

rather than as

The explicit attribute setting form="infix" on the mo element inside the mphantom sets the form attribute to what it would have been in the absence of the surrounding mphantom. This is necessary since otherwise, the + sign would be interpreted as a prefix operator, which might have slightly different spacing.

Alternatively, this problem could be avoided without any explicit attribute settings, by wrapping each of the arguments <mo>+</mo> and <mi>y</mi> in its own mphantom element, i.e.

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

3.3.8.1 Description

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 Section 3.2.5 Operator, Fence, Separator or Accent <mo>. Thus, any mfenced element is completely equivalent to an expanded form described below; either form can be used in MathML, at the convenience of an author or of a MathML-generating program. A MathML renderer 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 (Section 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.

3.3.8.2 Attributes

mfenced elements accept the attributes listed below in addition to those specified in Section 3.1.10 Mathematics style 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 Section 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 Section 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 (Section 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.

3.3.8.3 Examples

(a+b)

<mfenced>
  <mrow>
    <mi> a </mi>
    <mo> + </mo>
    <mi> b </mi>
  </mrow>
</mfenced>

Note that the above mrow is necessary so that the mfenced has just one argument. Without it, this would render incorrectly as "(a, +, b)".

[0,1)

<mfenced open="[">
  <mn> 0 </mn>
  <mn> 1 </mn>
</mfenced>

f(x,y)

<mrow>
  <mi> f </mi>
  <mo> &#x2061;<!--FUNCTION APPLICATION--> </mo>
  <mfenced>
    <mi> x </mi>
    <mi> y </mi>
  </mfenced>
</mrow>

3.3.9.1 Description

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 Section 3.1.3 Required Arguments.

3.3.9.2 Attributes

menclose elements accept the attributes listed below in addition to those specified in Section 3.1.10 Mathematics style 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 the following are affected by the directionality (see Section 3.1.5.1 Overall Directionality of Mathematics Formulas):

• "radical"

• "phasorangle"

When notation has the value "longdiv", the contents are drawn enclosed by a long division symbol. MathML 3 adds the mlongdiv element (Section 3.6.2 Long Division <mlongdiv>). This element supports notations for long division used in several countries and can be used to create a complete example of long division as shown in Section 3.6.8.3 Long Division. 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 case of notation="radical" is equivalent to the msqrt schema.

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 is 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 consistancy 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).

3.3.9.3 Examples

An example of using multiple attributes is

<menclose notation='circle box'>
  <mi> x </mi><mo> + </mo><mi> y </mi>
</menclose>

which renders with the box and circle overlapping roughly as

.

An example of using menclose for actuarial notation is

<msub>
  <mi>a</mi>
  <mrow>
    <menclose notation='actuarial'>
      <mi>n</mi>
    </menclose>
    <mo>&#x2063;<!--INVISIBLE SEPARATOR--></mo>
    <mi>i</mi>
  </mrow>
</msub>

which renders roughly as

An example of "phasorangle", which is used in circuit analysis, is:

  <mi>C</mi>
  <mrow>
    <menclose notation='phasorangle'>
      <mrow>
        <mo>&#x2212;<!--MINUS SIGN--></mo>
        <mfrac>
          <mi>&#x3C0;<!--GREEK SMALL LETTER PI--></mi>
          <mn>2</mn>
        </mfrac>
      </mrow>
    </menclose>
  </mrow>

which renders roughly as

An example of "madruwb" is:

  <menclose notation="madruwb">
    <mn>12</mn>
  </menclose>

which renders roughly as

.

3.4.1.1 Description

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 Section 3.1.6 Displaystyle and Scriptlevel.)

3.4.1.2 Attributes

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

3.4.2.1 Description

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 Section 3.1.6 Displaystyle and Scriptlevel.)

3.4.2.2 Attributes

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

3.4.3.1 Description

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 Section 3.1.6 Displaystyle and Scriptlevel.)

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

3.4.3.2 Attributes

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

3.4.3.3 Examples

The msubsup is most commonly used for adding sub/superscript pairs to identifiers as illustrated above. However, another important use is placing limits on certain large operators whose limits are traditionally displayed in the script positions even when rendered in display style. The most common of these is the integral. For example,

would be represented as

<mrow>
  <msubsup>
    <mo> &#x222B;<!--INTEGRAL--> </mo>
    <mn> 0 </mn>
    <mn> 1 </mn>
  </msubsup>
  <mrow>
    <msup>
      <mi> &#x2147;<!--DOUBLE-STRUCK ITALIC SMALL E--> </mi>
      <mi> x </mi>
    </msup>
    <mo> &#x2062;<!--INVISIBLE TIMES--> </mo>
    <mrow>
      <mo> &#x2146;<!--DOUBLE-STRUCK ITALIC SMALL D--> </mo>
      <mi> x </mi>
    </mrow>
  </mrow>
</mrow>

3.4.4.1 Description

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 Section 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 ∑.

3.4.4.2 Attributes

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

The default value of accentunder is false, unless underscript is an mo element or an embellished operator (see Section 3.2.5 Operator, Fence, Separator or Accent <mo>). If underscript is an mo element, the value of its accent attribute is used as the default value of accentunder. If underscript is an embellished operator, the accent attribute of the mo element at its core is used as the default value. As with all attributes, an explicitly given value overrides the default.

Here is an example (accent versus underscript): versus . The MathML representation for this example is shown below.

3.4.4.3 Examples

The MathML representation for the example shown above is:

<mrow>
  <munder accentunder="true">
    <mrow>
      <mi> x </mi>
      <mo> + </mo>
      <mi> y </mi>
      <mo> + </mo>
      <mi> z </mi>
    </mrow>
    <mo> &#x23DF;<!--BOTTOM CURLY BRACKET--> </mo>
  </munder>
  <mtext>&#xA0;<!--NO-BREAK SPACE-->versus&#xA0;<!--NO-BREAK SPACE--></mtext>
  <munder accentunder="false">
    <mrow>
      <mi> x </mi>
      <mo> + </mo>
      <mi> y </mi>
      <mo> + </mo>
      <mi> z </mi>
    </mrow>
    <mo> &#x23DF;<!--BOTTOM CURLY BRACKET--> </mo>
  </munder>
</mrow>

3.4.5.1 Description

The mover element attaches an accent or limit placed over a base using the syntax

<mover> base overscript </mover>

It always sets displaystyle to "false" within overscript, but increments scriptlevel by 1 only when accent is "false". Within base, it always leaves both attributes unchanged. (See Section 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 overscript is drawn in a superscript position. In this case, the accent attribute is ignored. This is often used for limits on symbols such as ∑.

3.4.5.2 Attributes

mover elements accept the attributes listed below in addition to those specified in Section 3.1.10 Mathematics style attributes common to presentation elements.

The difference between an accent versus limit is shown here: versus . These differences also apply to "mathematical accents" such as bars or braces over expressions: versus . The MathML representation for each of these examples is shown below.

The default value of accent is false, unless overscript is an mo element or an embellished operator (see Section 3.2.5 Operator, Fence, Separator or Accent <mo>). If overscript is an mo element, the value of its accent attribute is used as the default value of accent for mover. If overscript is an embellished operator, the accent attribute of the mo element at its core is used as the default value.

3.4.5.3 Examples

The MathML representation for the examples shown above is:

<mrow>
  <mover accent="true">
    <mi> x </mi>
    <mo> &#x5E;<!--CIRCUMFLEX ACCENT--> </mo>
  </mover>
  <mtext>&#xA0;<!--NO-BREAK SPACE-->versus&#xA0;<!--NO-BREAK SPACE--></mtext>
  <mover accent="false">
    <mi> x </mi>
    <mo> &#x5E;<!--CIRCUMFLEX ACCENT--> </mo>
  </mover>
</mrow>

<mrow>
  <mover accent="true">
    <mrow>
      <mi> x </mi>
      <mo> + </mo>
      <mi> y </mi>
      <mo> + </mo>
      <mi> z </mi>
    </mrow>
    <mo> &#x23DE;<!--TOP CURLY BRACKET--> </mo>
  </mover>
  <mtext>&#xA0;<!--NO-BREAK SPACE-->versus&#xA0;<!--NO-BREAK SPACE--></mtext>
  <mover accent="false">
    <mrow>
      <mi> x </mi>
      <mo> + </mo>
      <mi> y </mi>
      <mo> + </mo>
      <mi> z </mi>
    </mrow>
    <mo> &#x23DE;<!--TOP CURLY BRACKET--> </mo>
  </mover>
</mrow>

3.4.6.1 Description

The munderover element attaches accents or limits placed both over and under a base using the syntax

<munderover> base underscript overscript </munderover>

It always sets displaystyle to "false" within underscript and overscript, but increments scriptlevel by 1 only when accentunder or accent, respectively, are "false". Within base, it always leaves both attributes unchanged. (see Section 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 and overscript are drawn in a subscript and superscript position, respectively. In this case, the accentunder and accent attributes are ignored. This is often used for limits on symbols such as ∑.

3.4.6.2 Attributes

munderover elements accept the attributes listed below in addition to those specified in Section 3.1.10 Mathematics style attributes common to presentation elements.

The munderover element is used instead of separate munder and mover elements so that the underscript and overscript are vertically spaced equally in relation to the base and so that they follow the slant of the base as in the second expression shown below:

versus . The MathML representation for this example is shown below.

The difference in the vertical spacing is too small to be noticed on a low resolution display at a normal font size, but is noticeable on a higher resolution device such as a printer and when using large font sizes. In addition to the visual differences, attaching both the underscript and overscript to the same base more accurately reflects the semantics of the expression.

The defaults for accent and accentunder are computed in the same way as for munder and mover, respectively.

3.4.6.3 Examples

The MathML representation for the example shown above with the first expression made using separate munder and mover elements, and the second one using an munderover element, is:

<mrow>
  <mover>
    <munder>
      <mo> &#x222B;<!--INTEGRAL--> </mo>
      <mn> 0 </mn>
    </munder>
    <mi> &#x221E;<!--INFINITY--> </mi>
  </mover>
  <mtext>&#xA0;<!--NO-BREAK SPACE-->versus&#xA0;<!--NO-BREAK SPACE--></mtext>
  <munderover>
    <mo> &#x222B;<!--INTEGRAL--> </mo>
    <mn> 0 </mn>
    <mi> &#x221E;<!--INFINITY--> </mi>
  </munderover>
</mrow>

3.4.7.1 Description

Presubscripts and tensor notations are represented by a single element, mmultiscripts, using the syntax:

<mmultiscripts>
    base
     (subscript superscript)*
     [ <mprescripts/> (presubscript presuperscript)* ]
</mmultiscripts>

This element allows the representation of any number of vertically-aligned pairs of subscripts and superscripts, attached to one base expression. It supports both postscripts and prescripts. Missing scripts can be represented by the empty element none.

The prescripts are optional, and when present are given after the postscripts, because prescripts are relatively rare compared to tensor notation.

The argument sequence consists of the base followed by zero or more pairs of vertically-aligned subscripts and superscripts (in that order) that represent all of the postscripts. This list is optionally followed by an empty element mprescripts and a list of zero or more pairs of vertically-aligned presubscripts and presuperscripts that represent all of the prescripts. The pair lists for postscripts and prescripts are displayed in the same order as the directional context (ie. left-to-right order in LTR context). If no subscript or superscript should be rendered in a given position, then the empty element none should be used in that position.

The base, subscripts, superscripts, the optional separator element mprescripts, the presubscripts, and the presuperscripts, are all direct sub-expressions of the mmultiscripts element, i.e. they are all at the same level of the expression tree. Whether a script argument is a subscript or a superscript, or whether it is a presubscript or a presuperscript is determined by whether it occurs in an even-numbered or odd-numbered argument position, respectively, ignoring the empty element mprescripts itself when determining the position. The first argument, the base, is considered to be in position 1. The total number of arguments must be odd, if mprescripts is not given, or even, if it is.

The empty element mprescripts is only allowed as direct sub-expression of mmultiscripts.

3.4.7.2 Attributes

Same as the attributes of msubsup. See Section 3.4.3.2 Attributes.

The mmultiscripts element increments scriptlevel by 1, and sets displaystyle to "false", within each of its arguments except base, but leaves both attributes unchanged within base. (See Section 3.1.6 Displaystyle and Scriptlevel.)

3.4.7.3 Examples

Two examples of the use of mmultiscripts are:

₀F₁(;a;z).

<mrow>
  <mmultiscripts>
    <mi> F </mi>
    <mn> 1 </mn>
    <none/>
    <mprescripts/>
    <mn> 0 </mn>
    <none/>
  </mmultiscripts>
  <mo> &#x2061;<!--FUNCTION APPLICATION--> </mo>
  <mrow>
    <mo> ( </mo>
    <mrow> 
      <mo> ; </mo>
      <mi> a </mi>
      <mo> ; </mo>
      <mi> z </mi>
    </mrow> 
    <mo> ) </mo>
  </mrow>
</mrow>

(where k and l are different indices)

<mmultiscripts>
  <mi> R </mi>
  <mi> i </mi>
  <none/>
  <none/>
  <mi> j </mi>
  <mi> k </mi>
  <none/>
  <mi> l </mi>
  <none/>
</mmultiscripts>

An additional example of mmultiscripts shows how the binomial coefficient

can be displayed in Arabic style

<mstyle dir="rtl">
  <mmultiscripts><mo>&#x0644;<!--ARABIC LETTER LAM--></mo>
    <mn>12</mn><none/>
    <mprescripts/>
    <none/><mn>5</mn>
  </mmultiscripts>
</mstyle>

3.5.1.1 Description

A matrix or table is specified using the mtable element. Inside of the mtable element, only mtr or mlabeledtr elements may appear. (In MathML 1.x, the mtable was allowed to ‘infer’ mtr elements around its arguments, and the mtr element could infer mtd elements. This behaviour is deprecated.)

Table rows that have fewer columns than other rows of the same table (whether the other rows precede or follow them) are effectively padded on the right (or left in RTL context) with empty mtd elements so that the number of columns in each row equals the maximum number of columns in any row of the table. Note that the use of mtd elements with non-default values of the rowspan or columnspan attributes may affect the number of mtd elements that should be given in subsequent mtr elements to cover a given number of columns. Note also that the label in an mlabeledtr element is not considered a column in the table.

MathML does not specify a table layout algorithm. In particular, it is the responsibility of a MathML renderer to resolve conflicts between the width attribute and other constraints on the width of a table, such as explicit values for columnwidth attributes, and minimum sizes for table cell contents. For a discussion of table layout algorithms, see Cascading Style Sheets, level 2.

3.5.1.2 Attributes

mtable elements accept the attributes listed below in addition to those specified in Section 3.1.10 Mathematics style attributes common to presentation elements. Any rules drawn as part of the mtable should be drawn using the color specified by mathcolor.

In the above specifications for attributes affecting rows (respectively, columns, or the gaps between rows or columns), the notation (...)+ means that multiple values can be given for the attribute as a space separated list (see Section 2.1.5 MathML Attribute Values). In this context, a single value specifies the value to be used for all rows (resp., columns or gaps). A list of values are taken to apply to corresponding rows (resp., columns or gaps) in order, that is starting from the top row for rows or first column (left or right, depending on directionality) for columns. If there are more rows (resp., columns or gaps) than supplied values, the last value is repeated as needed. If there are too many values supplied, the excess are ignored.

Note that none of the areas occupied by lines frame, rowlines and columnlines, nor the spacing framespacing, rowspacing or columnspacing, nor the label in mlabeledtr are counted as rows or columns.

The displaystyle attribute is allowed on the mtable element to set the inherited value of the attribute. If the attribute is not present, the mtable element sets displaystyle to "false" within the table elements. (See Section 3.1.6 Displaystyle and Scriptlevel.)

3.5.1.3 Examples

A 3 by 3 identity matrix could be represented as follows:

<mrow>
  <mo> ( </mo>
  <mtable>
    <mtr>
      <mtd> <mn>1</mn> </mtd>
      <mtd> <mn>0</mn> </mtd>
      <mtd> <mn>0</mn> </mtd>
    </mtr>
    <mtr>
      <mtd> <mn>0</mn> </mtd>
      <mtd> <mn>1</mn> </mtd>
      <mtd> <mn>0</mn> </mtd>
    </mtr>
    <mtr>
      <mtd> <mn>0</mn> </mtd>
      <mtd> <mn>0</mn> </mtd>
      <mtd> <mn>1</mn> </mtd>
    </mtr>
  </mtable>
  <mo> ) </mo>
</mrow>

This might be rendered as:

Note that the parentheses must be represented explicitly; they are not part of the mtable element's rendering. This allows use of other surrounding fences, such as brackets, or none at all.

3.5.2.1 Description

An mtr element represents one row in a table or matrix. An mtr element is only allowed as a direct sub-expression of an mtable element, and specifies that its contents should form one row of the table. Each argument of mtr is placed in a different column of the table, starting at the leftmost column in a LTR context or rightmost column in a RTL context.

As described in Section 3.5.1 Table or Matrix <mtable>, mtr elements are effectively padded with mtd elements when they are shorter than other rows in a table.

3.5.2.2 Attributes

mtr elements accept the attributes listed below in addition to those specified in Section 3.1.10 Mathematics style attributes common to presentation elements.

3.5.3.1 Description

An mlabeledtr element represents one row in a table that has a label on either the left or right side, as determined by the side attribute. The label is the first child of mlabeledtr, and should be enclosed in an mtd. The rest of the children represent the contents of the row and are treated identically to the children of mtr; consequently all of the children must be mtd elements.

An mlabeledtr element is only allowed as a direct sub-expression of an mtable element. Each argument of mlabeledtr except for the first argument (the label) is placed in a different column of the table, starting at the leftmost column.

Note that the label element is not considered to be a cell in the table row. In particular, the label element is not taken into consideration in the table layout for purposes of width and alignment calculations. For example, in the case of an mlabeledtr with a label and a single centered mtd child, the child is first centered in the enclosing mtable, and then the label is placed. Specifically, the child is not centered in the space that remains in the table after placing the label.

While MathML does not specify an algorithm for placing labels, implementers of visual renderers may find the following formatting model useful. To place a label, an implementor might think in terms of creating a larger table, with an extra column on both ends. The columnwidth attributes of both these border columns would be set to "fit" so that they expand to fill whatever space remains after the inner columns have been laid out. Finally, depending on the values of side and minlabelspacing, the label is placed in whatever border column is appropriate, possibly shifted down if necessary, and aligned according to columnalignment.

3.5.3.2 Attributes

The attributes for mlabeledtr are the same as for mtr. Unlike the attributes for the mtable element, attributes of mlabeledtr that apply to column elements also apply to the label. For example, in a one column table,

<mlabeledtr rowalign='top'>

means that the label and other entries in the row are vertically aligned along their top. To force a particular alignment on the label, the appropriate attribute would normally be set on the mtd element that surrounds the label content.

3.5.3.3 Equation Numbering

One of the important uses of mlabeledtr is for numbered equations. In a mlabeledtr, the label represents the equation number and the elements in the row are the equation being numbered. The side and minlabelspacing attributes of mtable determine the placement of the equation number.

In larger documents with many numbered equations, automatic numbering becomes important. While automatic equation numbering and automatically resolving references to equation numbers is outside the scope of MathML, these problems can be addressed by the use of style sheets or other means. The mlabeledtr construction provides support for both of these functions in a way that is intended to facilitate XSLT processing. The mlabeledtr element can be used to indicate the presence of a numbered equation, and the first child can be changed to the current equation number, along with incrementing the global equation number. For cross references, an id on either the mlabeledtr element or on the first element itself could be used as a target of any link. Alternatively, in a CSS context, one could use an empty mtd as the first child of mlabeledtr and use CSS counters and generated content to fill in the equation number using a CSS style such as

body {counter-reset: eqnum;}
mtd.eqnum {counter-increment: eqnum;}
mtd.eqnum:before {content: "(" counter(eqnum) ")"}

3.5.3.4 Example

<mtable>
  <mlabeledtr id='e-is-m-c-square'>
    <mtd>
      <mtext> (2.1) </mtext>
    </mtd>
    <mtd>
     <mrow>
       <mi>E</mi>
       <mo>=</mo>
       <mrow>
        <mi>m</mi>
        <mo>&#x2062;<!--INVISIBLE TIMES--></mo>
        <msup>
         <mi>c</mi>
         <mn>2</mn>
        </msup>
       </mrow>
     </mrow>
    </mtd>
  </mlabeledtr>
</mtable>

This should be rendered as:

3.5.4.1 Description

An mtd element represents one entry, or cell, in a table or matrix. An mtd element is only allowed as a direct sub-expression of an mtr or an mlabeledtr element.

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

3.5.4.2 Attributes

mtd elements accept the attributes listed below in addition to those specified in Section 3.1.10 Mathematics style attributes common to presentation elements.

The rowspan and columnspan attributes can be used around an mtd element that represents the label in a mlabeledtr element. Also, the label of a mlabeledtr element is not considered to be part of a previous rowspan and columnspan.

3.5.5.1 Description

Alignment markers are space-like elements (see Section 3.2.7 Space <mspace/>) that can be used to vertically align specified points within a column of MathML expressions by the automatic insertion of the necessary amount of horizontal space between specified sub-expressions.

The discussion that follows will use the example of a set of simultaneous equations that should be rendered with vertical alignment of the coefficients and variables of each term, by inserting spacing somewhat like that shown here:

    8.44x + 55  y =  0
    3.1 x -  0.7y = -1.1

If the example expressions shown above were arranged in a column but not aligned, they would appear as:

    8.44x + 55y = 0
    3.1x - 0.7y = -1.1

For audio renderers, it is suggested that the alignment elements produce the analogous behavior of altering the rhythm of pronunciation so that it is the same for several sub-expressions in a column, by the insertion of the appropriate time delays in place of the extra horizontal spacing described here.

The expressions whose parts are to be aligned (each equation, in the example above) must be given as the table elements (i.e. as the mtd elements) of one column of an mtable. To avoid confusion, the term "table cell" rather than "table element" will be used in the remainder of this section.

All interactions between alignment elements are limited to the mtable column they arise in. That is, every column of a table specified by an mtable element acts as an "alignment scope" that contains within it all alignment effects arising from its contents. It also excludes any interaction between its own alignment elements and the alignment elements inside any nested alignment scopes it might contain.

The reason mtable columns are used as alignment scopes is that they are the only general way in MathML to arrange expressions into vertical columns. Future versions of MathML may provide an malignscope element that allows an alignment scope to be created around any MathML element, but even then, table columns would still sometimes need to act as alignment scopes, and since they are not elements themselves, but rather are made from corresponding parts of the content of several mtr elements, they could not individually be the content of an alignment scope element.

An mtable element can be given the attribute alignmentscope="false" to cause its columns not to act as alignment scopes. This is discussed further at the end of this section. Otherwise, the discussion in this section assumes that this attribute has its default value of "true".

3.5.5.2 Specifying alignment groups

To cause alignment, it is necessary to specify, within each expression to be aligned, the points to be aligned with corresponding points in other expressions, and the beginning of each alignment group of sub-expressions that can be horizontally shifted as a unit to effect the alignment. Each alignment group must contain one alignment point. It is also necessary to specify which expressions in the column have no alignment groups at all, but are affected only by the ordinary column alignment for that column of the table, i.e. by the columnalign attribute, described elsewhere.

The alignment groups start at the locations of invisible maligngroup elements, which are rendered with zero width when they occur outside of an alignment scope, but within an alignment scope are rendered with just enough horizontal space to cause the desired alignment of the alignment group that follows them. A simple algorithm by which a MathML application can achieve this is given later. In the example above, each equation would have one maligngroup element before each coefficient, variable, and operator on the left-hand side, one before the = sign, and one before the constant on the right-hand side.

In general, a table cell containing n maligngroup elements contains n alignment groups, with the ith group consisting of the elements entirely after the ith maligngroup element and before the (i+1)-th; no element within the table cell's content should occur entirely before its first maligngroup element.

Note that the division into alignment groups does not necessarily fit the nested expression structure of the MathML expression containing the groups — that is, it is permissible for one alignment group to consist of the end of one mrow, all of another one, and the beginning of a third one, for example. This can be seen in the MathML markup for the present example, given at the end of this section.

The nested expression structure formed by mrows and other layout schemata should reflect the mathematical structure of the expression, not the alignment-group structure, to make possible optimal renderings and better automatic interpretations; see the discussion of proper grouping in section Section 3.3.1 Horizontally Group Sub-Expressions <mrow>. Insertion of alignment elements (or other space-like elements) should not alter the correspondence between the structure of a MathML expression and the structure of the mathematical expression it represents.

Although alignment groups need not coincide with the nested expression structure of layout schemata, there are nonetheless restrictions on where an maligngroup element is allowed within a table cell. The maligngroup element may only be contained within elements (directly or indirectly) of the following types (which are themselves contained in the table cell):

• an mrow element, including an inferred mrow such as the one formed by a multi-child mtd element, but excluding mrow which contains a change of direction using the dir attribute;

• an mstyle element , but excluding those which change direction using the dir attribute;

• an mphantom element;

• an mfenced element;

• an maction element, though only its selected sub-expression is checked;

• a semantics element.

These restrictions are intended to ensure that alignment can be unambiguously specified, while avoiding complexities involving things like overscripts, radical signs and fraction bars. They also ensure that a simple algorithm suffices to accomplish the desired alignment.

Note that some positions for an maligngroup element, although legal, are not useful, such as an maligngroup element that is an argument of an mfenced element. Similarly, when inserting an maligngroup element in an element whose arguments have positional significance, it is necessary to introduce a new mrow element containing just the maligngroup element and the child element it precedes in order to preserve the proper expression structure. For example, to insert an maligngroup before the denominator child of an mfrac element, it is necessary to enclose the maligngroup and the denominator in an mrow to avoid introducing an illegal third child in the mfrac. In general, this will be necessary except when the maligngroup element is inserted directly into an mrow or into an element that can form an inferred mrow from its contents. See the warning about the legal grouping of "space-like elements" in Section 3.2.7 Space <mspace/> for an analogous example involving malignmark.

For the table cells that are divided into alignment groups, every element in their content must be part of exactly one alignment group, except for the elements from the above list that contain maligngroup elements inside them and the maligngroup elements themselves. This means that, within any table cell containing alignment groups, the first complete element must be an maligngroup element, though this may be preceded by the start tags of other elements.

This requirement removes a potential confusion about how to align elements before the first maligngroup element, and makes it easy to identify table cells that are left out of their column's alignment process entirely.

Note that it is not required that the table cells in a column that are divided into alignment groups each contain the same number of groups. If they don't, zero-width alignment groups are effectively added on the right side (or left side, in a RTL context) of each table cell that has fewer groups than other table cells in the same column.

3.5.5.3 Table cells that are not divided into alignment groups

Expressions in a column that are to have no alignment groups should contain no maligngroup elements. Expressions with no alignment groups are aligned using only the columnalign attribute that applies to the table column as a whole, and are not affected by the groupalign attribute described below. If such an expression is wider than the column width needed for the table cells containing alignment groups, all the table cells containing alignment groups will be shifted as a unit within the column as described by the columnalign attribute for that column. For example, a column heading with no internal alignment could be added to the column of two equations given above by preceding them with another table row containing an mtext element for the heading, and using the default columnalign="center" for the table, to produce:

equations with aligned variables
      8.44x + 55  y =  0
      3.1 x -  0.7y = -1.1

or, with a shorter heading,

   some equations
8.44x + 55  y =  0
3.1 x -  0.7y = -1.1

3.5.5.4 Specifying alignment points using <malignmark/>

Each alignment group's alignment point can either be specified by an malignmark element anywhere within the alignment group (except within another alignment scope wholly contained inside it), or it is determined automatically from the groupalign attribute. The groupalign attribute can be specified on the group's preceding maligngroup element or on its surrounding mtd, mtr, or mtable elements. In typical cases, using the groupalign attribute is sufficient to describe the desired alignment points, so no malignmark elements need to be provided.

The malignmark element indicates that the alignment point should occur on the right edge of the preceding element, or the left edge of the following element or character, depending on the edge attribute of malignmark. Note that it may be necessary to introduce an mrow to group an malignmark element with a neighboring element, in order not to alter the argument count of the containing element. (See the warning about the legal grouping of "space-like elements" in Section 3.2.7 Space <mspace/>).

When an malignmark element is provided within an alignment group, it can occur in an arbitrarily deeply nested element within the group, as long as it is not within a nested alignment scope. It is not subject to the same restrictions on location as maligngroup elements. However, its immediate surroundings need to be such that the element to its immediate right or left (depending on its edge attribute) can be unambiguously identified. If no such element is present, renderers should behave as if a zero-width element had been inserted there.

For the purposes of alignment, an element X is considered to be to the immediate left of an element Y, and Y to the immediate right of X, whenever X and Y are successive arguments of one (possibly inferred) mrow element, with X coming before Y (in a LTR context; with X coming after Y in a RTL context). In the case of mfenced elements, MathML applications should evaluate this relation as if the mfenced element had been replaced by the equivalent expanded form involving mrow. Similarly, an maction element should be treated as if it were replaced by its currently selected sub-expression. In all other cases, no relation of "to the immediate left or right" is defined for two elements X and Y. However, in the case of content elements interspersed in presentation markup, MathML applications should attempt to evaluate this relation in a sensible way. For example, if a renderer maintains an internal presentation structure for rendering content elements, the relation could be evaluated with respect to that. (See Chapter 4 Content Markup and Chapter 5 Mixing Markup Languages for Mathematical Expressions for further details about mixing presentation and content markup.)

malignmark elements are allowed to occur within the content of token elements, such as mn, mi, or mtext. When this occurs, the character immediately before or after the malignmark element will carry the alignment point; in all other cases, the element to its immediate left or right will carry the alignment point. The rationale for this is that it is sometimes desirable to align on the edges of specific characters within multi-character token elements.

If there is more than one malignmark element in an alignment group, all but the first one will be ignored. MathML applications may wish to provide a mode in which they will warn about this situation, but it is not an error, and should trigger no warnings by default. The rationale for this is that it would be inconvenient to have to remove all unnecessary malignmark elements from automatically generated data, in certain cases, such as when they are used to specify alignment on "decimal points" other than the '.' character.

3.5.5.5 <malignmark/> Attributes

malignmark elements accept the attributes listed below in addition to those specified in Section 3.1.10 Mathematics style attributes common to presentation elements (however, neither mathcolor nor mathbackground have any effect).

The edge attribute specifies whether the alignment point will be found on the left or right edge of some element or character. The precise location meant by "left edge" or "right edge" is discussed below. If edge="right", the alignment point is the right edge of the element or character to the immediate left of the malignmark element. If edge="left", the alignment point is the left edge of the element or character to the immediate right of the malignmark element. Note that the attribute refers to the choice of edge rather than to the direction in which to look for the element whose edge will be used.

For malignmark elements that occur within the content of MathML token elements, the preceding or following character in the token element's content is used; if there is no such character, a zero-width character is effectively inserted for the purpose of carrying the alignment point on its edge. For all other malignmark elements, the preceding or following element is used; if there is no such element, a zero-width element is effectively inserted to carry the alignment point.

The precise definition of the "left edge" or "right edge" of a character or glyph (e.g. whether it should coincide with an edge of the character's bounding box) is not specified by MathML, but is at the discretion of the renderer; the renderer is allowed to let the edge position depend on the character's context as well as on the character itself.

For proper alignment of columns of numbers (using groupalign values of "left", "right", or "decimalpoint"), it is likely to be desirable for the effective width (i.e. the distance between the left and right edges) of decimal digits to be constant, even if their bounding box widths are not constant (e.g. if "1" is narrower than other digits). For other characters, such as letters and operators, it may be desirable for the aligned edges to coincide with the bounding box.

The "left edge" of a MathML element or alignment group refers to the left edge of the leftmost glyph drawn to render the element or group, except that explicit space represented by mspace or mtext elements should also count as "glyphs" in this context, as should glyphs that would be drawn if not for mphantom elements around them. The "right edge" of an element or alignment group is defined similarly.

3.5.5.6 <maligngroup/> Attributes

maligngroup elements accept the attributes listed below in addition to those specified in Section 3.1.10 Mathematics style attributes common to presentation elements (however, neither mathcolor nor mathbackground have any effect).

maligngroup has one attribute, groupalign, which is used to determine the position of its group's alignment point when no malignmark element is present. The following discussion assumes that no malignmark element is found within a group.

In the example given at the beginning of this section, there is one column of 2 table cells, with 7 alignment groups in each table cell; thus there are 7 columns of alignment groups, with 2 groups, one above the other, in each column. These columns of alignment groups should be given the 7 groupalign values "decimalpoint left left decimalpoint left left decimalpoint", in that order. How to specify this list of values for a table cell or table column as a whole, using attributes on elements surrounding the maligngroup element is described later.

If groupalign is "left", "right", or "center", the alignment point is defined to be at the group's left edge, at its right edge, or halfway between these edges, respectively. The meanings of "left edge" and "right edge" are as discussed above in relation to malignmark.

If groupalign is "decimalpoint", the alignment point is the right edge of the character immediately before the left-most 'decimal point', i.e. matching the character specified by the decimalpoint attribute of mstyle (default ".", U+002E) in the first mn element found along the alignment group's baseline. More precisely, the alignment group is scanned recursively, depth-first, for the first mn element, descending into all arguments of each element of the types mrow (including inferred mrows), mstyle, mpadded, mphantom, menclose, mfenced, or msqrt, descending into only the first argument of each "scripting" element (msub, msup, msubsup, munder, mover, munderover, mmultiscripts) or of each mroot or semantics element, descending into only the selected sub-expression of each maction element, and skipping the content of all other elements. The first mn so found always contains the alignment point, which is the right edge of the last character before the first decimal point in the content of the mn element. If there is no decimal point in the mn element, the alignment point is the right edge of the last character in the content. If the decimal point is the first character of the mn element's content, the right edge of a zero-width character inserted before the decimal point is used. If no mn element is found, the right edge of the entire alignment group is used (as for groupalign="right").

In order to permit alignment on decimal points in cn elements, a MathML application can convert a content expression into a presentation expression that renders the same way before searching for decimal points as described above.

Characters other than "." can be used as "decimal points" for alignment by using mstyle; more arbitrary alignment points can chosen by embedding malignmark elements within the mn token's content itself.

For any of the groupalign values, if an explicit malignmark element is present anywhere within the group, the position it specifies (described earlier) overrides the automatic determination of alignment point from the groupalign value.

3.5.5.7 Inheritance of groupalign values

It is not usually necessary to put a groupalign attribute on every maligngroup element. Since this attribute is usually the same for every group in a column of alignment groups to be aligned, it can be inherited from an attribute on the mtable that was used to set up the alignment scope as a whole, or from the mtr or mtd elements surrounding the alignment group. It is inherited via an "inheritance path" that proceeds from mtable through successively contained mtr, mtd, and maligngroup elements. There is exactly one element of each of these kinds in this path from an mtable to any alignment group inside it. In general, the value of groupalign will be inherited by any given alignment group from the innermost element that surrounds the alignment group and provides an explicit setting for this attribute. For example, if an mtable element specifies values for groupalign and a maligngroup element within the table also specifies an explicit groupalign value, then then the value from the maligngroup takes priority.

Note, however, that each mtd element needs, in general, a list of groupalign values, one for each maligngroup element inside it (from left to right, in an LTR context, or from right to left in an RTL context), rather than just a single value. Furthermore, an mtr or mtable element needs, in general, a list of lists of groupalign values, since it spans multiple mtable columns, each potentially acting as an alignment scope. Such lists of group-alignment values are specified using the following syntax rules:

group-alignment             = "left" | "right" | "center" | "decimalpoint"
group-alignment-list        = group-alignment +
group-alignment-list-list   = ( "{" group-alignment-list "}" ) +

As described in Section 2.1.5 MathML Attribute Values, | separates alternatives; + represents optional repetition (i.e. 1 or more copies of what precedes it), with extra values ignored and the last value repeated if necessary to cover additional table columns or alignment group columns; '{' and '}' represent literal braces; and ( and ) are used for grouping, but do not literally appear in the attribute value.

The permissible values of the groupalign attribute of the elements that have this attribute are specified using the above syntax definitions as follows:

In the example near the beginning of this section, the group alignment values could be specified on every mtd element using groupalign = "decimalpoint left left decimalpoint left left decimalpoint", or on every mtr element using groupalign = "{decimalpoint left left decimalpoint left left decimalpoint}", or (most conveniently) on the mtable as a whole using groupalign = "{decimalpoint left left decimalpoint left left decimalpoint}", which provides a single braced list of group-alignment values for the single column of expressions to be aligned.

3.5.5.8 MathML representation of an alignment example

The above rules are sufficient to explain the MathML representation of the example given near the start of this section. To repeat the example, the desired rendering is:

    8.44x + 55  y =  0
    3.1 x -  0.7y = -1.1

One way to represent that in MathML is:

<mtable groupalign=
         "{decimalpoint left left decimalpoint left left decimalpoint}">
  <mtr>
    <mtd>
      <mrow>
        <mrow>
          <mrow>
            <maligngroup/>
            <mn> 8.44 </mn>
            <mo> &#x2062;<!--INVISIBLE TIMES--> </mo>
            <maligngroup/>
            <mi> x </mi>
          </mrow>
          <maligngroup/>
          <mo> + </mo>
          <mrow>
            <maligngroup/>
            <mn> 55 </mn>
            <mo> &#x2062;<!--INVISIBLE TIMES--> </mo>
            <maligngroup/>
            <mi> y </mi>
          </mrow>
        </mrow>
      <maligngroup/>
      <mo> = </mo>
      <maligngroup/>
      <mn> 0 </mn>
    </mrow>
    </mtd>
  </mtr>
  <mtr>
    <mtd>
      <mrow>
        <mrow>
          <mrow>
            <maligngroup/>
            <mn> 3.1 </mn>
            <mo> &#x2062;<!--INVISIBLE TIMES--> </mo>
            <maligngroup/>
            <mi> x </mi>
          </mrow>
          <maligngroup/>
          <mo> - </mo>
          <mrow>
            <maligngroup/>
            <mn> 0.7 </mn>
            <mo> &#x2062;<!--INVISIBLE TIMES--> </mo>
            <maligngroup/>
            <mi> y </mi>
          </mrow>
        </mrow>
        <maligngroup/>
        <mo> = </mo>
        <maligngroup/>
        <mrow>
          <mo> - </mo>
          <mn> 1.1 </mn>
        </mrow>
      </mrow>
    </mtd>
  </mtr>
</mtable>

3.5.5.9 Further details of alignment elements

The alignment elements maligngroup and malignmark can occur outside of alignment scopes, where they are ignored. The rationale behind this is that in situations in which MathML is generated, or copied from another document, without knowing whether it will be placed inside an alignment scope, it would be inconvenient for this to be an error.

An mtable element can be given the attribute alignmentscope="false" to cause its columns not to act as alignment scopes. In general, this attribute has the syntax ("true" | "false") +; if its value is a list of Boolean values, each Boolean value applies to one column, with the last value repeated if necessary to cover additional columns, or with extra values ignored. Columns that are not alignment scopes are part of the alignment scope surrounding the mtable element, if there is one. Use of alignmentscope="false" allows nested tables to contain malignmark elements for aligning the inner table in the surrounding alignment scope.

As discussed above, processing of alignment for content elements is not well-defined, since MathML does not specify how content elements should be rendered. However, many MathML applications are likely to find it convenient to internally convert content elements to presentation elements that render the same way. Thus, as a general rule, even if a renderer does not perform such conversions internally, it is recommended that the alignment elements should be processed as if it did perform them.

A particularly important case for renderers to handle gracefully is the interaction of alignment elements with the matrix content element, since this element may or may not be internally converted to an expression containing an mtable element for rendering. To partially resolve this ambiguity, it is suggested, but not required, that if the matrix element is converted to an expression involving an mtable element, that the mtable element be given the attribute alignmentscope="false", which will make the interaction of the matrix element with the alignment elements no different than that of a generic presentation element (in particular, it will allow it to contain malignmark elements that operate within the alignment scopes created by the columns of an mtable that contains the matrix element in one of its table cells).

The effect of alignment elements within table cells that have non-default values of the columnspan or rowspan attributes is not specified, except that such use of alignment elements is not an error. Future versions of MathML may specify the behavior of alignment elements in such table cells.

The effect of possible linebreaking of an mtable element on the alignment elements is not specified.

3.5.5.10 A simple alignment algorithm

A simple algorithm by which a MathML renderer can perform the alignment specified in this section is given here. Since the alignment specification is deterministic (except for the definition of the left and right edges of a character), any correct MathML alignment algorithm will have the same behavior as this one. Each mtable column (alignment scope) can be treated independently; the algorithm given here applies to one mtable column, and takes into account the alignment elements, the groupalign attribute described in this section, and the columnalign attribute described under mtable (Section 3.5.1 Table or Matrix <mtable>).

First, a rendering is computed for the contents of each table cell in the column, using zero width for all maligngroup and malignmark elements. The final rendering will be identical except for horizontal shifts applied to each alignment group and/or table cell. The positions of alignment points specified by any malignmark elements are noted, and the remaining alignment points are determined using groupalign values.

For each alignment group, the horizontal positions of the left edge, alignment point, and right edge are noted, allowing the width of the group on each side of the alignment point (left and right) to be determined. The sum of these two "side-widths", i.e. the sum of the widths to the left and right of the alignment point, will equal the width of the alignment group.

Second, each column of alignment groups is scanned. The ith scan covers the ith alignment group in each table cell containing any alignment groups. Table cells with no alignment groups, or with fewer than i alignment groups, are ignored. Each scan computes two maximums over the alignment groups scanned: the maximum width to the left of the alignment point, and the maximum width to the right of the alignment point, of any alignment group scanned.

The sum of all the maximum widths computed (two for each column of alignment groups) gives one total width, which will be the width of each table cell containing alignment groups. Call the maximum number of alignment groups in one cell n; each such cell is divided into 2n horizontally adjacent sections, called L(i) and R(i) for i from 1 to n, using the 2n maximum side-widths computed above; for each i, the width of all sections called L(i) is the maximum width of any cell's ith alignment group to the left of its alignment point, and the width of all sections called R(i) is the maximum width of any cell's ith alignment group to the right of its alignment point.

Each alignment group is then shifted horizontally as a block to a unique position that places: in the section called L(i) that part of the ith group to the left of its alignment point; in the section called R(i) that part of the ith group to the right of its alignment point. This results in the alignment point of each ith group being on the boundary between adjacent sections L(i) and R(i), so that all alignment points of ith groups have the same horizontal position.

The widths of the table cells that contain no alignment groups were computed as part of the initial rendering, and may be different for each cell, and different from the single width used for cells containing alignment groups. The maximum of all the cell widths (for both kinds of cells) gives the width of the table column as a whole.

The position of each cell in the column is determined by the applicable part of the value of the columnalign attribute of the innermost surrounding mtable, mtr, or mtd element that has an explicit value for it, as described in the sections on those elements. This may mean that the cells containing alignment groups will be shifted within their column, in addition to their alignment groups having been shifted within the cells as described above, but since each such cell has the same width, it will be shifted the same amount within the column, thus maintaining the vertical alignment of the alignment points of the corresponding alignment groups in each cell.

3.6.1.1 Description

mstack is used to lay out rows of numbers that are aligned on each digit. This is common in many elementary math notations such as 2D addition, subtraction, and multiplication.

The children of an mstack represent rows, or groups of them, to be stacked each below the previous row; there can be any number of rows. An msrow represents a row; an msgroup groups a set of rows together so that their horizontal alignment can be adjusted together; an mscarries represents a set of carries to be applied to the following row; an msline represents a line separating rows. Any other element is treated as if implicitly surrounded by msrow.

Each row contains ‘digits’ that are placed into columns. (see Section 3.6.4 Rows in Elementary Math <msrow> for further details). The stackalign attribute together with the position and shift attributes of msgroup, mscarries, and msrow determine to which column a character belongs.

The width of a column is the maximum of the widths of each ‘digit’ in that column — carries do not participate in the width calculation; they are treated as having zero width. If an element is too wide to fit into a column, it overflows into the adjacent column(s) as determined by the charalign attribute. If there is no character in a column, its width is taken to be the width of a 0 in the current language (in many fonts, all digits have the same width).

The method for laying out an mstack is:

1. The ‘digits’ in a row are determined.

2. All of the digits in a row are initially aligned according to the stackalign value.

3. Each row is positioned relative to that alignment based on the position attribute (if any) that controls that row.

4. The maximum width of the digits in a column are determined and shorter and wider entries in that column are aligned according to the charalign attribute.

5. The width and height of the mstack element are computed based on the rows and columns. Any overflow from a column is not used as part of that computation.

6. The baseline of the mstack element is determined by the align attribute.

3.6.1.2 Attributes

mstack elements accept the attributes listed below in addition to those specified in Section 3.1.10 Mathematics style attributes common to presentation elements.

3.6.2.1 Description

Long division notation varies quite a bit around the world, although the heart of the notation is often similar. mlongdiv is similar to mstack and used to layout long division. The first two children of mlongdiv are the divisor and the result of the division, in that order. The remaining children are treated as if they were children of mstack. The placement of these and the lines and separators used to display long division are controlled by the longdivstyle attribute.

The result or divisor may be an elementary math element or may be none. In particular, if msgroup is used, the elements in that group may or may not form their own mstack or be part of the dividend's mstack, depending upon the value of the longdivstyle attribute. For example, in the US style for division, the result is treated as part of the dividend's mstack, but divisor is not. MathML does not specify when the result and divisor form their own mstack, nor does it specify what should happen if msline or other elementary math elements are used for the result or divisor and they do not participate in the dividend's mstack layout.

In the remainder of this section on elementary math, anything that is said about mstack applies to mlongdiv unless stated otherwise.

3.6.2.2 Attributes

mlongdiv elements accept all of the attributes that mstack elements accept (including those specified in Section 3.1.10 Mathematics style attributes common to presentation elements), along with the attribute listed below.

The values allowed for longdivstyle 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 rules drawn as part of division layout should be drawn using the color specified by mathcolor.