3. Presentation Markup

• 3.1 Introduction
  • 3.1.1 What Presentation Elements Represent
  • 3.1.2 Terminology Used In This Chapter
  • 3.1.3 Required Arguments
  • 3.1.4 Elements with Special Behaviors
  • 3.1.5 Summary of Presentation Elements
• 3.2 Token Elements
  • 3.2.1 Attributes common to token elements
  • 3.2.2 <mi> -- identifier
  • 3.2.3 <mn> -- number
  • 3.2.4 <mo> -- operator, fence, or separator
  • 3.2.5 <mtext> -- text
  • 3.2.6 <mspace/> -- space
  • 3.2.7 <ms> -- string literal
• 3.3 General Layout Schemata
  • 3.3.1 <mrow> -- horizontally group any number of subexpressions
  • 3.3.2 <mfrac> -- form a fraction from two subexpressions
  • 3.3.3 <msqrt> and <mroot> -- form a radical
  • 3.3.4 <mstyle> -- style change
  • 3.3.5 <merror> -- enclose a syntax error message from a preprocessor
  • 3.3.6 <mpadded> -- adjust space around content
  • 3.3.7 <mphantom> -- make content invisible but preserve its size
  • 3.3.8 <mfenced> -- surround content with a pair of fences
• 3.4 Script and Limit Schemata
  • 3.4.1 <msub> -- attach a subscript to a base
  • 3.4.2 <msup> -- attach a superscript to a base
  • 3.4.3 <msubsup> -- attach a subscript-superscript pair to a base
  • 3.4.4 <munder> -- attach an underscript to a base
  • 3.4.5 <mover> -- attach an overscript to a base
  • 3.4.6 <munderover> -- attach an underscript-overscript pair to a base
  • 3.4.7 <mmultiscripts> -- attach prescripts and tensor indices to a base
• 3.5 Tables and Matrices
  • 3.5.1 <mtable> -- table or matrix
  • 3.5.2 <mtr> -- row in a table or matrix
  • 3.5.3 <mtd> -- one entry in a table or matrix
  • 3.5.4 <maligngroup/> and <malignmark/> -- alignment markers
• 3.6 Enlivening Expressions
  • 3.6.1 <maction> -- bind actions to a subexpression

3.1 Introduction

This chapter specifies the "presentation" elements of MathML, which can be used to describe the layout structure of mathematical notation. It is strongly recommended that one read Section 2.3 on MathML syntax and grammar before reading Chapter 3. Section 2.3 contains important information on MathML notations and conventions which are necessary for understanding some of the material in this chapter.

3.1.1 What Presentation Elements Represent

Presentation elements correspond to the "constructors" of traditional math notation -- that is, to the basic kinds of symbols and expression-building structures out of which any particular piece of traditional math notation is built. They are designed to be medium-independent, in the sense that there are sensible ways to render them in audio, as well as in traditional visual media for math. Because of the importance of traditional visual notation, the descriptions of which notational constructs the elements represent, and how they are typically rendered, is often given here in visual terms. However, the elements have been designed to contain enough information for good spoken renderings as well, provided the conventions described herein for their proper use are followed. 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).

One major anticipated use of MathML is to describe mathematical expressions within HTML documents, using multiple MathML expressions embedded in some manner in an HTML document. Note that HTML in general describes logical structures such as headings, paragraphs, etc. but only suggests (i.e. does not require) specific ways of rendering various logical parts of the document, in order to allow for medium-dependent rendering and for individual preferences of style; MathML presentation elements are fully compatible with this philosophy. 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 math 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 subexpressions 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 math, 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 extended characters, represented by entity references, are used to name operators or identifiers which in traditional notation render the same as other symbols, such as "&DifferentialD;", "&ExponentialE;", or "&ImaginaryI;", or operators which usually render invisibly, such as "&InvisibleTimes;", "&ApplyFunction;", or "&InvisibleComma;". 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 "&ApplyFunction;" 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.

3.1.2 Terminology Used In This Chapter

The MathML specification uses a number of technical terms to describe MathML-specific rules and conventions. The most notable example is the attribute value notations and conventions described in Section 2.3.3. (See also the brief description of XML terminology in Section 2.3.1.)

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

Types of presentation elements

The presentation elements are divided into two classes. Token elements represent individual symbols, names, numbers, labels, etc. and can have only characters and entity references (or the vertical alignment element <malignmark/>) as content. 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 which 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 subexpressions are built into larger expressions. The terminology derives from the fact that each layout schema corresponds to a different way of "laying out" its subexpressions to form a larger expression in traditional mathematical typesetting.

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 the chapter. These elements are listed in Section 3.1.5. The content elements are the MathML elements defined in chapter 4. The content elements are listed in Section 4.4.

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 (listed in Section 5.2.2). A subexpression of an expression E is any MathML expression which is part of the content of E, whether directly or indirectly, i.e. whether it is a "child" of E or not.

A child of a layout schema is also called an argument of that element. Token elements have no arguments, by definition, even though they can contain the <malignmark/> element; this means that a <malignmark/> element in a token is not an argument, whereas in a layout schema it is one.

As a consequence of the above definitions, the content of a layout schema consists exactly of a sequence of zero or more nonoverlapping elements which are its arguments (possibly with intervening whitespace, which is ignored in MathML). Note that an argument is almost always a subexpression; the only exceptions are the empty elements <none/> and <mprescripts/> which are allowed only as special arguments of the <mmultiscripts> element, but are not subexpressions because they are not MathML expressions as defined above.

Descriptions of presentation elements

Each MathML presentation element is described below in detail. The description starts with the information needed by authors of MathML (or of programs which generate MathML). The intended use of each element is described, along with the argument syntax it accepts. (There is also a table of argument count requirements and argument roles in Section 3.1.3.) The valid attributes, along with their permissible and default values, are listed, and the effect of each attribute is discussed.

For certain elements, further information of interest mainly to those implementing MathML renderers is given in a subsection. This includes many details of one suggested set of rendering rules which can be used to render MathML expressions in a manner reminiscent of traditional visual notation.

3.1.3 Required Arguments

Many of the elements described herein require a specific number of arguments (always 1, 2, or 3). Recall that MathML uses the term argument to describe a child element with additional MathML-specific requirements, usually related to which position it occupies in its parent.

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. The descriptions, interpreted according to the convention just stated, fully specify the allowed numbers of arguments for every element defined in this Chapter. 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 0 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 they appear in. See Section 3.2.6 for a discussion of the proper use of such spacelike elements.

Inferred <mrow>s

The elements listed in the following table as requiring exactly 1 argument (<msqrt>, <mstyle>, <merror>, <mpadded>, <mphantom>, and <mtd>) actually accept any number of arguments, but 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.

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 which 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 exactly 1, since they are most naturally understood as acting on a single expression.

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. Recall that a required argument count of 1 may indicate an inferred <mrow>.

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 spacelike; these are defined in Section 3.2.6. This definition affects some of the suggested rendering rules for <mo> elements (Section 3.2.4).

Certain elements (e.g., <msup>) are able to embellish operators which are their first argument. These elements are listed in Section 3.2.4, 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.

The <mtable> element can infer <mtr>s around its arguments, and the <mtr> element can infer <mtd>s, as explained in the sections about those elements.

3.1.5 Summary of Presentation Elements

Token Elements:

General Layout Schemata:

Script and Limit Schemata:

Tables and Matrices:

Enlivening Expressions: