To be effective, MathML must work well with a wide variety of renderers, processors, translators and editors. This chapter raises some of the interface issues involved in generating and rendering MathML. Since MathML exists primarily to encode mathematics in Web documents, perhaps the most important interface issues are related to embedding MathML in [HTML4] and [XHTML], and in any newer HTML when it appears.
There are three kinds of interface issues that arise in embedding MathML in other XML documents. First, MathML must be semantically integrated. MathML markup must be recognized as valid embedded XML content, and not as an error. This could be seen as primarily a question of managing namespaces in XML [Namespaces]. However, the implementation of XML namespaces and their management has not been well supported by recent commercial software. So there have grown up other ways of dealing with 'foreign content' in an XML document which is viewed as of a particular type.
Second, in the case of HTML/XHTML, MathML rendering must be integrated with browser software. Some browsers already implement MathML rendering natively, and one can expect more browsers will do so in the future. At the same time, other browsers have developed infrastructure to facilitate the rendering of MathML and other embedded XML content by thirdparty software or other builtin technology. Examples of this builtin technology are the sophisticated CSS rendering engines now available, and the powerful implementations of ECMAscript (or JavaScript) that are becoming common. Using these browserspecific mechanisms generally requires additional interface markup of some sort to activate them. In the case of CSS, there is a special restricted form of MathML3 tailored for use with presentday CSS, up to CSS2.1, which is specified in "A MathML for CSS profile" [MathMLforCSS]. This does not offer the full expressiveness afforded by MathML3 but provides a portable simpler form that can be rendered acceptably on the screen by modern CSS engines.
Third, other tools for generating and processing MathML must be able to communicate. A number of MathML tools have been or are being developed, including editors, translators, computer algebra systems, and other scientific software. However, since MathML expressions tend to be lengthy, and prone to error when entered by hand, special emphasis must be given to ensuring that MathML can be easily generated by userfriendly conversion and authoring tools, and that these tools work together in a dependable, platform and vendor independent way.
This chapter applies to both content and presentation MathML and indicates
a particular processing model to the semantics
, annotation
and annotationxml
elements defined in Section 5.1 Semantic Annotations.
Within an XML document supporting namespaces [XML], [Namespaces],
the preferred method to recognize
MathML markup is by the identification of the math
element
in the appropriate namespace, i.e. that
of URI http://www.w3.org/1998/Math/MathML
.
This is the recommended method to embed MathML within [XHTML] documents. Some useragents' setup may require supplementary information to be available.
Markuplanguage specifications that wish to embed MathML may provide special conditions or recognizing MathML independently of this recommendation. The conditions should be similar to those expressed in this recommendation and the elements' localnames should remain the same.
Although rendering MathML expressions often occurs in place in a Web browser, other MathML processing functions take place more naturally in other applications. Particularly common tasks include opening a MathML expression in an equation editor or computer algebra system. It is important therefore to specify the encoding names with which MathML fragments should be called.
Outside of the conditions of an XML environment where namespaces are recognized, media types [RFC2045], [RFC2046] should be used if possible to to ensure the invocation of a MathML processor. In the cases where media types are not usable, for example in some clipboard environments, the names described in the next section should be used.
Issue mimetypesforpandc  wiki (member only) 

Different mediatypes for presentation and content?  
Different mediatypes for generic, presentation, and content MathML are wished by some group members but not others. The current section describes the alternative where a mediatype for generic, presentation, and content MathML exist. 

Resolution  None recorded 
MathML contains two distinct vocabularies: one for encoding mathematical semantics defined in Chapter 4 Content Markup and one for encoding visual presentation defined in Chapter 3 Presentation Markup. Some MathMLaware applications import and export only one of these vocabularies, while other may be capable of producing and consuming both. The following three encoding names should be used to distinguish between content and presentation MathML when needed.
MathML Presentation: Instance contains presentation MathML markup only
Windows Flavor Name: MathML Presentation
Media Type: application/mathmlpresentation+xml
Universal Type Identifier: public.mathml.presentation
MathML Content: Instance contains content MathML markup only
Windows Flavor Name: MathML Content
Media Type:application/mathmlcontent+xml
Universal Type Identifier: public.mathml.content
MathML (generic): Any wellformed MathML instance presentation markup, content markup, or a mixture of the two is allowed
Windows Flavor Name:MathML
Media Type: application/mathml+xml
Filename extension:.mml
Universal Type Identifier: public.mathml
See Appendix B Media Types Registrations for more details about each of the encoding names.
Supplementary to these names, the clipboard flavor names MathMLContent
,
and MathMLPresentation
have been used and are now deprecated;
moreover, in MathML 1.0, the mediatype text/mathml
was
suggested, this has been superceded by [RFC3023].
MathML expressions are often exchanged between applications using the familiar copyandpaste or draganddrop paradigms and sometimes are stored in files or exchanged over the HTTP protocol. This section provides recommended ways to process MathML while applying these transfers.
The transfers of MathML fragments are between the contexts of two applications by making them available in several flavors, often called media types, clipboard formats or data flavors. These flavors are ordered by preference. The copyandpaste paradigm lets applications place content in a central clipboard, one datastream per clipboard format; consuming applications negotiate by choosing to read the data of the format they elect. The draganddrop paradigm lets application offer content by declaring the available formats and potential recipients accept or reject a drop based on this list; the drop action then lets the receiving application request the delivery of the format in the indicated format. HTTP GET transfers, as in [HTTP11], let clients submit a list of accepted mediatypes and the server deliver the appropriate data indicating the chosen mediatype. HTTP POST transfers, as in [HTTP11], let client submit the data with the accepted mediatype.
Current desktop platforms offer copyandpaste and draganddrop using similar
transfer architectures with varying naming depending on the platform.
HTTP transfers are all based on mediatypes.
In this section we specify what applications should
provide as transfer types, how they should be named, and how they should handle
the special semantics
, annotation
, and annotationxml
elements.
To summarize the three negotiation mechanisms, we shall, here, be talking of flavors, each having a name (a character string) and a content (a stream of binary data), which are offered, accepted, exported.
Note that the names indicated in Section 6.2.3 Names of MathML Encodings are the exact strings that should be used to describe the flavors corresponding to the encodings. On operating systems that allow such, applications should register such names (e.g. a call to Windows' RegisterClipboardFormat on launch or, on the Macintosh platform, the declaration of the support for the universal type in the application descriptor).
When transferring MathML, for example when placing it within a clipboard, an application MUST ensure the content is a wellformed XML instance of a MathML schema. Specifically:
The instance MUST begin with a XML declaration, e.g. <?xml version="1.0">
The instance MUST contain exactly one root math
element.
Since MathML is frequently embedded within other XML document
types, the instance MUST declare the MathML namespace
on the root math
element. In addition, the instance MAY use a
schemaLocation
attribute on the math
element to indicate
the location of MathML schema documents against which the instance is valid.
Note that the presence of the schemaLocation
attribute does not require a
consumer of the MathML instance to obtain or use the cited schema documents.
The instance MUST use numeric character references (e.g. α) rather than character entity names (e.g. α) for greater interoperability.
The character encoding for the instance MUST be either specified in the XML header, UTF16, or UTF8. UTF16encoded data MUST begin with a byteorder mark (BOM). If no BOM or encoding is given, the character encoding will be assumed to be UTF8.
Applications that transfer MathML SHOULD adhere to the following conventions:
Applications that have pure presentation markup and/or pure content markup versions of an expression SHOULD offer as many of these two flavors as are available.
Applications that only export one MathML flavor should name it MathML
if they don't know its nature. If they do, they should offer both the generic
and specific transfer types but should only deliver the specific types if they know the
recipient will support it.
For the HTTP GET transfer, this means that the specific transfer types (presentation, content)
should only be returned if the Accept
HTTP header includes it.
Applications that export the two specific transfer types should export the
content and presentation transfer types as well as the generic flavor
which combines the two others using a toplevel
MathML's semantics
element (see
Section 5.4.1 Toplevel Parallel Markup).
When an application exports a MathML fragment whose only child of the root element is
a semantics
element, it SHOULD offer, after the flavors above in the preference order,
a flavor for each annotation
or annotationxml
element that
has a clipboardflavor
attribute:
the flavor name should be given by the clipboardflavor
attribute value of the
annotation
or annotationxml
element,
and the content should be the child text in the surrounding encoding (if the annotation
element contains only textual data), a valid XML fragment (if the annotationxml
element contains children), or the data resulting of requesting the URL
given by the href
attribute.
Useragents implementors should be aware that the fragments contained in the clipboard could be used in a insecure way: indeed, opening a fragment in a receiving application will execute the programmes it contains, for example embedded scripts, and this without the traditional security restrictions of webcontent. Useragent implementors should, thus, only allow transfer of safe content flavors, maybe resorting to a sanitization process.
As a final fallback applications MAY export a version of the data in plaintext
flavor (such as text/plain
, CF_UNICODETEXT
,
UnicodeText
, NSStringPboardType
, ...).
When an application has multiple versions of an expression available, it
may choose the version to export as text at its
discretion. Since some older MathMLaware programs expect MathML
instances transferred as text to begin with a math
element, the text version should generally omit the XML
declaration, DOCTYPE declaration and other XML prolog material before
the math
element. Similarly, the BOM should be omitted for
Unicode text encoded as UTF16. Note, the Unicode text version of the
data should always be the last flavor exported,
following the principle that exported flavors should be ordered
with the most specific flavor first and the least specific flavor
last.
For purposes of determining whether a MathML instance is pure
content markup or pure presentation markup, the math
element
and the semantics
, annotation
and
annotationxml
elements should be regarded as belonging to
both the presentation and content markup vocabularies. This is
obvious for the root math
element which is required for all
MathML expressions. However, the semantics
element and its
child annotation elements comprise an arbitrary annotation mechanism
within MathML, and are not tied to either presentation or content
markup. Consequently, applications consuming MathML should always
process these four elements even if the application only implements
one of the two vocabularies.
It is worth noting that the above recommendations allow agents producing
MathML to provide binary data for the clipboard, for example as an image
or an applicationspecific format.
The sole method to do so is to reference the binary data by the href
attribute since XML character data does not allow arbitrary bytestreams.
While the above recommendations are intended to improve interoperability between MathMLaware applications utilizing the transfer features, it should be noted that they do not guarantee interoperablility. For example, references to external resources (e.g. stylesheets, etc.) in MathML data can also cause interoperability problems if the consumer of the data is unable to locate them, just as can happen when cutting and pasting HTML or many other data types. Applications that make use of references to external resources are encouraged to make users aware of potential problems and provide alternate ways for obtaining the referenced resources. In general, consumers of MathML data containing references they cannot resolve or do not understand should ignore them.
An eLearning application has a database of quiz questions, some of which contain MathML. The MathML comes from multiple sources, and the eLearning application merely passes the data on for display, but does not have sophisticated MathML analysis capabilities. Consequently, the application is not aware whether a given MathML instance is pure presentation or pure content markup, nor does it know whether the instance is valid with respect to a particular version of the MathML schema. It therefore places the following data formats on the clipboard:
Flavor Name  Flavor Content 

MathML 
<?xml version="1.0"?> <math xmlns="http://www.w3.org/1998/Math/MathML">...</math> 
Unicode Text 
<math xmlns="http://www.w3.org/1998/Math/MathML">...</math> 
An equation editor is able to generate pure presentation markup, valid with respect to MathML 3. Consequently, it exports the following flavors:
Flavor Name  Flavor Content 

MathML Presentation 
<?xml version="1.0"?> <math xmlns="http://www.w3.org/1998/Math/MathML">...</math> 
Tiff 
(a rendering sample) 
Unicode Text 
<math xmlns="http://www.w3.org/1998/Math/MathML">...</math> 
A schemabased content management system contains multiple MathML representations of a collection of mathematical expressions, including mixed markup from authors, pure content markup for interfacing to symbolic computation engines, and pure presentation markup for print publication. Due to the system's use of schemas, markup is stored with a namespace prefix. The system therefore can transfer the following data:
Flavor Name  Flavor Content 

MathML Presentation 
<?xml version="1.0"?> <mml:math xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance" xsi:schemaLocation="http://www.w3.org/Math/XMLSchema/mathml3/mathml3.xsd"> <mml:mrow> ... <mml:mrow> </mml:math> 
MathML Content 
<?xml version="1.0"?> <mml:math xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance" xsi:schemaLocation="http://www.w3.org/Math/XMLSchema/mathml3/mathml3.xsd"> <mml:apply> ... <mml:apply> </mml:math> 
MathML 
<?xml version="1.0"?> <mml:math xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance" xsi:schemaLocation="http://www.w3.org/Math/XMLSchema/mathml3/mathml3.xsd"> <mml:mrow> <mml:apply> ... content markup within presentation markup ... </mml:apply> ... </mml:mrow> </mml:math> 
TeX 
{x \over x1} 
Unicode Text 
<mml:math xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance" xsi:schemaLocation="http://www.w3.org/Math/XMLSchema/mathml3/mathml3.xsd"> <mml:mrow> ... <mml:mrow> </mml:math> 
A similar content management system is webbased and delivers MathML representations of mathematical expressions. The system is able to produce presentation MathML, content MathML, TeX and pictures in PNG format. In webpages being browsed, it could produce a MathML fragment such as the following:
<mml:math xmlns:mml="http://www.w3.org/1998/Math/MathML"> <mml:semantics> <mml:mrow>...</mml:mrow> <mml:annotationxml encoding="MathML Content">...</mml:annotationxml> <mml:annotation clipboardflavor="TeX">{1 \over x}</mml:annotation> <mml:annotation clipboardflavor="image/png" href="formula3848.png"/> </mml:semantics> </mml:math>
A webbrowser that receives such a fragment and tries to export it as part of a draganddrop action, can offer the following flavors:
Flavor Name  Flavor Content 

MathML Presentation 
<?xml version="1.0"?> <mml:math xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance" xsi:schemaLocation="http://www.w3.org/Math/XMLSchema/mathml3/mathml3.xsd"> <mml:mrow> ... <mml:mrow> </mml:math> 
MathML Content 
<?xml version="1.0"?> <mml:math xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance" xsi:schemaLocation="http://www.w3.org/Math/XMLSchema/mathml3/mathml3.xsd"> <mml:apply> ... <mml:apply> </mml:math> 
MathML 
<?xml version="1.0"?> <mml:math xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance" xsi:schemaLocation="http://www.w3.org/Math/XMLSchema/mathml3/mathml3.xsd"> <mml:mrow> <mml:apply> ... content markup within presentation markup ... </mml:apply> ... </mml:mrow> </mml:math> 
TeX 
{x \over x1} 
image/png 
(the content of the picture file, requested from formula3848.png 
Unicode Text 
<mml:math xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance" xsi:schemaLocation="http://www.w3.org/Math/XMLSchema/mathml3/mathml3.xsd"> <mml:mrow> ... <mml:mrow> </mml:math> 
MathML is usually used in combination with other markup languages. The most typical case is perhaps the use of MathML within a documentlevel markup language, such as XHTML or DocBook. It is also common that other objectlevel markup languages are also included in a compound document format, such as the W3C XHTML+MathML+SVG profile. Other common use cases include mixing other markup within MathML. For example, an authoring tool might insert an element representing a cursor position or other state information within MathML markup, so that an author can pick up editing where he or she left off.
Most document markup languages have some concept of an inline
equation, (or graphic, object, etc.) so there is a typically a natural
and welldefined way to incorporate MathML instances into the content
model. However, in the other direction, embedding of markup within
MathML is not so clear cut, since in many MathML elements, the role of
child elements is defined by positionally. For example, the first
child of an apply
must be an operator, and the second child
of an mfrac
is the denominator. The proper behavior when
foreign markup appears in such contexts is problematic. Even when such
behavior can be defined in a particular context, it presents an
implementation challenge for generic MathML processors.
For this reason, by default, the MathML schema does not allow foreign markup elements to be included within MathML instances. However, a lax schema is also provided for use in specific compound document formats where the behavior of mixed markup can be welldefined, and where the implementation of specialized user agents can be justified. Note that this is not uncommon, particularly when the allowed mixing is minimal.
In the default schema profile, no element from other namespaces are allowed, but attributes from other namespaces are allowed. MathMLprocessors that encounter unknown XML markup should behave as follows:
Attributes from nonMmathML namespaces should be silently ignored.
An element from a nonMathML namespaces should be treated
as an error. If the element is a child of a presentation
element, should be handled as described in
Section 3.3.5 Error Message <merror>
. If the element is a child of a content
element should be handled as described in
Section 4.2.9 Error Markup <cerror>
.
For example, if the second child of an mfrac
is an
unknown element, the fraction should be rendered with a denominator
indicating an error.
Under the lax schema profile, elements nonMathML namespaces are allowed in token elements, but not in other elements. This restriction on the location of elements from other namespaces largely eliminates the issues of positionally defined roles for elements in MathML, while still providing some flexibility for compound documents. Attributes from other namespaces are also allowed. MathMLprocessors that encounter unknown markup should behave as follows:
Unrecognized XML attributes should be silently ignored.
Unrecognized elements in token XML elements should be silently ignored.
An element from a nonMathML namespaces should be treated
as an error. If the element is a child of a presentation
element, should be handled as described in
Section 3.3.5 Error Message <merror>
. If the element is a child of a content
element should be handled as described in
Section 4.2.9 Error Markup <cerror>
.
Considerations about mixing markup vocabularies in compound documents arise when the format is first designed. But once the format is fixed, it is not generally practical for specific software tools to further modify the content model to suit their needs. However, it is still frequently the case that such tools may need to persist additional information within a MathML instance. Since MathML is most often generated by authoring tools, a particularly common and important case is an authoring tool needing persist some information about its internal state along with a MathML expression, so that an author can pick up editing where he or she left off. For example, placeholders are often used to indicate incomplete parts of an expression, and a cursor position within an expression is sometimes persisted.
Applications needing to persist private data within MathML expressions should generally attempt to do so without altering the underlying content model, even in situations where it is feasible to do so. To support this, regardless of what may be allowed by the content model of a particular compound document format, MathML always permits the persistance of private data via the following strategies:
For small amounts of data, attributes from other namespaces are allows on all MathML elements.
For larger amounts of data, applications may use the
semantics
element presented in Section 5.1 Semantic Annotations.
For authoring tools and other applications needing to
associate particular actions with presentation MathML subtrees,
e.g. to mark an incomplete expression to be filled in by an author,
the maction
element may be used. See Section 3.7.1 Bind Action to SubExpression
<maction>
.
In order to fully integrate MathML into XHTML, it should be possible not only to embed MathML in XHTML, as described in Section 6.2.1 Recognizing MathML in an XML Model, but also to embed XHTML in MathML. However, the problem of supporting XHTML in MathML presents many difficulties. Therefore, at present, the MathML specification does not permit any XHTML elements within a MathML expression, although this may be subject to change in a future revision of MathML.
In most cases, XHTML elements (headings, paragraphs, lists, etc.) either do not apply in mathematical contexts, or MathML already provides equivalent or better functionality specifically tailored to mathematical content (tables, mathematics style changes, etc.). However, there are two notable exceptions, the XHTML anchor and image elements. For this functionality, MathML relies on the general XML linking and graphics mechanisms being developed by other W3C Activities.
While the use of namespaces to embed MathML in other XML
applications is completely described by the relevant W3C
Recommendations, a certain degree of pragmatism is still called for at
present. Support for XML, namespaces and rendering behaviors in
popular user agents is not always fully in alignment with W3C
Recommendations.
When using namespace prefixes with MathML markup, use m:
as a
conventional prefix for the MathML namespace. Using an explicit
prefix is probably safer for compatibility in current user agents.
For example:
<body> ... <m:math xmlns:m="http://www.w3.org/1998/Math/MathML"> <m:mrow>...<m:mrow> </m:math> ... </body>
Consult the W3C Math Working Group home page for compatibility and implementation suggestions for current browsers and other MathMLaware tools.
In MathML 3, an element is designated as a link by the presence of
the href
attribute. MathML has no element that corresponds
to the HTML/XHTML anchor element a.
MathML allows the href
attribute on all
elements. However, links on elements that do not correspond to any
part of a typical visual rendering should be avoided, since they will
have no effect in typical user agents.
The list of presentation markup elements that do not ordinarily have a visual rendering, and thus should not be used as linking elements, is given in the table below.
MathML elements that should not be linking elements  

mprescripts 
none 
malignmark 
maligngroup 
Note that MathML 2 had no direct support for linking, and followed
the W3C Recommendation "XML Linking Language" [XLink] in
defining links using an xlink:href
attribute. This has
changed, and MathML 3 now uses the href
attribute for
linking. However, particular compound document formats may specify
the use of XML Linking with MathML elements. So, user agents that
implement XML Linking in compound documents containing MathML should
continue to support the use of the xlink:href
attribute
with MathML 3 as well.
For compound document formats that use XML Linking or other
formatspecific linking mechanisms, the id
attribute should
be used to specify locations for links into a MathML expressions. The
id
attribute is allowed on all elements, and values must be
unique within the document, making it ideal for the this purpose.
Apart from the introduction of new glyphs, many of the situations where one might be inclined to use an image amount to displaying labeled diagrams. For example, knot diagrams, Venn diagrams, Dynkin diagrams, Feynman diagrams and commutative diagrams all fall into this category. As such, their content would be better encoded via some combination of structured graphics and MathML markup. However, at the time of this writing, it is beyond the scope of the W3C Math Activity to define a markup language to encode such a general concept as "labeled diagrams." (See http://www.w3.org/Math for current W3C activity in mathematics and http://www.w3.org/Graphics for the W3C graphics activity.)
One mechanism for embedding additional graphical content is via the
semantics
element, as in the following example:
<semantics> <apply> <intersect/> <ci>A</ci> <ci>B</ci> </apply> <annotationxml encoding="SVG1.1"> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 290 180"> <clipPath id="a"> <circle cy="90" cx="100" r="60"/> </clipPath> <circle fill="#AAAAAA" cy="90" cx="190" r="60" style="clippath:url(#a)"/> <circle stroke="black" fill="none" cy="90" cx="100" r="60"/> <circle stroke="black" fill="none" cy="90" cx="190" r="60"/> </svg> </annotationxml> <annotationxml encoding="application/xhtml+xml"> <img xmlns="http://www.w3.org/1999/xhtml" src="intersect.gif" alt="A intersect B"/> </annotationxml> </semantics>
Here, the annotationxml
elements are used to indicate alternative
representations of the Content MathML depiction of the
intersection of two sets.
The first one is in the "Scalable Vector
Graphics" format [SVG1.1]
(see [XHTMLMathMLSVG] for the definition of an XHTML profile integrating MathML and SVG), the second one uses the
XHTML img
element embedded as an XHTML fragment.
In this situation, a MathML processor can use any of these
representations for display, perhaps producing a graphical format
such as the image below.
Note that the semantics representation of this example is given
in Content MathML markup, as the first child of the
semantics
element. In this regard, it is the
representation most analogous to the alt
attribute of the
img
element in XHTML, and would likely be
the best choice for nonvisual rendering.
Issue update_interface  wiki (member only) 

Update Interface  
The current section needs updating further in later drafts. 

Resolution  None recorded 
When MathML is rendered in an environment that supports [CSS2], controlling mathematics style properties with a CSS stylesheet is obviously desirable. MathML significantly redesigned the way presentation element style properties are organized to facilitate better interaction between MathML renderers and CSS style mechanisms. It introduced four mathematics style attributes. Roughly speaking, these attributes can be viewed as the proper selectors for CSS rules that affect MathML.
Controlling mathematics styling is not as simple as it might first appear
because mathematics styling and text styling are quite different in
character. In text, meaning is primarily carried by the relative
positioning of characters next to one another to form words. Thus,
although the font used to render text may impart nuances to the
meaning, transforming the typographic properties of the individual
characters leaves the meaning of text basically intact. By contrast,
in mathematical expressions, individual characters in specific
typefaces tend to function as atomic symbols. Thus, in the same
equation, a bold italic 'x' and a normal italic 'x' are almost always
intended to be two distinct symbols that mean different things. In
traditional usage, there are eight basic typographical categories
of symbols. These categories are described by mathematics style
attributes, primarily the mathvariant
attribute.
Text and mathematics layout also obviously differ in that mathematics uses 2dimensional layout. As a result, many of the style parameters that affect mathematics layout have no textual analogs. Even in cases where there are analogous properties, the sensible values for these properties may not correspond. For example, traditional mathematical typography usually uses italic fonts for single character identifiers, and upright fonts for multicharacter identifier. In text, italicization does not usually depend on the number of letters in a word. Thus although a fontslant property makes sense for both mathematics and text, the natural default values are quite different.
Because of the difference between text and mathematics styling, only the styling aspects that do not affect layout are good candidates for CSS control. MathML 3.0 captures the most important properties with the mathematics style attributes, and users should try to use them whenever possible over more direct, but less robust, approaches. Further discussion and a sample CSS stylesheet may be found in [MathMLforCSS].
Generally speaking, the model for CSS interaction with the math style attributes runs as follows. A CSS style sheet might provide a style rule such as:
math *.[mathsize="small"] { fontsize: 80% }
This rule sets the CSS fontsize properties for all children of the
math
element that have the mathsize
attribute set to small.
A MathML renderer
would then query the style engine for the CSS environment, and use the
values returned as input to its own layout algorithms. MathML does
not specify the mechanism by which style information is inherited from
the environment. However, some suggested rendering rules for the
interaction between properties of the ambient style environment and
MathMLspecific rendering rules are discussed in Section 3.2.2 Mathematics style attributes common to token elements, and more generally throughout Chapter 3 Presentation Markup.
It should be stressed, however, that some caution is required in writing CSS stylesheets for MathML. Because changing typographic properties of mathematics symbols can change the meaning of an equation, stylesheet should be written in a way such that changes to documentwide typographic styles do not affect embedded MathML expressions. By using the MathML mathematics style attributes as selectors for CSS rules, this danger is minimized.
Another pitfall to be avoided is using CSS to provide typographic style information necessary to the proper understanding of an expression. Expressions dependent on CSS for meaning will not be portable to nonCSS environments such as computer algebra systems. By using the logical values of the new MathML 3.0 mathematics style attributes as selectors for CSS rules, it can be assured that style information necessary to the sense of an expression is encoded directly in the MathML.
MathML 3.0 does not specify how a user agent should process style information, because there are many nonCSS MathML environments, and because different users agents and renderers have widely varying degrees of access to CSS information. In general, however, developers are urged to provide as much CSS support for MathML as possible.
CSS or analogous style sheets can specify changes to rendering
properties of selected MathML elements. Since rendering properties
can also be changed by attributes on an element, or be changed
automatically by the renderer, it is necessary to specify the order in
which changes requested by various sources should occur. An example of
automatic adjustment is what happens for fontsize
, as
explained in the discussion on scriptlevel
in Section 3.3.4 Style Change <mstyle>
. In the case of "absolute" changes,
i.e., setting a new property value independent of the old value (as
opposed to "relative" changes, such as increments or
multiplications by a factor), the absolute change performed last will
be the only absolute change which is effective, so the sources of
changes which should have the highest priority must be processed
last.
In the case of CSS, the order of processing of changes from various sources which affect one MathML element's rendering properties should be as follows:
(first changes; lowest priority)
Automatic changes to properties or attributes based on the type of
the parent element, and this element's position in the parent, as for
the changes to fontsize
in relation to
scriptlevel
mentioned above; such changes will usually be
implemented by the parent element itself before it passes a set of
rendering properties to this element
From a style sheet from the reader: styles which are not declared "important"
Explicit attribute settings on this MathML element
From a style sheet from the author: styles which are not declared "important"
From a style sheet from the author: styles which are declared "important"
From a style sheet from the reader: styles which are declared "important"
(last changes; highest priority)
Note that the order of the changes derived from CSS style sheets is specified by CSS itself (this is the order specified by CSS2). The following rationale is related only to the issue of where in this preexisting order the changes caused by explicit MathML attribute settings should be inserted.
Rationale: MathML rendering attributes are analogous to HTML rendering
attributes such as align
, which the CSS section on
cascading order specifies should be processed with the same priority.
Furthermore, this choice of priority permits readers, by declaring certain
CSS styles as "important", to decide which of their style
preferences should override explicit attribute settings in MathML. Since
MathML expressions, whether composed of "presentation" or
"content" elements, are primarily intended to convey meaning,
with their "graphic design" (if any) intended mainly to aid in
that purpose but not to be essential in it, it is likely that readers will
often want their own style preferences to have priority; the main exception
will be when a rendering attribute is intended to alter the meaning
conveyed by an expression, which is generally discouraged in the
presentation attributes of MathML.