Working Draft 10-Jul-97

3. Presentation Tags

3.1 Introduction

This section describes the XML elements proposed as the "presentation language" for the core MathML.

3.1.1 What Presentation Elements Represent

Presentation elements correspond to the constructors of traditional math notation. They are intended to be medium-independent, in the sense that there are sensible ways to render them in audio, as well as in the traditional visual medium for math. Since traditional notation is mainly visual, the descriptions of which notational constructs the elements represent, and how they are typically rendered, is often given in visual terms. Some attributes may make sense only for visual media, although renderers for other media are encouraged to treat all attributes in some analogous way if possible.

Note that HTML in general specifies the logical structure of data, but only suggests (does not require) specific renderings for data, in order to allow for medium-independence and also for individual preferences of rendering, as well as to ease automatic processing of data; MathML presentation elements are fully compatible with this philosophy.

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 may be enclosed by nested <MROW> schema, and bases of superscripts are not just the rightmost character, but the full base. This structure allows for better quality renderings of math, especially when details of the rendering environment such as display widths are not known to the document author.

Certain extended characters (represented by entity references) are used to name operators or identifiers which in traditional notation render the same as other entities, such as "&DifferentialD;" or "&ImaginaryI;", or invisibly, such as "⁢", "⁡", "&MissingTerm;", or "⁣". These are distinct notational entities, as evidenced by their distinct spoken renderings and in some cases by their effects on line breaking and spacing in visual rendering, and as such should be represented by the appropriate specific entities.

The complete list of MathML entities is given in Chapter 6.

3.1.2 Types of Presentation Elements

The presentation elements are divided into two classes, "tokens" which have only #PCDATA as content, and "layout schema" which have only elements as content. There are also a few empty elements used only in conjunction with certain layout schema.

All tokens (in the syntactic sense) in a mathematical expression should be enclosed by MathML token tags. The primary MathML token types are identifiers (variables, function names, ...), numbers, operators, fences (e.g. a parenthesis), and string literals. There are also token elements for representing text or whitespace which has no mathematical meaning.

The layout schema are the constructors of expressions in traditional math notation. That is, expressions are recursively built out of layout schema. Except for a few special cases involving empty elements, the recursion terminates with tokens.

Each MathML presentation element is described below in detail. The valid attributes, along with their default values, are listed for each element. Examples are interspersed with the element and attribute descriptions. In formal discussions of SGML markup a distinction is maintained between an element, such as an MROW element, and the tags <MROW> and </MROW> marking it. What is between the <MROW> begin tag and the </MROW> end tag is the MROW element's content. An element such as NONE is defined to have no content and so has a single tag of the form </NONE>. The distinction between elements and tags will not be so finely drawn below. For instance, we may refer to the <MROW> and </NONE> elements , really meaning the elements whose tags they are.

3.1.3 XML Attribute Values

According to the XML-lang specification, attributes given to elements must have the form:

attr = "..."

where space around the '=' is optional. The attribute value must be quoted.

In XML, attribute values can be declared as strings, or they can be constrained in various ways, either by enumerating the options, or by declaring them to be some special tokenized data type. The choice of an XML attribute type affects the extent to which validity checks can be performed.

The MathML DTD specifies formal XML attribute types for all MathML attributes, including enumerations of legitimate values in some cases. In general, however, the MathML DTD is relatively permissive, frequently declaring attribute values as CDATA strings to provide for greater interoperability with SGML parsers.

At the same time, even though an attribute value may be declared as a string in the DTD, only certain values are meaningful, as described in this specification. For example, many attributes expect numerical values. In the sections which follow, the meaningful attribute values are described for each element. To determine when these constraints are actually enforced in the MathML DTD, consult Appendix A.

To indicate meaningful attribute values, the following conventions are used in the MathML specification:

Attribute values specified as number are allowed to be integers or floating-point numbers (i.e. digits with one decimal point), optionally preceded by a minus sign. For some attributes, only those in a subset of the expressible values are sensible, but values outside this subset are not errors, but rather are rounded up or down (at the discretion of the renderer) to the closest value within the allowed subset.
Attribute values that depend upon a font are given in font-related units. For example, the spacing around an operator such as "+" is given in "em"s. Using font-related units allows the expressions to grow or shrink proportionately to the current font size.

3.1.4 Collapsing of Whitespace in Input

Another technical detail involves whitespace between begin/end tags. By default, XML processors remove all leading and trailing whitespace (blanks, tabs, and newlines) between the begin/end tags and collapse any internal white space to a single space (" ") character. MathML uses this default behavior. Authors wishing to encode blanks, tabs, or newlines at the start or end of the content of a token, or in sequences of more than one, must use entity references for these characters.

3.1.5 Required Arguments

Many of the elements described herein require a specific number of arguments (always 1, 2, or 3). In the detailed discussions 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. All elements which allow an arbitrary sequence of arguments (e.g. MROW) allow that sequence to be empty. The preceding rules are intended to make the allowed numbers of arguments unambiguous for every element described herein.

MathML also contains a generic separator element, whose tag is <SEP/>, which is ignored in all presentation elements; unlike all other elements, it is not counted in determining the number or position of arguments for elements for which this matters.

3.1.6 Empty Elements

The only empty token element tag is <MSPACE/>. The empty element tags which can only occur inside certain layout schema are described with those layout schema; they are: <MPRESCRIPTS/>, <NONE/>

The <SEP/> empty element tag (generic to MathML) is ignored where ever it appears in presentation elements. It can appear only in layout schema, never in token elements, according to the XML DTD, since token elements contain only #PCDATA.

3.1.7 Elements with Special Behaviors

Certain elements are considered "space-like": <MTEXT>, <MSPACE/>, and <MPHANTOM>. This affects some of the rules for typical rendering behavior noted in various sections below.

Certain elements (e.g., <MOVER>) are able to embellish operators which are their first argument. The definition of "embellished operator" affects the rules for stretching of operators. These elements are listed in the section on <MO> and <MF>.

The element <MF> behaves almost exactly like <MO>, and both should be considered "operators" from the point of view of the rules for rendering embellished or stretchy operators, described in the section on <MO> and <MF>.

3.1.8 Attributes Shared by All MathML Entities

In order to facilitate compatibility with Cascading Style Sheets, Level 1 (CSS1 ) [Lie and Bos, 1996], all MathML elements accept CLASS and STYLE attributes. At present, many MathML properties that would be desirable to control via style sheets are not defined in CSS1. Conversely, CSS1 properties which are applicable to MathML may not be accessible to embedded MathML renderers in the immediate future. However, the CLASS and STYLE attributes provide some degree of compatibility now, and may provide much greater compatibility in the future.

There is a great deal of work underway on the problem of controlling the layout of XML extensions to HTML via style sheet mechanisms. The HTML-Math working group will be coordinating its efforts with other groups over the next year to insure that MathML will be compatible with emerging style sheet mechanisms.

3.1.9 Summary of Presentation Tags

Tokens:

<MI>	identifier
<MN>	number
<MO>	operator
<MF>	fence
<MTEXT>	text
<MSPACE/>	space
<MS>	string literal

General Layout Schema:

<MSTYLE>	style change
<MERROR>	encloses a syntax error message from a preprocessor
<MPHANTOM>	makes contents invisible but preserves their size
<MROW>	horizontally groups any number of subexpressions
<MFRAC>	forms a fraction from two subexpressions
<MSQRT>	forms a square root sign (radical without an index)
<MROOT>	forms a radical with specified index

Scripts, Limits and Accent Schema

<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>	attaches tensor-style indices to a base

Tables and Matrices:

<MTABLE>	table or matrix
<MTR>	row in a table or matrix
<MTD>	one entry in a table or matrix

3.2 Tokens

All tokens allow any sequence of 0 or more characters (or extended characters represented as entity references) as their content. In particular, tokens with no content are allowed. The allowed set of entity names for extended characters is given in Chapter 6.

Every character or entity reference allowed as content in the presentation elements of MathML must occur as part of the content of a token element.

3.2.1 <MI> -- identifier

Discussion

Identifiers include variables, function names, and symbolic constants. No extra spacing is added around identifiers by typical graphical renderers.

Attributes:

Name	values	default
fontsize	number (points)	inherited
fontweight	plain \| bold	inherited
fontslant	plain \| italic	automatic
fontfamily	string	inherited
fontcolor	#rrggbb	inherited

Most attribute values are inherited from the surrounding context. The surrounding context of a math element should be given by the browser to the program which is the implementor of the math element. The exception to the inheritance default is the font slant. Single character identifiers are typically drawn (by default) in an "italic" font; multiple character identifiers are drawn in a plain (non-slanted) font.

Future extensions should allow for other values for the font weight and font slant in keeping with whatever standard emerges for giving font attributes in HTML.

Examples:

<MI>x</MI>
<MI>π</MI>
<MI>D</MI>
<MI>sin</MI>

Identifiers include functions names such as "sin". Expressions such as "sin x" are written using the ⁡ (⁡ as a short name) operator as shown below. ⁡ typically renders as whitespace.

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

3.2.2 <MN> -- number

Discussion

Any token that is numeric. No extra spacing is added around numbers by typical graphical renderers. Unlike the case of <MI>, all <MN> tokens are typically rendered in an unslanted font.

Attributes:

The attributes for <MN> are same as those for <MI> together with:

	Name	value	default
	base	number	10

The base attribute is intended primarily for external processing applications that need to evaluate numerical expressions.

Examples:

3.2.3 <MO> -- operator

Description:

Any token that is an operator. These include infix, prefix, and postfix operators.

(Fences, i.e. bracketing tokens such as braces, parentheses, and "absolute-value" bars, and separators, such as comma and semi-colon, are represented with <MF>, not with <MO>.)

Attributes:

The attributes for <MO> are same as those for <MI> together with:

Name	values	default
lspace	number (ems)	set by dictionary (.2777777)
rspace	number (ems)	set by dictionary (.2777777)
stretchy	true \| false	set by dictionary (false)
symmetric	true \| false	set by dictionary (true)
maxsize	number \| infinity	set by dictionary (infinity)
minsize	number	set by dictionary (0)
largeop	true \| false	set by dictionary (false)
movablelimits	true \| false	set by dictionary (false)
form	prefix \| infix \| postfix	set by dictionary (rule given below)

The maxsize and minsize are given as multipliers of the font size.

See rendering rules common to operators and fences below for a discussion on the attributes.

Examples

3.2.4 <MF> -- fence

Discussion

Any token that is a fence, i.e. a member of a matched pair of bracketing tokens such as braces, parentheses, and "absolute-value" bars, or which is used to separate other expressions, such as a comma. Matched pairs of fences should be given as the first and last elements of an MROW, whose middle elements represent the expressions and the separators (if any) enclosed by the matched pair of fences.

Attributes:

The attributes for fences are same as for operators, except for movablelimits and largeop.

The form attribute for <MF> can have the values "open", "close", or "separator" for left, right, and middle fences respectively. The appropriate default value of this attribute is specified in the operator/fence dictionary for common fences.

See rendering rules common to operators and fences below for further discussion on the attributes.

Examples:

Some examples of expressions involving fences:

(a+b)

[0,1)

f(x,y)

3.2.4.1 Attributes and Rendering Rules Common to Operators and Fences

Typical visual rendering behaviors for operators and fences are essentially identical, and are more complex than for other tokens, so the rules for both are described in this separate section. 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. To help clarity attribute names will usually be given in bold when used in the explanatory text below; thus, for instance, lspace.

Many mathematical symbols such as an integral sign, a plus sign, or a parenthesis have a well-established, predictable, traditional notational usage. Typically, this usage amounts to certain default attribute values for either the <MO> or <MF> schema. Since these defaults vary from symbol to symbol, MathML anticipates that renderers will have a "dictionary" of default attributes for operators and fences (See Appendix C). If an operator or fence is not listed in the dictionary, the default values shown in parentheses in the table of attributes for <MO> should be used, since they are typically acceptable for a generic operator.

Some operators are overloaded in the sense that they can occur in more than one form (prefix, infix, or postfix; open, close, or separator for fences), with possibly different rendering properties for each form. For example, "+" can be either a prefix or an infix operator. Typically, a visual renderer would add space around both sides of an infix operator, while only on the left of a prefix operator. The "form" attribute allows specification of which form to use, in case more than one form is possible according to the operator dictionary. If there is more than one possible form and no form attribute is given, a renderer may choose what form to use. Typically, this would be determined as follows:

If the operator is the first direct subexpression in an <MROW> of length greater than one, not counting space-like elements (see <MTEXT> section), the prefix form is used;
if it is the last direct subexpression in an <MROW> of length greater than one, not counting space-like elements, the postfix form is used;
in all other cases, including when the operator is not part of an <MROW>, the infix version is used.

If the operator does not have attributes for the specified form in the dictionary, the renderer may use any of the forms which are available. All operators in the dictionary must have at least one possible form.

There is one exception to the above rules: an operator which is "embellished" by one or more nested subscripts, superscripts, surrounding text or whitespace, or style changes. It is the embellished operator as a whole whose position in an MROW is examined by the above rules and whose surrounding spacing is affected by its form, in a typical renderer, not the <MO> element itself. For example, the "+₄ " in [Graphics:presentationgr1.gif] should be considered an infix operator.

The precise definition of an embellished operator is: an <MO> or <MF> element; or one of the elements <MSTYLE>, <MPHANTOM>, <MSUB>, <MSUP>, <MSUBSUP>, <MUNDER>, <MOVER>, <MUNDEROVER>, <MMULTISCRIPTS>, or <MFRAC>, whose first subexpression exists and is an embellished operator; or an <MROW> element directly containing one embellished operator, whose other direct subexpressions are all space-like elements (see <MTEXT> section). Note that this definition permits nested embellishment only when there are no intervening enclosing elements not in the above list. Fences are included because this definition also affects the use of the stretchy attributes, which are present on both <MO> and <MF>.

The above rules are chosen so that in all ordinary cases it will not be necessary to specify a form attribute.

The amount of space added around an operator or fence when it occurs in an <MROW> can be specified by the lspace and rspace attributes. These numbers are given in ems. By convention, operators that tend to bind tightly to their arguments have smaller values for spacing than operators that tend to bind less tightly. This convention should be followed in the operator dictionary. In TeX, these values can only be one of three values; typically they are 3/18em, 4/18em, and 5/18em. MathML does not impose this limit. Non-graphical renderers should treat spacing attributes, and other rendering attributes described here, in analogous ways for their rendering medium.

Four attributes govern whether and how an operator or fence character stretches so that it matches the size of other elements: stretchy, symmetric, maxsize, and minsize. If an operator or fence has the attribute stretchy="true", then it obeys the stretching rules listed below, given the constraints imposed by the fonts and font rendering system. The minsize and maxsize attributes also limit the size. These two attributes are given as multipliers of the font's size. For example, if a character has maxsize="3", then it can grow to be no more than three times its normal 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). The symmetric attribute only applies to characters that stretch vertically.

Example: set maximum size of a parenthesis so that it does not grow even though its default value is stretchy="true".

<MROW>
  <MF maxsize="1"> ( </MF>
  <MFRAC><MI>a</MI><MI>b</MI></MFRAC>
  <MF maxsize="1"> ) </MF>
</MROW>

should render as [Graphics:presentationgr2.gif]

as opposed to the default rendering as [Graphics:presentationgr3.gif]

. This could also have been written using the <MSTYLE> element discussed below (see the example there).

Vertical Stretching Rules:

If a stretchy operator or fence is a direct subexpression of an <MROW>, or is the sole direct subexpression of an <MTD> in an <MTR>, then it should stretch to cover the height and depth (above and below the axis) of the non-stretchy subexpressions in the <MROW> or <MTR> element, given the constraints mentioned above. This applies even if the <MTD> and/or <MTR> were inferred, as described in the <MTABLE> section.
If symmetric="true", then the maximum of the height and depth is used to determine the size before application of the minsize or maxsize attributes.

By default, most open and close fences stretch vertically. Also, operators such as ∑, ∫, /, and vertical arrows stretch by default.

Horizontal Stretching Rules:

If a stretchy operator is a direct subexpression of an <MUNDER>, <MOVER>, <MUNDEROVER>, or if it is the sole direct subexpression of an <MTD>, then it should stretch to cover the width of the other subexpressions in the given element (or in the same matrix column, in the case of a matrix), given the constraints mentioned above. This applies even if the <MTD> was inferred, as described in the <MTABLE> section.

By default, most horizontal arrows and some accents stretch horizontally.

If a stretchy operator is not required to stretch (i.e. if it is not in one of the locations mentioned above, or if there are no other expressions whose size it should stretch to match), then it has the standard (unstretched) size determined by the font.

If a stretchy operator is required to stretch, but all other expressions in the containing element are also stretchy, all elements that can vertically stretch should grow to (approximately) the maximum of the normal (unstretched) sizes of all elements in the containing entity, if they can grow that large. If the value of minsize or maxsize prevents this then that (max or min) size is used.

For example, in an MROW containing nothing but stretchy operators, each of the operators should stretch to the maximum of their normal (unstretched) sizes, provided no other attributes are set which override this behavior. Of course, limitations in fonts or font rendering may result in the final, stretched sizes being only approximately the same.

The rules for the horizontal stretchiness inside scripts make the following work:

<MROW>
  <MI>x</MI>
  <MOVER>
    <MO>&RightArrow;</MO>
    <MTEXT>maps to</MTEXT>
  </MOVER>
  <MI>y</MI>
</MROW>

This displays as [Graphics:presentationgr4.gif]

. The rules for matrices allow arrows to stretch for use in commutative diagrams laid out as matrices.

The largeop attribute specifies whether the operator should be drawn large if displaystyle="true" and scriptlevel="0". This corresponds to TeX's \displaystyle; MathML uses two attributes (displaystyle and scriptlevel) to control orthogonal presentation features that TeX encodes into one "style" attribute with values \displaystyle, \textstyle, \scriptstyle, and \scriptscriptstyle. MathML's scriptlevel attribute is discussed further in the section describing the <MSTYLE> element. Examples of large operators include ∫ and ∏.

The movablelimits attribute specifies whether underscripts and overscripts should be drawn as subscripts and superscripts when the scriptlevel attribute is > 0 or displaystyle="false". Movablelimits="false" means that underscripts and overscripts should never be drawn as subscripts and superscripts. By default, displaystyle="true" for displayed math and displaystyle="false" for inline math. Thus, operators with movablelimits="true" will display with limits (i.e., underscripts and overscripts) in displayed math and with subscripts and superscripts in inline math. Examples of operators that typically have movablelimits="true" are ∑, ∏, and "lim".

3.2.5 <MTEXT> -- text

Description:

An <MTEXT> token can be used to represent arbitrary text which should be rendered as itself, but which should not affect in any way the mathematical content of the containing expression.

This element is often used to contain "renderable whitespace", i.e., invisible characters which 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 which consists of blanks, newlines, and tabs. Blanks, newlines, and tabs present directly in the source are collapsed, according to the rules of an XML parser; they must be represented by entity references if it is desired to avoid this collapsing.

Renderable whitespace can have a positive or negative width as in "&thinspace;" and "&negativethinspace;", or zero width as in "&zerowidthspace;". The complete list of such characters is given in section 6. Note that there is no formal distinction in MathML between renderable whitespace characters and any other kinds of characters, in <MTEXT> or in any other element.

Renderable whitespace can also include characters that affect alignment or line breaking. Some of these characters include:

entity name purpose (rough description)

NewLine start a new line -- don't indent

IndentingNewLine start a new line -- indent

NoBreak do not allow a linebreak here

GoodBreak if a linebreak is needed on the line, here is a good spot

BadBreak if a linebreak is needed on the line, try to avoid breaking here

AlignmentMarker align this vertically with the same character in adjacent lines

For the complete list of MathML entities, and a discussion of their use, consult Chapter 6.

Attributes:

Same as for identifier.

Use of Space-like Elements

Use of "space-like elements", i.e. <MTEXT>, <MSPACE/>, or <MPHANTOM>, as arguments of some element which requires a specific number of arguments, or interprets different argument positions differently, does not permit that element to have the wrong number of arguments or to interpret the argument positions abnormally (e.g. by ignoring the occupation of an argument position by a space-like element). Instead, space-like elements should be grouped with a neighboring element by introducing an <MROW> for that purpose. For example:

<MFRAC>
    <MROW>
        <MTEXT> &thickspace; </MTEXT>
        <MI>a</MI>
    </MROW>
    <MI>b</MI>
</MFRAC>

Examples:

    <MTEXT>Theorem 1:</MTEXT>
    <MTEXT>&thinspace;</MTEXT>
    <MTEXT>&alignmentmarker;&thickspace; </MTEXT>
    <MTEXT>/* a comment */</MTEXT>

3.2.6 <MSPACE/> -- space

Description:

An <MSPACE/> empty element represents a blank space of any desired size, as set by its attributes. The default value for each attribute is 0, so it will not be useful without some attributes specified.

Attributes:

Name	values	default
width	number (ems)	0
height	number (exs)	0
depth	number (exs)	0
background	#rrggbb	inherited

The <MSPACE/> element should not be used to "tweak" the spacing used by renderers. Different renderers may use different spacings and tweaking the spacing for one renderer may produce very poor results in other renderers. In the future, renderer-specific changes will be possible using the style sheet mechanism.

See also the comments about "space-like elements" given under <MTEXT>.

3.2.7 <MS> -- string literal

Description:

<MS> is used to represent "string literals" in expressions meant to be interpreted by computer algebra systems or other systems with "programming languages". No extra spacing is added around rendered string literals, but they are typically rendered with surrounding double quotes. <MS>, like all elements, does collapse whitespace in its content according to the rules of XML, so blanks, tabs, or newlines in the content should be encoded as entity references.

As explained below, most text embedded in a mathematical expression should be marked up with <MTEXT>, or perhaps <MO> or <MI>, rather than <MS>.

Attributes:

Same as for identifier along with

Name	values	default
lquote	string	"
rquote	string	"

By default, string literals are displayed surrounded by double quotes. The characters used can be changed with the lquote and rquote attributes.

Examples:

Most text embedded in math may seem like a string literal at first glance. However, it is usually the case that it is more correctly represented (and will be better displayed) as an operator, identifier, or <MTEXT> element. For example, the expression " [Graphics:presentationgr5.gif]

" is equivalent to " [Graphics:presentationgr6.gif]

" and can be represented as:

<MROW>
   <MO> there exists </MO>
   <MROW>
      <MROW>
           <MI> δ</MI>
           <MO> ></MO>
           <MN> 0</MN>
      </MROW>
       <MO> such that</MO>
      <MROW>
          <MROW>
               <MI>f</MI>
               <MO>⁡</MO>
              <MROW>
                   <MF>(</MF>
                   <MI>x</MI>
                   <MF>)</MF>
              </MROW>
          </MROW>
          <MO>< </MO>
          <MN>1</MN>
      </MROW>
   </MROW>
</MROW>

An example involving a <MI> tag is: [Graphics:presentationgr7.gif] In this example, ellipsis should be represented using an <MI> element, since it takes the place of a term in the sum.

As a final example, expository text (which is probably best not included in a math element at all), is best represented with an <MTEXT> element. An example of this is:
[Graphics:presentationgr9.gif] [Graphics:presentationgr8.gif]

In this example, "Theorem 1:" can use an <MTEXT> element. The "If" and "then" together mean "implies" and thus might use an operator element. However, they too might be considered ordinary text. 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.

3.3 General Layout Schema

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

3.3.1 <MSTYLE> -- style changes

Description:

These elements allow any single element as their content.

<MSTYLE> is used to make style changes in its content. The changes affect the context inherited by all contained subexpressions except where overridden by some automatic or explicit change to some attribute, as discussed for each element individually.

Attributes:

All attributes can be given. In addition to those listed for any specific elements:

Name	values	default
scriptlevel	number	automatic
displaystyle	true \| false	automatic
scriptsizemultiplier	number	0.71
scriptminsize	number (pts)	8

scriptlevel is an extension of TeX's \displaystyle, \scriptstyle, etc. scriptlevel is automatically incremented by various elements which typically display some or all of their arguments in smaller type, including elements for scripts, fractions, roots, and matrices. The scriptlevel attribute works with the scriptsizemultiplier and scriptminsize attributes to adjust font sizes used for displaying scripts. A scriptsizemultiplier="1" would cause scripts never to shrink. Any automatic script size change is limited by scriptminsize. This prevents scripts from becoming unreadably small.

The example of limiting the stretchiness of a parenthesis shown in the section on rendering rules for <MO> and <MF> can be rewritten using <MSTYLE> as:

Note that the width, height, and depth attributes, defined on <MPHANTOM>, can be given on <MSTYLE> to change its rendered size in the same way as for <MPHANTOM>. If they are made smaller than the normal rendered values for the content (which can depend on the renderer), the content is "clipped" (not shrunk), on the top, bottom, or right edges for height, depth, and width respectively. If they are made larger, extra space is added on the same edges; the content is not "stretched". For audio renderers, duration corresponds to horizontal space (width).

3.3.2 <MERROR> -- encloses an error message

Description:

Display the contents as a syntax 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.

The intent of this element is to provide a way for other applications that generate MathML from other input to report on syntax errors. Since one of the planned extension mechanisms for MathML is to allow preprocessors to parse alternative input syntaxes designed for easy hand entry, it is important that preprocessors have the ability to indicate that a syntax error occurred at a certain point, by replacing the erroneous part of the input with an <MERROR> element containing a description of the error, while processing the surrounding expressions normally; this makes it easier for an author to determine from the rendered output what portion of the input was in error.

Attributes:

None (except attributes allowed for all elements)

3.3.3 <MPHANTOM> -- content used only for its size

Description:

<MPHANTOM> renders invisibly, but with the same size and other dimensions (such as baseline position) that its contents would have if they were rendered normally. Like all space-like elements (see <MTEXT>), it has no mathematical meaning. <MPHANTOM> can be used to align parts of an expression by invisibly duplicating subexpressions.

Attributes:

Name	values	default
width	number (ems)	same as content
height	number (exs)	same as content
depth	number (exs)	same as content

The attributes can be used to change the dimensions to some other value. This is useful mainly to set certain dimensions to 0. height and depth specify the extent above and below the baseline respectively. Setting the width, height, or depth to 0 is useful for forcing horizontal (or vertical) alignment without affecting vertical (or horizontal) alignment.

See also the comments about "space-like elements" given under <MTEXT>.

3.3.4 <MROW> -- horizontally group any number of subexpressions

Description:

An <MROW> is used to horizontally group any number of subexpressions. Subexpressions should be grouped by the document author in a manner similar to some notion of an underlying syntax tree. Operators and their arguments should occur in a single <MROW>; more than one operator should occur in one <MROW> only when the operators are in the same group in the operator dictionary (see Appendix C) and can be considered to act together on the interleaved arguments (e.g. for chains of relational operators). Matching fences, and the expressions and separators they directly enclose, should be the elements of a single <MROW>. In all other cases, nested <MROW>s should be used.

These rules for grouping are conventional; although the choice of grouping will affect details of the appearance and possibly of subsequent interpretation, any grouping is allowed.

Proper grouping has three purposes: it improves display (affects spacing); it allows for intelligent linebreaking and indentation; it simplifies possible semantic interpretation of presentation by computer algebra systems or macro packages (including interpretation which is helpful for audio rendering).

Attributes:

None (except attributes allowed for all elements)

Examples:

As an example, [Graphics:presentationgr10.gif]

should be written as:

3.3.5 <MFRAC> -- form a fraction from two subexpressions

Description:

This schema 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>

Attributes

	Name	values	default
	linethickness	number	1 (rule thickness)

A fraction with linethickness="0" might be used for binomials. A linethickness greater than one might be used with nested fractions. These cases are shown below:
[Graphics:presentationgr9.gif]

3.3.6 <MSQRT> and <MROOT> -- form a radical

Description:

These schema draw radicals. The <MSQRT> schema is used for square roots, while the <MROOT> schema is used to draw radicals with indices, e.g. a cube root. The usage for these schema is

<MSQRT> base </MSQRT>
<MROOT> base index </MROOT>

Attributes:

None.

3.4 Scripts and Limits Schema

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

In addition to sub/superscript schema, over/underscript elements place scripts above and below the base. These elements can be used to place limits on large operators, or for placing accents and lines above or below the base. The rules for rendering accents differ from those for overscripts and underscripts, and this difference can be controlled with the accent and accentunder attributes, as described in the appropriate sections below.

MathML also provides a schema for tensor indices. Tensor indices are distinct from ordinary sub- and superscripts in that they must align in vertical columns. Tensor indices can also occur in prescript positions.

Because presentation tags should be used to describe the abstract notational structure of expressions, it is important that the base expression in all scripting schema should be the entire expression that is being scripted, not just the rightmost character. For example, [Graphics:presentationgr12.gif] should be written as:

3.4.1 <MSUB> -- attach a subscript to a base

Description:

The usage for the <MSUB> element is

<MSUB> base subscript </MSUB>

Attributes:

	Name	values	default
	subscriptshift	number (exs)	automatic

The subscriptshift attribute specifies the minimum amount to shift the baseline of subscript down.

3.4.2 <MSUP> -- attach a superscript to a base

Description:

The usage for the <MSUP> element is

<MSUP> base superscript </MSUP>

Attributes:

	Name	values	default
	superscriptshift	number (exs)	automatic

The superscriptshift attribute specifies the minimum amount to shift the baseline of superscript up.

3.4.3 <MSUBSUP> -- attaches a sub- and superscript pair to a base

Description:

The <MSUBSUP> element is used so that the subscript and superscript are both tight against the base, i.e. vertically aligned as in the second case shown here:
[Graphics:presentationgr9.gif]

The usage for the <MSUBSUP> element is

<MSUBSUP> base subscript superscript </MSUBSUP>

Attributes:

Name	values	default
subscriptshift	number (exs)	automatic
superscriptshift	number (exs)	automatic

Examples:

One use of the <MSUBSUP> element is for placing limits on certain large operators (as embellishments). For example, the integral
[Graphics:presentationgr9.gif]

would be represented as

3.4.4 <MUNDER> -- attach an underscript to a base

Description:

The usage for the <MUNDER> element is

<MUNDER> base underscript </MUNDER>

Attributes:

	Name	values	default
	accentunder	true \| false	false

The accentunder attribute controls whether underscript is drawn as an "accent" or as a limit. These differences are described in the <MOVER> section. Below is an example (accent vs underscript):
[Graphics:presentationgr9.gif]

If the base is an operator with movablelimits="true", and displaystyle="false" or scriptlevel > 0, then underscript is drawn in a subscript position. This is often used for limits on symbols such as ∑.

3.4.5 <MOVER> -- attach an overscript to a base

Description:

The usage for the <MOVER> element is

<MOVER> base overscript </MOVER>

Attributes:

	Name	values	default
	accent	true \| false	false

The accent attribute controls whether overscript is drawn as an accent or as a limit. The main difference between an accent and a limit is that the limit is reduced in size whereas an accent (i.e. diacritical mark) is the same size as the base. A second difference is that the diacritical mark is drawn closer to the base. This is shown below (accent vs limit):
[Graphics:presentationgr9.gif]

