Presentation Markup

3.1 Introduction

This chapter specifies the "presentation" elements of MathML, which can be used to describe the layout structure of mathematical notation.

3.1.1 What Presentation Elements Represent

Presentation elements correspond to the "constructors" of traditional mathematical notation – that is, to the basic kinds of symbols and expression-building structures out of which any particular piece of traditional mathematical notation is built. Because of the importance of traditional visual notation, the descriptions of the notational constructs the elements represent are usually given here in visual terms. However, the elements are medium-independent in the sense that they have been designed to contain enough information for good spoken renderings as well. Some attributes of these elements may make sense only for visual media, but most attributes can be treated in an analogous way in audio as well (for example, by a correspondence between time duration and horizontal extent).

MathML presentation elements only suggest (i.e. do not require) specific ways of rendering in order to allow for medium-dependent rendering and for individual preferences of style. This specification describes suggested visual rendering rules in some detail, but a particular MathML renderer is free to use its own rules as long as its renderings are intelligible.

The presentation elements are meant to express the syntactic structure of mathematical notation in much the same way as titles, sections, and paragraphs capture the higher-level syntactic structure of a textual document. Because of this, for example, a single row of identifiers and operators, such as "x + a / b", will often be represented not just by one mrow element (which renders as a horizontal row of its arguments), but by multiple nested mrow elements corresponding to the nested sub-expressions of which one mathematical expression is composed – in this case,

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

Similarly, superscripts are attached not just to the preceding character, but to the full expression constituting their base. This structure allows for better-quality rendering of mathematics, especially when details of the rendering environment such as display widths are not known to the document author; it also greatly eases automatic interpretation of the mathematical structures being represented.

Certain MathML characters are used to name operators or identifiers that in traditional notation render the same as other symbols, such as &DifferentialD;, &ExponentialE;, or &ImaginaryI;, or operators that usually render invisibly, such as ⁢, ⁤, ⁡, or ⁣. These are distinct notational symbols or objects, as evidenced by their distinct spoken renderings and in some cases by their effects on linebreaking and spacing in visual rendering, and as such should be represented by the appropriate specific entity references. For example, the expression represented visually as "f(x)" would usually be spoken in English as "f of x" rather than just "f x"; this is expressible in MathML by the use of the ⁡ operator after the "f", which (in this case) can be aurally rendered as "of".

The complete list of MathML entities is described in Chapter 6 Characters, Entities and Fonts.

3.1.2 Terminology Used In This Chapter

It is strongly recommended that, before reading the present chapter, one read Section 2.1 MathML Syntax and Grammar on MathML syntax and grammar, which contains important information on MathML notations and conventions. In particular, in this chapter it is assumed that the reader has an understanding of basic XML terminology described in Section 2.1.2 Children versus Arguments, and the attribute value notations and conventions described in Section 2.1.3 MathML Attribute Values.

The remainder of this section introduces MathML-specific terminology and conventions used in this chapter.

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. In general, tokens can have only characters as content. The only exceptions are the vertical alignment element malignmark, mglyph, and entity references. Layout schemata build expressions out of parts, and can have only elements as content (except for whitespace, which they ignore). 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 for representing text or whitespace that has more aesthetic than mathematical significance, and for 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.6 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.4.3 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 Required Arguments

Many of the elements described herein require a specific number of arguments (always 1, 2, or 3). In the detailed descriptions of element syntax given below, the number of required arguments is implicitly indicated by giving names for the arguments at various positions. A few elements have additional requirements on the number or type of arguments, which are described with the individual element. For example, some elements accept sequences of zero or more arguments – that is, they are allowed to occur with no arguments at all.

Note that MathML elements encoding rendered space do count as arguments of the elements in which they appear. See Section 3.2.7 Space (mspace) for a discussion of the proper use of such space-like elements.

3.1.3.1 Inferred `mrow`s

The elements listed in the following table as requiring 1* argument (msqrt, mstyle, merror, menclose, mpadded, mphantom, mtd, and math) actually accept any number of arguments. However, if the number of arguments is 0, or is more than 1, they treat their contents as a single inferred mrow formed from all their arguments. Although the math element is not a presentation element, it is listed below for completeness.

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.

In the descriptions in this chapter of the above-listed elements' rendering behaviors, their content can be assumed to consist of exactly one expression, which may be an mrow element formed from their arguments in this manner. However, their argument counts are shown in the following table as 1*, since they are most naturally understood as acting on a single expression.

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.

Element	Required argument count	Argument roles (when these differ by position)
`mrow`	0 or more
`mfrac`	2	numerator denominator
`msqrt`	1*
`mroot`	2	base index
`mstyle`	1*
`merror`	1*
`mpadded`	1*
`mphantom`	1*
`mfenced`	0 or more
`menclose`	1*
`msub`	2	base subscript
`msup`	2	base superscript
`msubsup`	3	base subscript superscript
`munder`	2	base underscript
`mover`	2	base overscript
`munderover`	3	base underscript overscript
`mmultiscripts`	1 or more	base (subscript superscript)* [`<mprescripts/>` (presubscript presuperscript)*]
`mtable`	0 or more rows	0 or more `mtr` or `mlabeledtr` elements
`mlabeledtr`	1 or more	a label and 0 or more `mtd` elements
`mtr`	0 or more	0 or more `mtd` elements
`mtd`	1*
`maction`	1 or more	depend on `actiontype` attribute
`math`	1*

3.1.4 Elements with Special Behaviors

Certain MathML presentation elements exhibit special behaviors in certain contexts. Such special behaviors are discussed in the detailed element descriptions below. However, for convenience, some of the most important classes of special behavior are listed here.

Certain elements are considered space-like; these are defined in Section 3.2.7 Space (mspace). This definition affects some of the suggested rendering rules for mo elements (Section 3.2.5 Operator, Fence, Separator or Accent (mo)).

Certain elements, e.g. msup, are able to embellish operators that are their first argument. These elements are listed in Section 3.2.5 Operator, Fence, Separator or Accent (mo), which precisely defines an "embellished operator" and explains how this affects the suggested rendering rules for stretchy operators.

Certain elements treat their arguments as the arguments of an "inferred mrow" if they are not given exactly one argument, as explained in Section 3.1.3 Required Arguments.

In MathML 1.x, the mtable element could infer mtr elements around its arguments, and the mtr element could infer mtd elements. In MathML 2.0, mtr and mtd elements must be explicit. However, for backward compatibility renderers may wish to continue supporting inferred mtr and mtd elements.

3.1.5 Directionality

In the notations familiar to most readers, both the overall layout and the textual symbols are arranged from left to right (LTR). Yet, as alluded to in the introduction, mathematics written in Hebrew, or in locales such as Morocco or Persia, the overall layout is used unchanged, but the embedded symbols (often Hebrew or Arabic) are written right to left (RTL). Moreover, in most of the Arabic speaking world, the notation is arranged entirely RTL; thus a superscript is still raised, but it follows the base on the left, rather than the right.

MathML 3.0 therefore recognizes two distinct directionalities: the directionality of the text and symbols within Token elements, and the overall directionality represented by Layout Schemata. These two facets are dicussed below.

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.5.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. 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 overall directionality may also be switched for individual subformula by using the dir on mrow elements. When not specified, all mrow elements inherit the directionality of the 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 important thing to notice is that the Bidi algorithm is applied independently to the contents of each token element; each Token element is an independent run of characters. This is in contrast to the application of Bidi to HTML, where the algorithm applies to the entire sequence of characters within each block level element.

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, caligraphic scripts such as Arabic blend, or connect, sequences of characters together, changing thier 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 codepoints U+2135-U+2138 (ALEF SYMBOL, BET SYMBOL, GIMEL SYMBOL, DALET SYMBOL) should be used. These are strong left-to-right.

3.1.6 Summary of Presentation Elements

3.1.6.1 Token Elements

`mi`	identifier
`mn`	number
`mo`	operator, fence, or separator
`mtext`	text
`mspace`	space
`ms`	string literal
`mglyph`	accessing glyphs for characters from MathML

3.1.6.2 General Layout Schemata

`mrow`	group any number of sub-expressions horizontally
`mfrac`	form a fraction from two sub-expressions
`msqrt`	form a square root (radical without an index)
`mroot`	form a radical with specified index
`mstyle`	style change
`merror`	enclose a syntax error message from a preprocessor
`mpadded`	adjust space around content
`mphantom`	make content invisible but preserve its size
`mfenced`	surround content with a pair of fences
`menclose`	enclose content with a stretching symbol such as a long division sign.

3.1.6.3 Script and Limit Schemata

`msub`	attach a subscript to a base
`msup`	attach a superscript to a base
`msubsup`	attach a subscript-superscript pair to a base
`munder`	attach an underscript to a base
`mover`	attach an overscript to a base
`munderover`	attach an underscript-overscript pair to a base
`mmultiscripts`	attach prescripts and tensor indices to a base

3.1.6.4 Tables and Matrices

`mtable`	table or matrix
`mlabeledtr`	row in a table or matrix with a label or equation number
`mtr`	row in a table or matrix
`mtd`	one entry in a table or matrix
`maligngroup` and `malignmark`	alignment markers

3.1.6.5 Enlivening Expressions

maction bind actions to a sub-expression

3.2 Token Elements

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

Frequently tokens consist of a single character denoting a mathematical symbol. Other cases, e.g. function names, involve multi-character tokens. Further, because traditional mathematical notation makes wide use of symbols distinguished by their typographical properties (e.g. a Fraktur 'g' for a Lie algebra, or a bold 'x' for a vector), care must be taken to insure that styling mechanisms respect typographical properties which carry meaning. Consequently, characters, tokens, and typographical properties of symbols are closely related to one another in MathML.

3.2.1 MathML characters in token elements

Character data in MathML markup is only allowed to occur as part of the content of token elements. The only exception is whitespace between elements, which is ignored. Token elements can contain any sequence of zero or more Unicode characters. In particular, tokens with empty content are allowed, and should typically render invisibly, with no width except for the normal extra spacing for that kind of token element. The exceptions to this are the empty elements mspace and mglyph. The mspace element's width depends upon its attribute values. The mglyph element renders using the character described by its attributes.

While all Unicode character data is valid in token element content, MathML 2.0 distinguishes a special subset of named Unicode 3.2 characters, called MathML characters in this document. The complete list of MathML characters is defined in Chapter 6 Characters, Entities and Fonts. MathML characters can be either represented directly as Unicode character data, or indirectly via numeric or character entity references. See Chapter 6 Characters, Entities and Fonts for a discussion of the advantages and disadvantages of numeric character references versus entity references. New mathematics characters that arise, or non-standard glyphs for existing MathML characters, may be represented by means of the mglyph element.

Apart from the mglyph element, the malignmark element is the only other element allowed in the content of tokens. See Section 3.5.5 Alignment Markers for details.

Token elements (other than mspace and mglyph) should be rendered as their content (i.e. in the visual case, as a closely-spaced horizontal row of standard glyphs for the characters in their content). Rendering algorithms should also take into account the mathematics style attributes as described below, and modify surrounding spacing by rules or attributes specific to each type of token element.

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 3.2 contains more than nine hundred Math Alphanumeric Symbol characters corresponding to letter-like symbols. These characters are in the Secondary Multilingual Plane (SMP). See Chapter 6 Characters, Entities and Fonts for more information. As valid Unicode data, these characters are permitted in MathML 2.0, and as tools and fonts for them become widely available, we anticipate they will be the predominant way of denoting letter-like symbols.

MathML 2.0 also provides an alternative encoding for these characters using only Basic Multilingual Plane (BMP) characters together with markup. MathML 2.0 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 next section discusses the mathvariant attribute in more detail, and a complete technical description of the corresponding characters is given in Section 6.5 Mathematical Alphanumeric Symbols.

3.2.2 Mathematics style attributes common to token elements

MathML 2.0 introduces four new mathematics style attributes. These attributes are valid on all presentation token elements except mspace and mglyph, and on no other elements except mstyle. The attributes are:

Name	values	default
mathvariant	normal \| bold \| italic \| bold-italic \| double-struck \| bold-fraktur \| script \| bold-script \| fraktur \| sans-serif \| bold-sans-serif \| sans-serif-italic \| sans-serif-bold-italic \| monospace \| initial \| tailed \| looped \| stretched	normal (except on `<mi>`)
mathsize	small \| normal \| big \| number v-unit	inherited
mathcolor	#rgb \| #rrggbb \| html-color-name	inherited
mathbackground	#rgb \| #rrggbb \| html-color-name	inherited

(See Section 2.1.3 MathML Attribute Values for terminology and notation used in attribute value descriptions.)

The mathematics style attributes define logical classes of token elements. Each class is intended to correspond to a collection of typographically-related symbolic tokens that have a meaning within a given math expression, and therefore need to be visually distinguished and protected from inadvertent document-wide style changes which might change their meanings.

When MathML rendering takes place in an environment where CSS is available, the mathematics style attributes can be viewed as predefined selectors for CSS style rules. See Section 7.4 Using CSS with MathML and Appendix C Sample CSS Style Sheet for MathML for further discussion and a sample CSS style sheet. When CSS is not available, it is up to the internal style mechanism of the rendering application to visually distinguish the different logical classes.

Renderers have complete freedom in mapping mathematics style attributes to specific rendering properties. However, in practice, the mathematics style attribute names and values suggest obvious typographical properties, and renderers should attempt to respect these natural interpretations as far as possible. For example, it is reasonable to render a token with the mathvariant attribute set to "sans-serif" in Helvetica or Arial. However, rendering the token in a Times Roman font could be seriously misleading and should be avoided.

It is important to note that only certain combinations of character data and mathvariant attribute values make sense. For example, there is no clear cut rendering for a 'fraktur' alpha, or a 'bold italic' Kanji character. By design, the only cases that have an unambiguous interpretation are exactly the ones that correspond to SMP Math Alphanumeric Symbol characters, which are enumerated in Section 6.5 Mathematical Alphanumeric Symbols. The mathvariant values "initial", "tailed", "looped" and "stretched" are expected to apply only to Arabic characters. In all other cases, it is suggested that renderers ignore the value of the mathvariant attribute if it is present. Similarly, authors should refrain from using the mathvariant attribute with characters that do not have SMP counterparts, since renderings may not be useful or predictable. In the very rare case that it is necessary to specify a font variant for other characters or symbols within an equation, external styling mechanisms such as CSS are generally preferable, or in the last resort, the deprecated style attributes of MathML 1 could be used.

Token elements also permit xml:id, xref, class and style attributes for compatibility with style sheet mechanisms, as described in Section 2.1.4 Attributes Shared by all MathML Elements. However, some care must be taken when using CSS generally. Using CSS to produce visual effects that alter the meaning of an equation should be especially avoided, since MathML is used in many non-CSS environments. Similarly, care should be taken to insure arbitrary document-wide style transformations do not affect mathematics expressions in such a way that meaning is altered.

Since MathML expressions are often embedded in a textual data format such as XHTML, the surrounding text and the MathML must share rendering attributes such as font size, so that the renderings will be compatible in style. For this reason, most attribute values affecting text rendering are inherited from the rendering environment, as shown in the "default" column in the table above. (In cases where the surrounding text and the MathML are being rendered by separate software, e.g. a browser and a plug-in, it is also important for the rendering environment to provide the MathML renderer with additional information, such as the baseline position of surrounding text, which is not specified by any MathML attributes.) Note, however, that MathML 2.0 doesn't specify the mechanism by which style information is inherited from the rendering environment. For example, one browser plug-in might choose to rely completely on the CSS inheritance mechanism and use the fully resolved CSS properties for rendering, while another application might only consult a style environment at the root node, and then use its own internal style inheritance rules.

Most MathML renderers will probably want to rely on some degree to additional, internal style processing algorithms. In particular, inheritance of the mathvariant attribute does not follow the CSS model. The default value for this attribute is "normal" (non-slanted) for all tokens except mi. For mi tokens, the default depends on the number of characters in tokens' content. (The deprecated fontslant attribute also behaves this way.) See Section 3.2.3 Identifier (mi) for details.

3.2.2.1 Deprecated style attributes on token elements

The MathML 1.01 style attributes listed below have been deprecated in MathML 2.0. In rendering environments that support CSS, it is preferable to use CSS to control the rendering properties corresponding to these attributes. However as explained above, direct manipulation of these rendering properties by whatever means should usually be avoided.

If both a new mathematics style attribute and conflicting deprecated attributes are given, the new math style attribute value should be used. For example

<mi fontweight='bold' mathvariant='normal'> a </mi>

should render in a normal weight font, and

<mi fontweight='bold' mathvariant='sans-serif'> a </mi>

should render in a normal weight sans serif font. In the example

<mi fontweight='bold' mathvariant='fraktur'> a1 </mi>

the mathvariant attribute still overrides fontweight attribute, even though "fraktur" generally shouldn't be applied to a '1' since there is no corresponding SMP Math Alphanumeric Symbol character. In the absence of fonts containing Fraktur digits, this would probably render as a Fraktur 'a' followed by a Roman '1' in most renderers.

The new mathematics style attributes also override deprecated 1.01 style attribute values that are inherited. Thus

<mstyle fontstyle='italic'>
  <mi mathvariant='bold'> a </mi>
</mstyle>

renders in a bold upright font, not a bold italic font.

At the same time, the MathML 1.01 attributes still serve a purpose. Since they correspond directly to rendering properties needed for mathematics layout, they are very useful for describing MathML layout rules and algorithms. For this reason, and for backward compatibility, the MathML rendering rules suggested in this chapter continue to be described in terms of the rendering properties described by these MathML 1.01 style attributes.

The deprecated attributes are:

Name	values	default
fontsize	number v-unit	inherited
fontweight	normal \| bold	inherited
fontstyle	normal \| italic	normal (except on `<mi>`)
fontfamily	string \| css-fontfamily	inherited
color	#rgb \| #rrggbb \| html-color-name	inherited

The fontsize attribute specifies the desired font size. v-unit represents a unit of vertical length (see Section 2.1.3.3 CSS-compatible attributes). The most common unit for specifying font sizes in typesetting is pt (points).

If the requested size of the current font is not available, the renderer should approximate it in the manner likely to lead to the most intelligible, highest quality rendering.

Many MathML elements automatically change fontsize in some of their children; see the discussion of scriptlevel in the section on mstyle, Section 3.3.4 Style Change (mstyle).

The value of the fontfamily attribute should be the name of a font that may be available to a MathML renderer, or information that permits the renderer to select a font in some manner; acceptable values and their meanings are dependent on the specific renderer and rendering environment in use, and are not specified by MathML (but see the note about css-fontfamily below). (Note that the renderer's mechanism for finding fonts by name may be case-sensitive.)

If the value of fontfamily is not recognized by a particular MathML renderer, this should never be interpreted as a MathML error; rather, the renderer should either use a font that it considers to be a suitable substitute for the requested font, or ignore the attribute and act as if no value had been given.

Note that any use of the fontfamily attribute is unlikely to be portable across all MathML renderers. In particular, it should never be used to try to achieve the effect of a reference to a non-ASCII MathML character (for example, by using a reference to a character in some symbol font that maps ordinary characters to glyphs for non-ASCII characters). As a corollary to this principle, MathML renderers should attempt to always produce intelligible renderings for the MathML characters listed in Chapter 6 Characters, Entities and Fonts, even when these characters are not available in the font family indicated. Such a rendering is always possible – as a last resort, a character can be rendered to appear as an XML-style entity reference using one of the entity names given for the same character in Chapter 6 Characters, Entities and Fonts.

The symbol css-fontfamily refers to a legal value for the font-family property in CSS, which is a comma-separated list of alternative font family names or generic font types in order of preference, as documented in more detail in CSS[CSS2]. MathML renderers are encouraged to make use of the CSS syntax for specifying fonts when this is practical in their rendering environment, even if they do not otherwise support CSS. (See also the subsection CSS-compatible attributes within Section 2.1.3.3 CSS-compatible attributes).

3.2.2.2 Color-related attributes

The mathcolor (and deprecated color) attribute controls the color in which the content of tokens is rendered. Additionally, when inherited from mstyle or from a MathML expression's rendering environment, it controls the color of all other drawing by MathML elements, including the lines or radical signs that can be drawn by mfrac, mtable, or msqrt.

The values of mathcolor, color, mathbackground, and background can be specified as a string consisting of "#" followed without intervening whitespace by either 1-digit or 2-digit hexadecimal values for the red, green, and blue components, respectively, of the desired color. The same number of digits must be used for each component. No whitespace is allowed between the '#' and the hexadecimal values. The hexadecimal digits are not case-sensitive. The possible 1-digit values range from 0 (component not present) to F (component fully present), and the possible 2-digit values range from 00 (component not present) to FF (component fully present), with the 1-digit value x being equivalent to the 2-digit value xx (rather than x0).

These attributes can also be specified as an html-color-name, which is defined below. Additionally, the keyword "transparent" may be used for the background attribute.

The color syntax described above is a subset of the syntax of the color and background-color properties of CSS. The background-color syntax is in turn a subset of the full CSS background property syntax, which also permits specification of (for example) background images with optional repeats. The more general attribute name background is used in MathML to facilitate possible extensions to the attribute's scope in future versions of MathML.

Color values on either attribute can also be specified as an html-color-name, that is, as 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.

The suggested MathML visual rendering rules do not define the precise extent of the region whose background is affected by using the background attribute on mstyle, except that, when mstyle'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 mstyle, 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.

3.2.3 Identifier (`mi`)

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.

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

Name	values	default
mathvariant	normal \| bold \| italic \| bold-italic \| double-struck \| bold-fraktur \| script \| bold-script \| fraktur \| sans-serif \| bold-sans-serif \| sans-serif-italic \| sans-serif-bold-italic \| monospace \| initial \| tailed \| looped \| stretched	(depends on content; described below)
fontstyle (deprecated)	normal \| italic	(depends on content; described below)

A typical graphical renderer would render an mi element as the characters in its content, with no extra spacing around the characters (except spacing associated with neighboring elements). The default mathvariant and fontstyle would (typically) be "normal" (non-slanted) unless the content is a single character, in which case it would be "italic". Note that this rule for mathvariant and fontstyle attributes is specific to mi elements; the default value for the mathvariant and fontstyle attributes on other MathML token elements is "normal".

Note that for purposes of determining equivalences of Math Alphanumeric Symbol characters (See Section 6.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 ⁡ operator (which also has the short name ⁡) 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> ... </mi>
  <mo> + </mo>
  <mi> n </mi>
</mrow>

When an mi is used in such exceptional situations, explicitly setting the fontstyle 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>

Use of special entity references for such constants can simplify the interpretation of MathML presentation elements. See Chapter 6 Characters, Entities and Fonts for a complete list of character entity references in MathML.

3.2.4 Number (`mn`)

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.

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

A typical graphical renderer would render an mn element as the characters of its content, with no extra spacing around them (except spacing from neighboring elements such as mo). Unlike mi, mn elements are (typically) rendered in an unslanted font by default, regardless of their content.

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 Operator, Fence, Separator or Accent (`mo`)

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.

The term "operator" as used in the present chapter means any symbol or notation that should render as an operator, and that is therefore representable by an mo element. That is, the term "operator" includes any ordinary operator, fence, separator, or accent unless otherwise specified or clear from the context.

All such symbols are represented in MathML with mo elements since they 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.

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. Most attributes get their default values from the Section 3.2.5.7.1 The operator dictionary, as described later in this section. When a dictionary entry is not found for a given mo element, the default value shown here in parentheses is used.

Name	values	default
form	prefix \| infix \| postfix	set by position of operator in an `mrow` (rule given below); used with `mo` content to index operator dictionary
fence	true \| false	set by dictionary (false)
separator	true \| false	set by dictionary (false)
lspace	number h-unit \| namedspace	set by dictionary (thickmathspace)
rspace	number h-unit \| namedspace	set by dictionary (thickmathspace)
stretchy	true \| false	set by dictionary (false)
symmetric	true \| false	set by dictionary (true)
maxsize	number [ v-unit \| h-unit ] \| namedspace \| infinity	set by dictionary (infinity)
minsize	number [ v-unit \| h-unit ] \| namedspace	set by dictionary (1)
largeop	true \| false	set by dictionary (false)
movablelimits	true \| false	set by dictionary (false)
accent	true \| false	set by dictionary (false)

h-unit represents a unit of horizontal length, and v-unit represents a unit of vertical length (see Section 2.1.3.2 Attributes with units). namedspace is one of "veryverythinmathspace", "verythinmathspace", "thinmathspace", "mediummathspace", "thickmathspace", "verythickmathspace", or "veryverythickmathspace". These values can be set by using the mstyle element as is further discussed in Section 3.3.4 Style Change (mstyle).

If no unit is given with maxsize or minsize, the number is a multiplier of the normal size of the operator in the direction (or directions) in which it stretches. These attributes are further explained below.

Typical graphical renderers show all mo elements as the characters of their content, with additional spacing around the element determined from the attributes listed above. Detailed rules for determining operator spacing in visual renderings are described in a subsection below. As always, MathML does not require a specific rendering, and these rules are provided as suggestions for the convenience of implementors.

Renderers without access to complete fonts for the MathML character set may choose not to render an mo element as precisely the characters in its content in some cases. For example, <mo> ≤ </mo> might be rendered as <= to a terminal. However, as a general rule, renderers should attempt to render the content of an mo element as literally as possible. That is, <mo> ≤ </mo> and <mo> <= </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 <=.)

Issue linebreak-op wiki (member only)

linebreak operators

Issue linebreak-op	`wiki (member only)`
linebreak operators
Line breaks typically occur before or after operators (including fences and separators). We could add an attribute linebreakstyle to specify information to the automatic linebreaking algorithm about the preferred method of linebreaking around an operator. The potential values are: before, after, duplicate The default for these values could be specified in the operator dictionary. As with other mo attributes, this value can be set by using the mstyle element. To be useful, there needs to be a level of indirection so the general behavior could be changed easily without having to list a new value for all operators. One such possibility is to define three additional attributes: operatorlinebreakstyle, separatorlinebreakstyle, and fencelinebreakstyle. The problem with this idea is it breaks the simple model used to find default values for mo attributes.
Resolution	None recorded

Line breaks typically occur before or after operators (including fences and separators). We could add an attribute linebreakstyle to specify information to the automatic linebreaking algorithm about the preferred method of linebreaking around an operator. The potential values are: before, after, duplicate

The default for these values could be specified in the operator dictionary. As with other mo attributes, this value can be set by using the mstyle element. To be useful, there needs to be a level of indirection so the general behavior could be changed easily without having to list a new value for all operators. One such possibility is to define three additional attributes: operatorlinebreakstyle, separatorlinebreakstyle, and fencelinebreakstyle. The problem with this idea is it breaks the simple model used to find default values for mo attributes.

Resolution None recorded

3.2.5.3 Examples with ordinary operators

<mo> + </mo>
<mo> &#x3C;<!--LESS-THAN SIGN--> </mo>
<mo> &#x2264;<!--LESS-THAN OR EQUAL TO--> </mo>
<mo> &#x3C;<!--LESS-THAN SIGN-->= </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 entity references used for these "invisible operators" are:

Full name	Short name	Examples of use

3 Presentation Markup