[whatwg] Mathematics on HTML5

[Øistein E. Andersen]

First of all, I must say that I applaud the initiative to include tags for mathematics in HTML5 and that I really hope that this will be part of the final specification.

Several attempts have been made to create a suitable format for mathematics on the web, none of which has gained widespread acceptance. Let me highlight a few requirements that probably must be satisfied in order to avoid a new failure.

1) Do not encode every tiny semantic detail explicitly

As Henri Sivonen put it: «[I]t is futile to insist on semantics that you can't pull out of LaTeX as it is normally authored.» I would like to use a slightly different wording: It is futile to insist on encoding anything that does not change the appearance of a formula as it is written on a blackboard or printed in a book.

This point can be illustrated by the two similar-looking formulae a) $\sin^2 (2p+1)x$ and b) $f^2(2p+1)x$. Mathematicians whom I know would evaluate a) as {sin[(2p+1)*x]}^2 and b) as f[f(2p+1)]*x.

Rules to map between meaning and form cannot be made to work reliably in all cases. Brevity is queen, and conventions may differ between different fields of mathematics.

The point already made about $dt^2$ meaning (dt)^2 being encoded to mean d(t^2) in MathML is just another example of what happens when there is lack of agreement between what the author wants (i.e. to make the formula look nice on the web so that other people can read it) and what the format tries to enforce (i.e. to assure that encoding of a formula be sufficiently semantical for a computer theoretically to be able to evaluate it).

No semantics is clearly better than wrong semantics, and correct semantics combined with nice presentation is probably not feasible without encoding everything twice. After all, most authors would clearly want to use the same encoding for the superscripts in e.g. $x^2 = x\times x$, $f^2(x) = f[f(x)]$, $f^{(4)}(x) = \frac{d^4}{dx^4}f(x)$, and $x_i^{(j)} = x_{i,j}$. Anything else will undoubtedly lead to erratic encoding, and what is a poor author supposed to do when he wants to use e.g. a superscript in a way for which no encoding exists?

Finally, the encoding of semantics in mathematical formulae probably does not feel more necessary to most people who write and read them than the encoding of the particular meaning of an ambiguous word like `can', albeit a differentiation between the modal verb meaning `be able to', the noun denoting a container, and the transitive verb meaning `put into a can' could potentially be helpful for applications like grammar checking and text retrieval.

2) Fight verbosity

The reasons for TeX's undeniable success are many, but one of them might be its concise syntax. People who appreciate the aesthetics of mathematics and are used to make the distinction between $f$ and $F$ or between $\phi$, $\varphi$ and $\Phi$ certainly have no difficulty distinguishing \big from \Big. More importantly, the amount of mark-up needed to encode a line of mathematics is enormous compared to what is necessary for a line of running text. Consequently, each mark-up element must be kept as short as possible.

It may be true that there will always be more <p>'s than <formula>'e out there; however, those using mathematics are likely to use it quite heavily, which makes <m> (for mathematics, or <f> if the <m> tag cannot be reassigned), <frac>2<den>3</frac> and <root>3<of>125</root> clearly better suited than <formula>, <fraction>2<denominator>3</fraction> and <radical>3<radicand>125</radical>.

3) Assure compatibility with a reasonable subset of TeX

As already stated by others, many (most?) potential users of HTML5 Mathematics already know TeX, and if common TeX constructs cannot be reliably encoded, they will quickly move on to (or wait for) something else. If Wikipedia's subset of TeX [1], which seams to cover the most commonly used syntactic constructs, can straightforwardly be transcoded, then Wikipedia would in all probability offer HTML5 Mathematics as a rendering option, which would potentially give the new format a flying start. I would be most keen to learn to what extent the existing drafts would be able to represent the mathematical constructs covered by this particular subset of TeX adequately.

[1] http://en.wikipedia.org/wiki/Help:Formula

4) Make font selection simple and natural

This point does not seem to have attracted quite the attention it deserves yet.

TeX seems to have got things right on this point by making italic the default for letters and roman the default for numbers. Is this approach completely unfeasible within the HTML/CSS framework?

If either numbers or letters (variables) have to be marked up explicitly, the choice should be obvious. Nevertheless, writing something like <m><var>a</var><var>x</var><sup>2</sup> + <var>b</var><var>x</var> + <var>c</var> = log <var>d</var></m> is somewhat cumbersome, which will inevitably lead to <m><var>ax</var><sup>2</sup> + <var>bx</var> + <var>c</var> = log <var>d</var></m> or even the complete omission of <var> tags.

On the other hand, TeX's approach will render the last part of the formula $ax^2 + bx + c = log d$ as the product l*i*m*d, a fact which will probably will make the author realise that something is wrong and make him change log into \log.

It could be argued, of course, that authors' laziness should be disregarded, which might be right to a certain extent, but we do not want to make their work too troublesome either.

How are non-italic variables supposed to be handled? Using attributes, like <var class="italic">, <var class="bold">, <var class="blackletter">, <var class="roman">, etc. may be part of the solution, even though it would be quite verbose. At the very least, a (minimal) set of font-styles should be clearly defined.

5) Avoid unnecessary complexity [less important section]

Quite a few years ago, my mother was employed by a newspaper to type text written by journalists. In order to allow correct hyphenation of words, she had to encode every possible hyphenation point in each word. One could argue that the same should be done on the web, as the reader's browser's hyphenation rules (if such a thing even existed) cannot be expected to handle text on the Internet correctly because the vocabulary is unknown (as is the author's hyphenation preferences, but I digress.). Still, nobody does this, and hardly anyone complains about it.

Correct splitting of continuous fractions seems like a similar non-problem. If a fraction is really overly long, then the author should probably split it manually.

6) Build on existing standards

When making something from scratch, then the risk of making a mistake is clearly higher, and the new language will be unfamiliar to everyone. 

It might be useful to discuss the problems inherent in existing languages in some detail, including (possibly simplified) MathML (semantics? not strictly left-to-right and top-to-bottom?), a subset of TeX (no angle brackets? impossible to add CSS support?), and ISO-12083 (inconvenient tagnames?).

-- 
Andersen

PS: I would very much welcome a default rendering of the existing and yet-to-be-written code examples in the drafts.