These differences also affect lines:
[Graphics:presentationgr9.gif] [Graphics:presentationgr17.gif]

If the base is an operator with movablelimits="true", and displaystyle="false" or scriptlevel > 0, then overscript is drawn in a superscript position. This is often used for limits on symbols such as ∑.

3.4.6 <MUNDEROVER> -- attach an under- and overscript pair to a base

Description:

The usage for the <MUNDEROVER> element is

<MUNDEROVER> base underscript overscript </MUNDEROVER>

Attributes:

Name	values	default
accent	true \| false	false
accentunder	true \| false	false

The <MUNDEROVER> element is used 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 example below:
[Graphics:presentationgr9.gif]

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.

If the base is an operator with movablelimits="true", and displaystyle="false" or scriptlevel > 0, then underscript and overscript are drawn in a subscript and superscript position. This is often used for limits on symbols such as ∑.

3.4.7 <MMULTISCRIPTS> -- attach prescripts and tensor indices to a base

Description:

The usage for the <MMULTISCRIPTS> element is

<MMULTISCRIPTS> base postscriptpairs [ <MPRESCRIPTS/> prescriptpairs ] </MMULTISCRIPTS>

Presubscripts and tensor notations are represented by a single element, <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 (to the right of the base in visual notation) and prescripts (to the left of the base in visual notation). 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 given in a left-to-right order. 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 arguments to 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, if it follows <MPRESCRIPTS/>, 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 elements <MPRESCRIPTS/> and <NONE/> are only allowed as direct arguments to <MMULTISCRIPTS>.

Attributes:

Same as <MSUBSUP>.

Examples:

Two examples of the use of <MMULTISCRIPTS> are:
[Graphics:presentationgr9.gif]

<MROW>
    <MMULTISCRIPTS>
        <MI>F</MI>
        <MN>1</MN>
        <NONE/>
        <MPRESCRIPTS/>
        <MN>0</MN>
        <NONE/>
    </MMULTISCRIPTS>
    <MO>⁡</MO>
    <MROW>
        <MF>(</MF>
        <MF>;</MF>
        <MI>a</MI>
        <MF>;</MF>
        <MI>z</MI>
        <MF>)</MF>
    </MROW>
</MROW>
[Graphics:presentationgr9.gif] [Graphics:presentationgr20.gif]

3.5 Tables and Matrices

Matrices, arrays and other table-like mathematical notation are marked up using <MTABLE>, <MTR> and <MTD> tags. These elements are similar to the <TABLE>, <TR> and <TD> elements of HTML, except that they provide substantially more attributes in order to provide the fine layout control necessary for commutative diagrams, block matrices and so on.

3.5.1 <MTABLE> -- table or matrix

Description:

A matrix or table is specified using the <MTABLE> element. Inside of the <MTABLE> element, <MTR> and <MTD> elements can be given. If some argument to <MTABLE> is not a <MTR> element, renderers should assume a one-column row (i.e. the argument is effectively wrapped with an inferred <MTR> begin-end tag pair). Similarly, if some argument to a (possibly inferred) <MTR> element is not a <MTD> element, that argument should be treated as a matrix entry by effectively wrapping it with an inferred <MTD> begin-end tag pair. Matrix rows that have fewer columns than other rows of the same matrix (whether the other rows precede or follow them) are effectively padded on the right with invisible elements so that the number of columns equals the maximum number of columns in any of the <MTR> elements in that matrix.

Attributes:

Name	values	default
align	top \| bottom \| center \| baseline \| axis	axis
rowalign	(top \| bottom \| center \| baseline \| axis)+	baseline
columnalign	(left \| center \| right)+	center
rowspacing	(number)+ (exs)	1.0
columnspacing	(number)+ (ems)	0.8
rowlines	(none \| solid \| dashed)+	none
columnlines	(none \| solid \| dashed)+	none
frame	none \| solid \| dashed	none
framespacing	number number (ems exs)	"0.4 0.5"
equalrows	true \| false	true
equalcolumns	true \| false	true

Note: the notation "(x | y)+" means one or more occurrences of either x or y, separated with whitespace. For example, possible values for columnalign are "left", "left left", and "left right center center" If there are more entries than are necessary (e.g., more entries than columns for columnalign), then only the first entries will be used. If there are fewer entries, then the last entry is repeated as often as necessary. For example, if columnalign="right center" and the matrix has three columns, the first column will be right aligned and the second and third columns will be centered.

The align attribute specifies where to align the matrix with respect to its environment. "axis" means to align the center of the matrix on the environment's axis. (The axis of an equation is an alignment line used by typesetters. It is the line on which a minus sign typically lies.) "center" and "baseline" both mean to align the center of the matrix on the environment's baseline. "top" or "bottom" aligns the top or bottom of the matrix on the environment's baseline.

The rowalign attribute specifies how the entries in each row should be aligned. For example, "top" means that the tops of each entry in each row should be aligned with the tops of the other entries in that row. The columnalign attribute specifies how the entries in each column should be aligned.

The rowspacing and columnspacing attributes specify how much space should be added between each row and column. However, spacing before the first row and after the last row (i.e. at the top and bottom of the matrix) is given by the second number in the value of the framespacing attribute, and spacing before the first column and after the last column (i.e. on the left and on the right of the matrix) is given by the first number in the value of the framespacing attribute.

The rowlines and columnlines attributes specify whether and what kind of lines should be added between each row and column. Lines before the first row or column and after the last row or column are given using the frame attribute.

If a frame is desired around the matrix, the frame attribute is used. If the attribute value is not "none", then framespacing is used to add spacing between the lines of the frame and the first and last rows and columns of the matrix. If frame="none", then the framespacing attribute is ignored. The frame and framespacing attributes are not part of the rowlines/columnlines, rowspacing/columnspacing options because having them be so would often require that rowlines and columnlines would need to be fully specified instead of just giving a single value. For example, if a matrix had five columns and we wanted lines between the columns, but no frame, then we would have to write columnlines="none solid solid solid solid none". By separating the frame from the internal lines, we only need to write columnlines="solid".

The equalrows attribute (if true) forces the rows all to be the same total height. The equalcolumns attribute (if true) forces the columns all to be the same width.

3.5.2 <MTR> -- row in a table or matrix

Description:

This element is only valid within an <MTABLE> element and specifies that the contents should be a row of the matrix.

Attributes:

Name	values	default
rowalign	top \| bottom \| center \| baseline \| axis	inherited
columnalign	(left \| center \| right)+	inherited

The rowalign and columnalign attributes allow a specific row to override the alignment specified by the same attributes in the surrounding MTABLE element.

3.5.3 <MTD> -- element in a table or matrix

Description:

This element is only allowed within an <MTR> element (perhaps an inferred one).

Attributes:

Name	values	default
rowspan	number	1
columnspan	number	1
rowalign	top \| bottom \| center \| baseline \| axis	inherited
columnalign	left \| center \| right	inherited

The rowspan and columnspan attributes allow a specific matrix element to be treated as if it occupied the number of rows or columns specified. The interpretation of how this larger element affects specifying subsequent rows and columns is meant to correspond with the similar attributes for HTML 3.2 tables.

The rowalign and columnalign attributes allow a specific matrix element to override the alignment specified by a surrounding MTABLE or MTR element.

3.5 Enlivening Text

3.6.1 <MACTION> -- binding actions

Authors can make links from MathML subexpressions by using the standard HTML <A HREF="..."> construction, as described in section 7.1.4. However, links are only one of many ways which specific renderers might provide authors for making math notation active. For example, in lengthy mathematical expressions, the ability to "fold" expressions might be provided, i.e. a renderer might allow a reader to toggle between an ellipsis and a much longer expression which it represents.

To provide a mechanism for binding actions to expressions, MathML proposes the <MACTION> tag. The MACTION element accepts any number of subexpressions as arguments, and a single actiontype attribute with a string value. By default, renderers which do not recognize the specified action type should render the first argument (if any are present).

It is worth noting that in order to be fully MathML compliant, a renderer need only implement the default behavior.

A suggested list of action types and usages might include:

<MACTION actiontype="toggle"> (first expression) (second expression)... </MACTION>

For this action type, a renderer would alternately display the given expressions, cycling through them when a reader clicked on the active expression. Typical uses would be for exercises in education, ellipses in long computer algebra output, or to illustrate alternate notations. Note that the expressions may be of significantly different size, so that size negotiation with the browser may be desirable. If size negotiation is not available, scrolling, elision, panning, or some other method may be necessary to allow full viewing.

<MACTION actiontype="statusline"> (expression) (message) </MACTION>

In this case, the renderer would display the expression in context on the screen. When a reader clicked on the expression or moved the mouse over it, the renderer would send a rendering of the message to the browser statusline. Presumably authors would use plain text in an <MTEXT> construct for the message in most circumstances. For non-<MTEXT> messages, renderers may provide a natural language translation of the markup.

<MACTION actiontype="tooltip"> (expression) (message) </MACTION>

Here the renderer would also display the expression in context on the screen. When the mouse pauses over the expression for a long enough delay time, the renderer displays a rendering of the message in a pop-up "tooltip" box near the expression. These message boxes are also sometimes called "ballon help" boxes. Presumably authors would use plain text in an <MTEXT> construct for the message in most circumstances. For non-<MTEXT> messages, renderers may provide a natural language translation of the markup.

<MACTION actiontype="foregroundhighlight" other="color='#ff0000'"> expression </MACTION> <MACTION actiontype="backgroundhighlight" other="color='#ff0000'"> expression </MACTION>

In this case, a renderer might highlight the enclosed expression on a "mouse-over" event. In the example given above, use is being made of the "other" attribute to pass a color to a specific renderer as well. The "foregroundhighlight" version changes the color of the characters in the presentation, while the "backgroundhighlight" changes the color of the background behind the characters.

<MACTION actiontype="menu" > (menu item 1) (menu item 2) ... </MACTION>

This action type instructs a renderer to provide a pop up menu. This allows a one to many linking capability. Note that the menu items may be other <MACTION actiontype="menu">...</MACTION> expressions, thereby allowing nested menus.

entity name	purpose (rough description)
NewLine	start a new line -- don't indent
IndentingNewLine	start a new line -- indent
NoBreak	do not allow a linebreak here
GoodBreak	if a linebreak is needed on the line, here is a good spot
BadBreak	if a linebreak is needed on the line, try to avoid breaking here
AlignmentMarker	align this vertically with the same character in adjacent lines