CSS Warrior

While working on CSS formattable MathML profile, I noticed that MathML actually admits serialization that one could feed to any CSS2.1 rendering engine (including Opera 9, Prince formatter 6, Safari 3 and Mozilla browsers based on Gecko 1.9a3 or later).
Here is demo page: http://xml-maiden.com/mathml/mini/stress.xhtml

While this particular serialization sucks (mostly due to workarounds for browser bugs and lack of some crucial CSS3 stuff that is not yet implemented in browsers), generally speaking CSS rendering engines have necessary functionality to handle complex inline expressions and if we'll manage to ship reasonable MathML profile that works in CSS environment then barrier for adoption of MathML on web will be reduced significantly.

The trick with serialization above is that CSS can handle many MathML layout schemata provided that order of child elements follows their inflow order so for instance

<mroot>
 <mi>radix</mi>
 <mi>radicand</mi>
</mroot>

would work while

<mroot>
 <mi>radicand</mi>
 <mi>radix</mi>
</mroot>

is not easy to handle with CSS. One can rewrite MathML example above as

<mroot>
 <maction>
  <mi>radicand</mi>
  <mi>radix</mi>
 </maction>
 <maction>
  <mi>radix</mi>
  <mi>radicand</mi>
 </maction>
</mroot>

Then for native MathML formatters it is equivalent to

<mroot>
 <mi>radicand</mi>
 <mi>radix</mi>
</mroot>

due to fallback behaviour that maction has, while CSS formatters can pick elements in order that matches normal flow. By applying such cyclic permutation to mover, munderover, mroot and msubsup one can get MathML serialization that is CSS2.1 formattable.
Here is example: http://xml-maiden.com/mathml/basic/stress.xhtml
It is one bug away from working in Safari (baseline alignment of inline-tables is broken) so the demo page mentioned in the beggining of post relies on extra workarounds for that bug.

Note that with CSS3 named flows one could avoid maction monkey business, but browsers are not there yet. Once we get there then adding support for appropriate MathML profile should be easy for most of web browsers.

Recently I joined W3C Math working group, where I will represent Opera Software. I am not the biggest supporter of MathML and often am considered among its oponents, however there are a lot of thing that can be done on MathML side and solving the existing problems requires some kind of coordination between Math WG, CSS folks and browser developers.

The intention is to address MathML/CSS compatibility issues that would make integration of MathML with the rest of technologies supported by browsers much easier. Today it is hard to judge what the actual outcome will be, but in overall I am optimistic as it seems that essential part of MathML can be reformulated in more CSS friendly manner and with a few CSS3 extensions one may merge it in XML + CSS framework.

Once the technical issues will be resolved and realistic spec will be available I think browsers will be able to reconsider their position on MathML support. Not sure whether this will finally bring more MathML content to web as being quite verbose MathML distracts essential part of potential users especially those from LaTeX community, but in the same time MathML3 may have both XML and non-XML input syntax like RELAX NG and XQuery have, so if successful this step may provide some kind of bridge between LaTeX and XML communities.

Basically I consider myself to be among XSL Foe's rather then XSL FO users, however I am really curious about possibility of rendering maths with XSL FO and since XSL community does not care much about issue, I decided to write appropriate style sheets myself. Generally speaking capabilities of XSL FO 1.0/1.1 are sufficient to format most of mathematical expressions including fractions, indices, matrices, under scripts, radicals etc.
There are some problems with over scripts however and it seems that rendering over scripts with complex base is quite tricky so current style sheet assumes that base of expression with over scripts is simple (#PCDATA).
As it was expected situation with XSL FO implementations is not perfect either, currently most of XSL Formatters including RenderX XEP and Apache FOP do not support fo:inline-container needed to format complex inline expressions, Xinc seems to implement fo:inline-container but fails to align it properly, so at the moment only Antenna XSL Formatter can handle fo:inline-container properly. It is not the problem as long as my interest is purely academic and I am unlikely to use XSL FO in real life. Some examples of formatting mathematics in XML + XSL framework are posted on my site.

The idea behind XSL-TeX was to develop experimental LaTeX like mathematical markup that fits well in X(HT)ML + XSLT + CSS, X(HT)ML + XSLT + XSL FO and X(HT)ML + JS + CSS frameworks. Basically it is just experiment intended to find out whether it is worth to send non-XML input to browsers, as well as CSS and XSL formatters. It is inspired by CanonML initiative.

The basic conceptual problem with LaTeX like input syntax is that there is no natural way to apply CSS selectors, Xpath, and DOM Core to LaTeX like markup due to highly non-uniform syntax where one has no analog of hierarchical tree with elements and attributes. In addition such a markup is unlikely to be suitable for client side usage as XSLT and/or JS needed to transform LaTeX like input into something suitable for rendering in browser (X(HT)ML+CSS, MathML, SVG) makes rendering slow and non incremental.

Due to this reasons XSL-TeX inititaive was abandoned almost as quickly as arised. However some resources (convertors, style sheets) for handling XSL-TeX are available and if someone is interested in taking non-XML approach (s)he can reuse these style sheets.

Below is brief summary of input syntax and available tools.


Input Syntax (Brief summary)

Inline formula: $E = mc^2$
Displayed formula: $$E = mc^2$$
Subscripts: Base_{subscript} or Base_s
Superscripts: Base^{superscript} or Base^s
Stacked indices: Base_{sub}^{sup} or Base^{sup}_{sub} or Base_s^s or Base^s_s
Presubscript: \inf{sub}Base
Presuperscript: \sur{sup}Base
Stacked prescripts: \pre{sup}{sub}Base
Fractions: \frac{numerator}{denominator}
Overscripts: \stackrel{over}{Base}
Underscripts: \stackrev{Base}{under}
Overbrace: \overbrace{Base}
Overbrace with inscription: \overbrace{Base}^{over}
Underbrace: \underbrace{Base}
Underbrace with inscription: \underbrace{Base}_{under}
Square root: \sqrt{radicand}
Radical: \rad{radix}{radicand}
Operators: \ope{U} \ope{U}_{sub} \ope{U}^{sup} \ope{U}_{sub}^{sup}
Common Operators: ∑ ∑_{sub} ∑^{sup} ∑_{sub}^{sup}
Fences:
\left( content \right)
\left[ content \right]
\left{ content \right}
\left| content \right|
\left. content \right|
Fences with indices:
\left( content \right)_{sub}
\left[ content \right]_{s}
\left{ content \right}_{sub}^{sup}
\left| content \right|^{sup}_{sub}
\left. content \right|_0^1
Vectors: \vector{entry}{entry}{entry}{entry}
Matrices:
\matrix{
\row{cell}{cell}{cell}
\row{cell}{cell}{cell}
\row{cell}{cell}{cell}
}
Determinants:
\det{
\row{cell}{cell}{cell}
\row{cell}{cell}{cell}
\row{cell}{cell}{cell}
}
Cases:
\cases{
\case{value}{scope}
\case{value}{scope}
}
Bold: \mathbf{Bold}
Italic: \mathsl{Italic}
Strike: \strike{Strike}
Overline: \overline{overline}
Underline:\underline{underline}
Linebreak: \\
Softbreak (wrap point): \wrap
Character escapes: \{ \} \_ \^ \s (for $) \b (for \)




Style sheets for XSL-TeX

xsltex.xslt

XSLT style sheet that transforms XSL-TeX into XML and is suitable for rendering XSL-TeX in Opera 9.
See examples of using this style sheet.
It is not recommended to use this method for delivery (transforamtions are better to be done on author side).

xsltex.js

JavaScript that transforms XSL-TeX into XML. It can be used for rendering XSL-TeX in Opera 9.
Some examples of using this JS are available.
As in case of XSLT, transforamtions are better to be done on author side.

Converters

XSL-TeX in Action

Online converter for transforming XSL-TeX into XML and/or XHTML. Output can be formatted in Opera 9 and/or
Prince 5 using CSS. There are some examples of XHTML output produced by this convertor.
Can be used offline.

tex2xml.js

Macro for EmEditor that can be used to convert XSL-TeX to XML during authoring process.
It converts selected part of mathematical expression only.
Works in EmEditor version 5 (or 4 Professional). Can be enabled from
-[Macros]
--[Select...]
drop down menu in EmEditor.

xsl-tex.js

Macro for EmEditor that can be used to convert XSL-TeX to XML during authoring process.
It converts selected document fragment containing mathematical expressions.
Works in EmEditor version 5 (or 4 Professional). Can be enabled from
-[Macros]
--[Select...]
drop down menu in EmEditor.

Being emerged in European Centre for Nuclear Research (CERN), world wide web quickly evolved into entertainment oriented media and left many scientists disappointed. Web standards were science unfriendly and embedding complex mathematical formulae in web pages was far from being easy. Many problems still remain open, we still don't have decent set of Unicode fonts with good coverage of math oriented Unicode ranges, we still can't agree on markup as bringing LaTeX, MathML, OpenMath, ISO 12083, XML MAIDEN and other approaches to commond ground is nearly impossible. Some dislike angle brackets some curly ones, some want to have self contained markup, some want to integrate math oriented markup with the rest of webstandards, some want to code pages manually, some think that what they see is what they get, some prefer to have clear hierarchical structure, some vote for drastically abridged Unicode based notations.

It looks like madhouse, but in next several years I think we will get our web back regardless what markup language we prefer to use. As CSS support in browsers grows stronger, capabilities of XML + CSS and XHTML + CSS publishing frameworks grow and merge more and more markup languages in single X(HT)ML + CSS framework at some point this will resolve formatting related problems of math community. Languages that for some reasons does not fit into this framework (MathML, ISO 12083, LaTeX), still can be handled in more awkward but in the same time more powerful XML + XSLT + CSS, XML + EcmaScript + DOM + CSS or even XML + XSLT + EcmaScript + DOM + CSS approaches. Combining text processing capabilities of XSLT or EcmaScript + DOM with formatting capabilities of CSS can yield good results (in the same time involving XSLT/DOM in rendering process slows down rendering and makes it non-incremental). Thus day when we will be able to place mathematics on web without tears is not very far and already today scientist are ready to deploy necessary XML/CSS/XSLT/DOM machinery.

Important steps in this direction are ability of Opera 9 and Prince 5 to handle maths in pure CSS, that on one hand turns green light for XML MAIDEN and on other hand makes in easier to write MathML and ISO 12083 implementations on the top of CSS rendering engine (that is not really good idea from web architecture point of view, as single XML + CSS framework is preferable to multiple presentational markup languages that often just duplicate existing functionality). In the same time javascript applications like jsMath, ASCIIMathML, HMath, Wiky (New!), UserJS for ISO 12083 provide good background for future web oriented client side scientific applications.