# CSS Warrior

## MathML in Opera 9.5

MathML enabled weekly Kestrel build is available for testing. It has experimental support for MathML Basic (MathML for CSS profile).

To illustrate what can be done with MathML Basic there are some examples such as torture, stress tests and some of my articles converted to MathML.

Feedback and bug reports can be posted on MathML forum (for bugs reports you can also use bug tracking system, before reporting make sure that problematic formulae comply to latest working draft of MathML for CSS profile as we support only that profile at the moment).

More information will be posted on MathML forum.

## MathML in Opera and Safari

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>
</mroot>


would work while
<mroot>
</mroot>


is not easy to handle with CSS. One can rewrite MathML example above as
<mroot>
<maction>
</maction>
<maction>
</maction>
</mroot>


Then for native MathML formatters it is equivalent to
<mroot>
</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.

## Mathematical formulae in new dimension

One should be crazy to expect mobile browsers to be able to render mathematical formulae, especially when most of desktop browsers fail miserably on any kind of mathematical markup. But is seems that things look completely differently when you look at them from a higher dimension.

Upcoming new version of Opera Mini turned out to be capable of handling complex inline layouts, including CSS formatted math formulae. It managed to handle quite sophisticated stress tests much better then some of its desktop friends do.

## MathML story continues

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.

## Opera addict moves to Osland

No more restrictions on using Opera during working hours!
Access to internal builds and bug tracking system! What else do we need?
So I am moving to Opera Software, where I'll join Grand Moose and the rest of
vikings from Core QA team in their battle with shrinking army of Presto bugs.

## Formatting mathematical articles with XSL FO

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.

## e-Publishing with CSS

Some time ago XSL FO lost battle for web where it apparantly failed to replace more convenient, easy to learn and easy to use CSS. Result is quite natural as, being specially designed for usage on web, CSS establishes good balance between rules specified by author of the document (via author's style sheet), user's preferences (specified via user style sheet) and browser's defaults (UA style sheet), in addition it allows authors to write media specific style sheets that take into account media type (screen, print, projection, handheld, speech, tv) as well as device parameters (color/bw, screen width/height/resolution etc), while CSS selectors admit incremental matching that allows browsers to render pages progressively as while page is loading.

One of these factors (progressive rendering) is no longer relevant in case of paged media where outcome of battle between CSS and XSL FO is not clear yet, but even on page media CSS has many advantages over other style languages. Inspite of its advantages CSS is not really popular in e-publishing, however situation is changing as more and more people realize that eliminating gap between the web and e-publishing will simplify whole publishing process including authoring, formatting and delivery of content. Taking into account that modern browsers are not really keen when it comes to paged media, it is important to have good CSS formatters and publishing oriented browsers. Release of professional CSS formatter (Prince developed by YesLogic) was first successful step towards CSS based e-publishing framework, OpenReader format for e-books is another good trend that reduces gap between web standards and e-book formats and finally release of new publishing oriented tool¹ that combines browser, CSS formatter, server side applications, PDF generator and source editor suggests that CSS has good chances to win the battle.

¹I meant PDFreactor developed by RealObjects, it supports XML, XHTML, CSS, XSLT and SVG. CSS support is promising but not as strong as in Prince (for example ACID2 fails), however it provides browser like viewer and has XSLT processor.

## XSL-TeX Experiment

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}
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.

## LaTeX to XML with XSLT

After reading article about possibility (or lack of such) of transforming LaTeX into XML using XSLT, I decided to find out myself whether it is possible to employ XSLT in such transformations. If so, then one can consider LaTeX (certain subset of notations) among markup languages that fit into XML + XSLT + CSS framework.

I think it is worth to investigate this issue, because if it will turned out that XSLT style sheet that transforms compact non-XML input like LaTeX into XML exists, is relatively small and fast enough then using it on client side makes sense. At least for me using XSLT sounds to be more reasonable then taking Javascript approach for transforming markup (I don't like XSLT but for some strange reason I strongly prefer idea of style sheet to idea of scripting).

To illustrate what I mean I prepared couple of XHTML pages (simple article and unfinished version of torture page) with embedded LaTeX formulae (works in Opera 9 only). LaTeX source is transformed into XML using XSLT and rendered with CSS.

XSLT part is not finished yet and it is hard to say how fast final version will be,
but in any case it shows that possibility exists and sounds to be realistic.

## Web gets back

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.