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 "ⅆ" or "ⅈ", 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.
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.
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:
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.
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.
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>.
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.
<MI> | identifier |
<MN> | number |
<MO> | operator |
<MF> | fence |
<MTEXT> | text |
<MSPACE/> | space |
<MS> | string literal |
<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 |
<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 |
<MTABLE> | table or matrix |
<MTR> | row in a table or matrix |
<MTD> | one entry in a table or matrix |
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.
Name | values | default | |
fontsize | number (points) | inherited | |
fontweight | plain | bold | inherited | |
fontslant | plain | italic | automatic | |
fontfamily | string | inherited | |
fontcolor | #rrggbb | inherited |
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.
<MI>x</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.
<MI>π</MI>
<MI>D</MI>
<MI>sin</MI>
<MROW>
<MI>sin</MI>
<MO>⁡</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>
Name | value | default | |
base | number | 10 |
(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>.)
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) |
See rendering rules common to operators and fences below for a discussion on the attributes.
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.
(a+b)
<MROW>
<MF>(</MF>
<MROW>
<MI>a</MI>
<MO>+</MO>
<MI>b</MI>
</MROW>
<MF>)</MF>
</MROW>
[0,1)
<MROW>
<MF>[</MF>
<MN>0</MN>
<MF>,</MF>
<MN>1</MN>
<MF>)</MF>
</MROW>
f(x,y)
<MROW>
<MI>f</MI>
<MO>⁡</MO>
<MROW>
<MF>(</MF>
<MI>x</MI>
<MF>,</MF>
<MI>y</MI>
<MF>)</MF>
</MROW>
</MROW>
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:
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 "+_{4} " in 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 as opposed to the default rendering as . This could also have been written using the <MSTYLE> element discussed below (see the example there).
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>→</MO> <MTEXT>maps to</MTEXT> </MOVER> <MI>y</MI> </MROW>This displays as . 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".
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 |
<MFRAC>
<MROW>
<MTEXT> &thickspace; </MTEXT>
<MI>a</MI>
</MROW>
<MI>b</MI>
</MFRAC>
Name | values | default | |
width | number (ems) | 0 | |
height | number (exs) | 0 | |
depth | number (exs) | 0 | |
background | #rrggbb | inherited |
See also the comments about "space-like elements" given under <MTEXT>.
As explained below, most text embedded in a mathematical expression should be marked up with <MTEXT>, or perhaps <MO> or <MI>, rather than <MS>.
Name | values | default | |
lquote | string | " | |
rquote | string | " |
<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: 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:
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.
<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.
Name | values | default | |
scriptlevel | number | automatic | |
displaystyle | true | false | automatic | |
scriptsizemultiplier | number | 0.71 | |
scriptminsize | number (pts) | 8 |
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:
<MSTYLE maxsize="1">
<MROW>
<MF>(</MF>
<MFRAC><MI>a</MI> <MI>b</MI></MFRAC>
<MF>)</MF>
</MROW>
</MSTYLE>
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).
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.
Name | values | default | |
width | number (ems) | same as content | |
height | number (exs) | same as content | |
depth | number (exs) | same as content |
See also the comments about "space-like elements" given under <MTEXT>.
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).
<MROW>
<MROW>
<MN>2</MN>
<MO> ⁢ </MO>
<MI>x</MI>
</MROW>
<MO> + </MO>
<MI>y</MI>
<MO> - </MO>
<MI>z</MI>
</MROW>
<MFRAC> numerator denominator </MFRAC>
Name | values | default | |
linethickness | number | 1 (rule thickness) |
<MSQRT> base </MSQRT>
<MROOT> base index </MROOT>
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, should be written as:
<MSUP>
<MROW>
<MF> ( </MF>
<MROW>
<MI>x</MI>
<MO> + </MO>
<MI>y</MI>
</MROW>
<MF> ) </MF>
</MROW>
<MN>2</MN>
</MSUP>
<MSUB> base subscript </MSUB>
Name | values | default | |
subscriptshift | number (exs) | automatic |
<MSUP> base superscript </MSUP>
Name | values | default | |
superscriptshift | number (exs) | automatic |
The usage for the <MSUBSUP> element is
<MSUBSUP> base subscript superscript </MSUBSUP>
Name | values | default | |
subscriptshift | number (exs) | automatic | |
superscriptshift | number (exs) | automatic |
would be represented as
<MROW>
<MSUBSUP>
<MO> ∫ </MO>
<MN> 0 </MN>
<MN> 1 </MN>
</MSUBSUP>
<MROW>
<MSUP>
<MI> ⅇ </MI>
<MI> x </MI>
</MSUP>
<MO> ⁢ </MO>
<MROW>
<MO> ⅆ </MO>
<MI>x </MI>
</MROW>
</MROW>
</MROW>
<MUNDER> base underscript </MUNDER>
Name | values | default | |
accentunder | true | false | false |
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 ∑.
<MOVER> base overscript </MOVER>
Name | values | default | |
accent | true | false | false |
These differences also affect lines:
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 ∑.
<MUNDEROVER> base underscript overscript </MUNDEROVER>
Name | values | default | |
accent | true | false | false | |
accentunder | true | false | false |
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 ∑.
<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>.
<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>
<MMULTISCRIPTS>
<MI>R</MI>
<MI>i</MI>
<NONE/>
<NONE/>
<MI>j</MI>
<MI>k</MI>
<NONE/>
<MI>l</MI>
<NONE/>
</MMULTISCRIPTS>
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 |
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.
Name | values | default | |
rowalign | top | bottom | center | baseline | axis | inherited | |
columnalign | (left | center | right)+ | inherited |
Name | values | default | |
rowspan | number | 1 | |
columnspan | number | 1 | |
rowalign | top | bottom | center | baseline | axis | inherited | |
columnalign | left | center | right | inherited |
The rowalign and columnalign attributes allow a specific
matrix element to override the alignment specified by a surrounding MTABLE
or MTR element.
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: