Loci
<a id="topmat"/>Math Authoring for the Web Made Easier A Stylesheet for a LaTeX-HTML Hybrid Document Format Thomas E. Leathrum Jacksonville State Univ. leathrumjsu.edu http://cs.jsu.edu/~leathrum/ January 2009 This article was written using a new stylesheet which provides a hybrid of XHTML with some new elements intended to reflect LaTeX-like document structure. Most of the elements familiar from XHTML are available here, as is nearly all of SVG. Instead of remapping MathML, though, the embedding interface for Content Pseudo-TeX (CPT) is provided, with special tags. Also included are: topmatter formatting, including automatic generation of the table of contents, with internal linking; LaTeX-like elements for definitions, theorems, proofs, and similar environments; automatic numbering of sections, equations, and figures; basic citation formatting, including internal reference annotations; and identifier referencing with automatic internal page linking for citations and numbers.

Introduction

In January of 2007, the MAA Special Interest Group on the use of the World-Wide Web in Undergraduate Mathematics Instruction (WebSIGMAA) sponsored a panel discussion at the AMS/MAA Joint Mathematics Meetings on "Best Practices for Mathematics on the World-Wide Web," at which I served as a panelist. In my comments, I focused on ways to facilitate internationalization and accessibility of Web-based materials, in particular the advantages of content-oriented mark-up such as Content MathML. Following the panelists' comments, questions from the audience got me wondering about whether it would be possible to build software which would make it easier for authors accustomed to writing LaTeX mark-up to write instead standards-compliant content-oriented Web mark-up. In a conversation with a colleague a month later, I wondered openly if it would be possible, as a first step in this direction, to translate a compact and readable LaTeX-like mark-up for mathematics expressions into Content MathML. The result of that discussion was the Content Pseudo-TeX Translator applet. But I knew that would only be the first step.

The next step is represented here, with this article, and with the document format I used to write this article. This format supplements the earlier Content Pseudo-TeX with new LaTeX-like document structure environments and many structure-related elements from existing Web standards. Documents written in this format are translated by a stylesheet (and by the earlier translator applet) into fully standards-compliant Web mark-up for the current generation of advanced Web browsers.

The document format is designed to be easy and efficient for authors to learn and use, but it is by no means entirely self-contained -- indeed, most of the tags and environments available to authors are explicitly remapped from other Web standard formats. An author should have no need to understand the more advanced technologies used to implement the document format, but nonetheless some knowledge of other formats is prerequisite to using this document format effectively. In particular, an author using this document format should understand basic XML syntax, common XHTML tags (XHTML is essentially just HTML with the restrictions imposed by XML syntax), and SVG for graphics. Math expressions are included using an embedded form of Content Pseudo-TeX, which inherits its identifiers from Content MathML Chapter 4 and its syntactic structure from LaTeX. Lists of all tags available in this format are included in the Appendices to this article, but for detailed documentation of Content Pseudo-TeX and of the tags remapped from XHTML or SVG, please see the References.

Getting Started

This document formatting stylesheet manages internally many issues which have confounded novice authors of Web materials as browsers have developed more sophisticated uses of XML, the eXtensible Mark-up Language from the World Wide Web Consortium (W3C). For example, XHTML and other recent variations on HTML are notorious for their use of rather cryptic header elements, such as DOCTYPE declarations and namespaces. In this document format, all such issues are handled internally, invisible to the author. To begin a page in this format, the browser need only be informed that the document is an XML document, and to load the stylesheet remap.xsl -- so the basic document structure looks like: 




Article Title Here
Your Name
Your School
...


...

...
]]>

It should be noted at this point that the document structure does adhere to the rather strict rules of XML formatting: tags must either be empty, as in (to be seen later), or balanced, as in the environment seen above, and attribute values must be enclosed in quotation marks, as in the identifier seen above. Moreover, all element and attribute identifiers must be all lower case letters.

The file must also be saved in such a way as to be served to the browser as an XML file -- in most cases, this just means saving the file with filename suffix ".xml." The reference above to the stylesheet, remap.xsl, is a local reference -- due to browser security issues, the stylesheet and several related files must be saved locally, in the same folder as the document being set using this format. The relevant files are available for download in a compressed archive (available formats: ZIP or TGZ).

XHTML and SVG elements

Nearly all XHTML elements are remapped in this stylesheet to elements available within this document format. The complete list of remapped XHTML elements is given in "Remapped XHTML Elements." All attributes are copied with the supported elements, also. Some elements are given new meanings, or are not available because their functions are handled by other elements instead.

For example, the environment in XHTML places a title in the browser's top bar. In this document format, the environment does that and also places a main title centered within the article text.

The heading elements (, , etc.) are redefined (except for , which is not available) in order to reduce their presented sizes and provide special code needed to properly handle automatic section numbering and table of contents generation. Any XHTML attributes which are applied to these redefined versions of the elements are copied and applied appropriately.

The XHTML environments , , and are not available because their functions are all handled in this document format by the environment.

The document format does not attempt to redefine or replace the XHTML elements for handling tables or itemized lists, even though they do not closely correspond with LaTeX environments, since the elements already available suffice for nearly all purposes.

Some XHTML elements, however, are not available in any form within this document format, either because they are deprecated within XHTML or because they are heavily presentation-oriented, and this document format attempts to maintain content-level structured formatting. The unavailable elements are: style elements big, small, font, b, i, tt, s, strike, u basefont, and center (same effects can be achieved using attributes instead); presentation elements br and hr; frames-related elements frame, frameset, and noframe; deprecated form elements dir, isindex, and menu; and HTTP instruction element meta.

All SVG elements are remapped in this stylesheet to elements available within this document format. The complete list of SVG elements available in this document format is given in "Remapped SVG Elements." Two SVG elements require a bit of extra handling in the stylesheet: title and metadata -- name clashes with new elements in the document format are handled by the internal namespace management, but only when they appear within the environment. All attributes are copied with the supported elements, also. However, in cases where SVG requires additional care for proper use of XML namespaces, the stylesheet manages the namespaces internally. In particular, the attribute to the linking environment in SVG ordinarily requires explicit reference to the XLink XML namespace. sec. 17 There is, of course, a corresponding linking environment in XHTML, but it does not require the XLink namespace in normal use. In this document format, all namespace references are managed internally, so the author does not need to worry about it.

There are two other elements which XHTML and SVG have in common: and . The syntax of these elements is identical between XHTML and SVG, though, so the stylesheet only needs to manage the XHTML and SVG namespaces for these elements. Again, this is handled internally so that the author does not need to worry about it. As in both XHTML and SVG, the contents of and environments must be protected from the XML parser by enclosing the contents within a <![CDATA[...]]> environment.

Here is a simple example of SVG:

This was generated with the following code: 






 ]]>

Note here also the use of the environment and its attribute. These center the SVG image. This example is repeated in Section , "Automatic Numbering," where figure numbering and captions are demonstrated as well.

There are many ways to generate mathematically useful SVG images. For example, the gnuplot program can generate graphs of functions using straightforward commands, and it can export its output in SVG format. The Inkscape program provides a graphical interface with SVG output, but does not have particular support for generating graphs of functions. The gnumeric spreadsheet program can generate a graph from data within a spreadsheet and export the graph in SVG format. The Mathematica software package can export graphics as SVG, but apparently the Maple software package cannot (as of Maple version 12).

Emedded Content Pseudo-TeX

Mathematical expressions can be included within a document using the embedding interface for Content Pseudo-TeX. The header references to the JavaScript file and Java applet normally needed to invoke embedded CPT are included automatically by the stylesheet, so the author does not have to worry about them. Embedded mathematics are included using the environment. CPT expressions within the environment must be protected from the XML parser, though, using a CDATA section.

The environment takes the attribute , similar to ordinary MathML. Setting display="block" sets the mathematics in block displayed mode, similar to "$$" in TeX or the "\[...\]" environment in LaTeX. The default setting for this attribute is block="inline", which sets the mathematics in-line with the surrounding text.

The environment is provided as a convenient abbreviation for <math display="block">...</math>.

Here is an example of embedded mathematics, using the environment for block display mode:

This was generated using the following code: 

>]]>

The environment and with display="block" both also allow a environment for including left-justified labels such as equation numbers. The environment must be inside the or environment, but outside the CDATA zone. For example:

This was generated using the following code: 

>]]>

Use of the element above and other related numbering elements is explained in Section , "Automatic Numbering." Other labels are allowed within the environment as well. For example:

This was generated using the following code: 

>]]>

The following table includes several more examples of embedded Content Pseudo-TeX, all set using the environment:

\limit[v:x][c:{x\tendsto@above|0}]{\sin{x}/x}=1
\sum[v:n][l:1][u:\infinity;]{1/n^2}=\pi;^2/6 
\int[v:x][l:-\infinity;][u:\infinity;]
    {\exp{-(x^2)}}=\root{\pi;}
 
f(x)\approx|
  \sum[v:n][l:0][u:k]{
  (\begin{apply}\diff[n:n]{f}c\end{apply}/n!)*(x-c)^n}
Table of CPT Examples.

The previous article on Content Pseudo-TeX includes complete documentation on the source syntax. Since CPT derives most of its identifiers from corresponding Content MathML elements, authors will also need to refer to the W3C documentation on MathML, which includes descriptions of all Content MathML elements. Chapter 4

LaTeX-Like Document Structure Elements

This document format supports several theorem-like environments, similar to those in LaTeX, which allow an author to introduce basic structural elements into a document without being concerned with layout issues. The supported environments are:

  • : Definition
  • : Theorem
  • : Proof
  • : Lemma (typeset similar to Theorem)
  • : Claim (typeset similar to Theorem)
  • : Proposition (typeset similar to Theorem)
  • : Corollary (typeset similar to Theorem)
  • : Example (typeset similar to Definition)
  • : Exercise (typeset similar to Definition)
  • : Problem (typeset similar to Definition)

All of these theorem-like environments allow a environment, for which the contents are used to replace the default label on the environment. The environment must be inside the theorem-like environment. Here are examples of a few of these environments:

A term is defined here. This is a theorem based on the defined term. The theorem is proven here. Renamed theoremThis is a renamed theorem.

These examples were set with the following code: 

A term is defined here.
This is a theorem based on the defined term.
The theorem is proven here.
Renamed theoremThis is a renamed theorem.]]>

All of these theorem-like environments, except the environment, also allow a environment for including labels such as subsection numbers. The environment does not support labels because a proof is always associated with a theorem, so the label applies to the theorem. The environment must be inside the theorem-like environment. Here is an example:

This theorem includes a label.

This example was set with the following code: 

This theorem includes a label.]]>

Use of the element above and other related numbering elements is explained in Section , "Automatic Numbering." Other labels are allowed within the environment as well. For example:

This is another labeled theorem.

This was set with the following code: 

This is another labeled theorem.]]>

Topmatter Formatting

The material which typically appears at the beginning of an article or similar document (the "topmatter"), such as title, author, and abstract, are set in this document format using the following elements:

  • : Contains the article's title. The contents of this environment are placed in the browser's top window bar (the function the XHTML environment usually performs), and also within the document in title position.
  • : Contains the article's subtitle.
  • : Contains the article's author, and related information. The document may contain more than one environment. The following optional environments are allowed only inside the environment:
    • : Contains the affiliation of the author.
    • : Contains the e-mail address of the author. Inside this environment, the and environments are required. The string "user@host" is set within the document, and a "mailto:" link is automatically provided.
    • : Contains the URL of the author's Web homepage. The contents of the environment are set within the document, and a link is automatically provided.
  • : Contains the article's date. No particular date format is enforced.
  • : Contains the article's abstract. The "Abstract:" label is included automatically.
  • : Automatically generates a table of contents for the article, based on heading elements (, , etc.) within the article. The "Contents:" label is included automatically.

Indentation in the table of contents is determined by the level of heading element within the article, so for example a line from an heading is indented more than a line from an heading. Internal page links are automatically included for each item. Also, if the element is included in the topmatter, then a link back to the table of contents is included with each heading element within the article.

The topmatter for this article was set using the following code: 

Math Authoring for the Web Made Easier
A Stylesheet for a LaTeX-HTML Hybrid Document Format
Thomas E. Leathrum
Jacksonville State Univ.
leathrumjsu.edu
http://cs.jsu.edu/~leathrum/

July 2008

This article was written...

]]>

The order in which these elements appear in the document is not relevant -- they will be set in the proper order in the browser.

The stylesheet also provides a environment for including arbitrary data in the source XML file (provided the XML formatting is not violated). The contents of this environment do not appear in the document when it is set in a browser. Using the W3C's RDF metadata format within this element is recommended, but not required.

There is no explicit prohibition in the stylesheet preventing these elements from being used anywhere in the document, but it wouldn't make much sense to put them anywhere but the beginning, immediately after the opening <document> element.

The format described above for e-mail addresses is used instead of simply including an e-mail address string in the document in order to foil automated Internet "robots" which mine pages for e-mail address strings.

If the page includes a environment for local style declarations, it should be included in the topmatter, immediately after the opening <document> element.

Automatic Numbering

For numbering chapters, sections, subsections, etc., within a document, the following elements are provided: , , , , etc. (down to ). Chapters and sections are numbered sequentially, with section numbers resetting to 1 when a new chapter begins. Chapter labels have the form "Chapter I" (using Roman numerals). Section labels include only the section number. Subsection labels have the form "2.3," where the first number is the section number and the second number is the subsection number. Subsection numbers reset to 1 when a new section begins. Similarly, subsubsection labels have the form "2.3.4," etc. There is no requirement that chapter numbers be used (for example, this article does not use them), but using subsection numbers without preceding section numbers will cause problems with how the labels appear when they are set.

Appendix number labels are provided with the elements , , , , etc. (down to ). Appendix labels have the form "Appendix A," where the capital roman letters proceed sequentially for all appendices. Appendix section labels have the form "A.2," appendix subsection numbers have the form "A.2.3," etc. Again, numbering and number resetting is automatic.

If section numbers are included in heading environments (, , etc.), then the section number element must be the first item inside the heading environment, or the automatic generation of the table of contents and automatic adjustments to punctuation will fail.

A typical use of these automatic numbering elements is to provide subsection labels on theorem-like environments. In order to properly place the subsection label when the environment is set in the document, the environment is provided within each of the theorem-like environments (except the environment). Here is a typical example:

This is a numbered theorem.

This was set with the following code: 

This is a numbered theorem.]]>

Punctuation around these automatically-generated number labels is generally handled automatically as well, although the punctuation is treated somewhat differently depending on whether the number label is in a heading element, a label in a theorem-like environment, or elsewhere.

Figures and equations can be numbered automatically using the and elements. For labeling figures, the environment is provided. Here is an example showing the use of an automatically generated figure number in a caption under an SVG image:

SVG example.

This was generated with the following code: 






 

 SVG example.]]>

Note here also the use of the environment and its attribute. These center the SVG image. The stylesheet automatically centers the caption.

Similarly, the element provides automatically generated equation number labels. The environment and with display="block" both also allow a environment for including left-justified labels such as equation numbers. For example:

This was generated using the following code: 

>]]>

Both figure numbers and equation numbers have the form "2.3," where the first number is the section number and the second number is sequential within the section -- so there are three independent sequences of numbers within a section: the subsections, the figures, and the equations. That is why, in this section, the numbered theorem, the numbered figure, and the numbered equation all take the same number: they are each the first of their type in this section, and the three types are numbered independently.

If any of these number elements has an attribute, then that number can be referenced abstractly elsewhere in the document using the element, which supports the attribute. For example, the section heading for this section is generated using the following code: 

 Automatic Numbering]]>

Elsewhere in this document, then, this section can be referenced as follows: 

,  "Automatic Numbering."]]>

The stylesheet keeps track of the cross-referenced numbering automatically. The cross-referenced elements are also provided with internal page links, so that (in the example above) the label set by the element is a link with the element as its destination. (This linking can be suppressed by setting the optional attribute link="false" in .) To see this example, the following is set with the code above: Section , "Automatic Numbering."

The element, which can be used either as an empty element or as an environment , provides a more customizable way to generate numbering sequences. This element takes two attributes, a required attribute and an optional attribute. In its basic form, as an empty element with only the attribute, the element provides a sequence of numbers ("1," "2," "3," etc.) for each unique identifier provided in the attribute. With both attributes present, the element provides a number in the form "2.3.4.5," where the last number ("5") is the number of occurences of with the same value of the attribute, and the value of specifies that the string of numbers before the last number ("2.3.4") is copied from the last occurence of the counting element named in the attribute. For example, occurences of:

]]>

would establish another sequence of the form "2.3" (similar to , , and ). There is one important caveat: the numbers shown last do not reset to 1 when there is another occurence of the element named in the attribute. In other words, if occurences of as shown in the code above generate numbers "2.1," "2.2," and "2.3," followed by a element giving the number "3," then another occurence of as in the code above would give the number "3.4," because it is the fourth occurence of countid="n" and copies the "3" from the previous occurence of . Any counting element other than iteself can be named in the attribute. If the attribute is not present and is used as an environment, the contents of the environment provide the initial part of the number label -- for example, occurences of:

M]]>

would provide a sequence in the form "M.1," "M.2," "M.3," etc. Note that a element can also be used in the contents of a environment, although the link automatically provided in the only applies to that part of the label, not to the last number -- this is a context in which the link="false" attribute to may be appropriate. For example, if ]]> provides the section number "3," then:

]]>

will provide labels in the form "3.1," "3.2," etc., without internal links. Finally, a element can also be given an attribute and linked using , as with the other numbering elements.

Citations and Bibliographic References

Bibliographic entries are set in a document using the environment, which will ordinarily appear at the end of the document. Each environment is required to also include a environment, which is intended to allow the author to provide a unique identifying label for each entry. Elements valid within the environment to supply the reference data are given in the following list (names of elements are self-explanatory):

  • (may appear more than once for multiple authors)
  • (may appear more than once for multiple editors)
  • (for chapter number)
  • (for chapter title)
    • (may only appear inside environment)
  • (no particular date format is enforced)
  • (internet link URL, automatically set as active link)
  • (see below)

The environment tests its contents for instances of punctuation (dashes or commas) which would indicate that the page reference is to multiple pages, and uses a "pp." label if such punctuation is found; otherwise, it uses a "p." label, indicating only a single page.

The and environments may be used together, and indeed the punctuation is a bit different when they are, but neither element should be inside the other.

There are no prohibitions implemented to prevent clashes between elements within the citation, so for example even though there should never be any reason to refer to both a journal and a book in one citation, the elements do not prohibit such use. Some such clashes may cause problems with punctuation or other presentation issues in the citation when it is set in the document, though. Also, there is no explicit prohibition preventing the environment from being used anywhere in a document, but standard placement would be at the end of the document, perhaps in a "References" section, as seen at the end of this article.

Note also that the , , and environments take different meanings and presentations within the environment than when they are used in the document's topmatter. Similarly, the environment has a different meaning and presentation within the environment than when it is used as an empty element, , for automatic numbering of chapters.

If a environment has an attribute, then the bibliographic entry can be referenced abstractly elsewhere in the document using the element, which can be used either as an empty element as shown or as an environment, , both of which support the attribute. For example, in the References section of this article, the entry with tag "CPT" (to an earlier article regarding Content Pseudo-TeX) is set using the environment in the following form: 

CPT...]]>

Then an inline citation to that entry, such as , can be set with the following code: 

]]>

When is used as an environment, the contents of the environment are placed inside the tag's brackets. For example, a reference to a particular section in the above article may look like sec. 4.4. This can be set with the following code: 

sec. 4.4]]>

Note that the element also provides internal page links to the bibliographic entries.

Compatibility and Usage Notes

This document style, and this article, were written and tested using the Firefox browser. The embedded Content Pseudo-TeX is known not to work in the Microsoft Internet Explorer browser, but other elements should work.

So the ideal environment for viewing this article, and for using the document format, would be the Firefox browser (version 2.0 or later) with the Java runtime plug-in (version 1.5 or later). It may be necessary to install fonts in order to view mathematics correctly in the Firefox browser -- the STIX fonts are recommended, even though they are still in beta test stage at this writing.

Other browsers may work as well. The document format and associated files require several advanced Web technologies, though. First of all, a document using the format will be written as an XML file, and transformed to XHTML using the stylesheet, so the browser must support XML and the XML Stylesheet Language with Transformations. The browser must also support the Java plug-in and JavaScript in order to load the files required for embedded CPT. The embedding procedure requires the JavaScript commands to dynamically manipulate the XML document's Document Object Model (DOM) using a set of methods collectively referred to as Asynchronous JavaScript and XML (AJAX). In particular, the JavaScript methods manipulate the MathML portions of the DOM in order to embed mathematics expressions after the Java applet completes the translation from CPT to Content MathML. The mapping from Content MathML to Presentation MathML is carried out using another XSLT stylesheet. So the browser needs native support for Presentation MathML. This is the issue for Internet Explorer -- support for MathML in Explorer requires the Design Science MathPlayer plug-in, so the JavaScript methods do not have dynamic access to the MathML portions of the DOM, the MathML is instead rendered by the plug-in only at the time the document is loaded. At that point, the document still contains the untranslated CPT, not the MathML.

A final comment regarding XML document types (for advanced users): as noted earlier, this document style does not call for a document type element at the beginning of the document, but nonetheless documents written using this stylesheet can (and arguably should) be validated using a Document Type Definition (DTD). The stylesheet adds a document type element to the document in the process of transforming to XHTML -- in particular, the document type refers to the DTD for the profile provided by W3C for XHTML, MathML, and SVG combined. However, the stylesheet transforms must be applied before the resulting document is validated against the DTD. In writing this article, I carried out the transformation and validation using plug-ins for the jEdit editor: the XSLT plug-in uses the Apache Xalan Java engine for XSLT transforms, and the XML plug-in checks XML against DTD's using the Apache Xerces Java engine. I also wrote a basic local DTD to check the document format before applying the stylesheet; however, that DTD is not distributed with the stylesheet because its coverage of XHTML and SVG is incomplete but loading the complete W3C profile prior to defining the new elements left unresolvable name and context clashes. If validation is important in a particular application, I recommend performing the stylesheet transformations prior to validation. Note, however, that the translation of Content Pseudo-TeX will not have been applied when the document is validated against the DTD -- the CDATA zones will be intact, albeit with the "CDATA" environment stripped off. This behavior may appear to cause some problems with validation if the untranslated CPT math expressions contain the characters "<" or "&" -- the validator may conclude that the XML output is malformed. This is because the XSLT processor needs to cast its output as a text document in order for the XML validator to test it against a DTD. Ordinarily (i.e. when the stylesheet is applied by a browser), the XSLT processor should actually generate its output as a DOM tree representing the transformed document, and in this case the CPT expression appears in the tree correctly as a text node, unparsed and ready to be sent to the translator applet.

Conclusion

In an earlier article on Content Pseudo-TeX, sec. 6 I wrote about Future Directions for CPT and math on the Web:

A more draconian, but perhaps nonetheless ultimately preferable, recommendation would be to create a new stylesheet using XSLT transformations to implement a new tag set, with tag names derived from document structure macros in LaTeX. For example, the stylesheet could implement a ...]]> XML environment analogous to the LaTeX \begin{theorem}...\end{theorem} environment. The document structure environments in LaTeX do not specify any particular presentation for theorems or definitions, leaving such decisions to the LaTeX style -- in other words, they provide content-level information about the document. The syntax of tags in a document written for this stylesheet would still be XML-based, but at least the tag identifiers would be familiar to LaTeX users. I am working on a stylesheet based on this idea, and I hope to have a prototype available soon.

The document structure described in this article implements that vision. I expect this stylesheet to be subject to changes based on the demands of editorial processes as it comes into wider use. These changes may include new elements, changes in various presentations, and localization (e.g. translating automatic labels into other languages). The point of any stylesheet is to make such changes invisible to the author. I hope that other authors will find this stylesheet useful, and that editors of online mathematics journals will recognize its merits.

The project which has led to this stylesheet could proceed in a number of different directions. It may be possible, for example, to provide some degree of translation between this document format and LaTeX, although there are some inconsistencies in both directions which may make the translations difficult or imprecise. It may also be possible to develop a compressed syntax, similar to CPT, which translates into SVG elements and provides an easier way to describe graphs of functions.

Remapped XHTML Elements

The following elements have been remapped from XHTML, with all attributes copied, to make them available within this document format:

  • Basic XHTML formatting: p em strong sup sub
  • Advanced XHTML formatting: abbr acronym address blockquote code dfn div span kbd pre q samp var
  • Bidirectional text: bdo
  • Editing: del ins
  • Embedded content and other advanced HTML: img area map object param link base
    • Deprecated, but supported anyway: applet iframe
  • Lists: dl dt dd ol ul li
  • Tables: table tr td th caption col colgroup tbody thead tfoot
  • Forms: form input label select option textarea button fieldset optgroup
  • Elements overlapping with SVG, available to both with namespaces managed automatically: a script style

In addition, some XHTML elements are available with new meanings:

  • Main title and browser window title: title
  • Headings redefined: h1 h2 h3 h4 h5 (h6 is not available)
  • Citation: cite

Other XHTML elements are unavailable:

  • Some are unavailable because other tags cover their role: html head body
  • Other unavailable elements:
    • style: big small font b i tt s strike u center basefont
    • presentation: br hr
    • frames: frame frameset noframe
    • deprecated form elements: dir isindex menu
    • HTTP instructions: meta

Remapped SVG Elements

The following is an alphabetical list of all SVG elements which are remapped, with all attributes copied, to make them available in this document format:

altGlyph altGlyphDef altGlyphItem animate animateColor animateMotion animateTransform circle clipPath color-profile cursor definition-src defs desc ellipse feBlend feColorMatrix feComponentTransfer feComposite feConvolveMatrix feDiffuseLighting feDisplacementMap feDistantLight feFlood feFuncA feFuncB feFuncG feFuncR feGaussianBlur feImage feMerge feMergeNode feMorphology feOffset fePointLight feSpecularLighting feSpotLight feTile feTurbulence filter font font-face font-face-format font-face-name font-face-src font-face-uri foreignObject g glyph glyphRef hkern image line linearGradient marker mask missing-glyph mpath path pattern polygon polyline radialGradient rect set stop svg switch symbol text textPath tref tspan use view vkern

Other changes to SVG elements:

  • Elements overlapping with XHTML, available to both with namespaces managed automatically: a script style
  • Elements overlapping with new elements, available to both with namespaces managed automatically: metadata title

List of All New Elements

The following are new elements introduced by this document format:

  • main document: document
  • topmatter: author affiliation email user host url date abstract contents metadata
    • redefined XHTML element: title
  • mathematics: math dmath
  • theorem-like environments: definition theorem proof lemma claim proposition corollary exercise example problem
    • renaming: name
  • labels and captions: label caption
  • automatic numbering:
    • chapters and sections: chapter section subsection subsubsection subsubsubsection subsubsubsubsection subsubsubsubsubsection
    • appendix: appendix appendixsection appendixsubsection appendixsubsubsection appendixsubsubsubsection appendixsubsubsubsubsection
    • figures and equations: figure equation
    • referencing: numref
    • configurable: count
  • bibliography: tag author editor article chapternum chapter book journal volume number edition publisher city date url page
    • referencing: citeref
    • redefined XHTML element: cite

References

XML W3C
Extensible Markup Language (XML) 1.0
4th 29 September 2006 http://www.w3.org/TR/2006/REC-xml-20060816/ XHTML W3C
XHTML 1.0 The Extensible HyperText Markup Language
revised 2nd 1 August 2002 http://www.w3.org/TR/xhtml1/ SVG W3C
Scalable Vector Graphics (SVG) 1.1 Specification
14 January 2003 http://www.w3.org/TR/SVG/ MathML W3C
Mathematical Markup Language (MathML) Version 2.0
2nd 21 October 2003 http://www.w3.org/TR/MathML2/ XSLT W3C
XSL Transformations (XSLT), Version 1.0
16 November 1999 http://www.w3.org/TR/xslt RDF W3C
RDF Primer
10 February 2004 http://www.w3.org/TR/rdf-primer/ LaTeX Leslie Lamport LaTeX: A Document Preparation System 2nd Addison Wesley Professional 30 June 1994 CPT Leathrum
A Tool for Content MathML Authoring: Content Pseudo-TeX Translator Applet
Journal of Online Mathematics and its Applications June 2007 http://www.maa.org/joma/Volume7/Leathrum/index.xml