[whatwg] Mathematics on HTML5

[Henri Sivonen]

On May 26, 2006, at 16:58, <juanrgonzaleza at canonicalscience.com> wrote:

> Now I learned XSL-FO and even if tomorrow was implemented in browser I
> would *not* use FO.

XSL-FO is not popular around here.

> But biggest error was try to use MathML. MathML is full of incorrect
> design options and technical holes! Even some MathML author recognizes
> that content MathML was not "well thought" due to lack of agreement  
> on the
> committee.

I am pretty convinced that the granularity of markup needed for math  
and the verbosity of XML necessarily lead to an XML syntax for math  
that is not suitable for direct human authoring. However, I think it  
does *not* necessarily follow that an XML syntax for math is an  
inherently bad idea.

For example, the XML syntax for RELAX NG is rather inconvenient for  
human authoring. You really want to write the Compact Syntax instead.  
However, being able to process RELAX NG as XML can be useful in some  
situations.

Likewise, one could consider LaTeX or the Mathematica language as  
compact authoring syntaxes for MathML. (Though that could work better  
if MathML was a straight bijective XML mapping of the default LaTeX  
math macros.)

Math even more than schemas or vector graphics needs to have an XML  
syntax, because math needs to integrate in prose on a more profound  
level than e.g. replaced elements would allow.

> 1) Insanely complicated and inefficient. In some cases, I have  
> computed 15
> times more bandwidth and server storage when using MathML than
> alternatives.

gzip

> 2) Not fully compatible with other basic technologies such as CSS  
> and DOM.

How is MathML not compatible with the DOM?

> Well MathML is not really based in those. But we can render math using
> just HTML, and CSS, and we can use JS and DOM in the same way we  
> use in
> HTML or CSS for text. Look XML-MAIDEN
> [http://www.geocities.com/csssite/index.xml] for ideas, samples, etc.

Interesting. However, the results have the look and feel of a  
afterthought math editor for a word processor rather than the look  
and feel of pdfLaTeX output.

> One of problems
> with this approach is that once new STIX fonts available I can use  
> them in
> HTML, also in CSS rendering of math, but I cannot use them in firefox,
> since MathML module would be rewritten, and the full engine  
> recompiled,
> obligating to users to download and install new versions of browser  
> for
> new fonts!!!

The PUA mapping is indeed a problem. If you want to see a change  
here, I suggest creating an OpenType font that uses the Type 1  
outlines from the YandY version of Computer Modern and has proper  
Unicode mappings.

> 4) The default printing of MathML is not good and people is  
> returning to
> TeX for that!

In general, Knuth was over 20 years ahead of everyone else. CSS-based  
typesetters are still catching up with TeX on some things. (And the  
bar is pretty high.)

But yes, if you want to print math, pdfLaTeX is the best thing  
around. Changing the syntax of MathML does not help in catching up.  
Improving the rendering engine does.

> 5) Accessibility is very deficient

A different syntax won't help. Implementations of accessibility tools  
will.

> Moreover, the situation is still poor than that! Many sites claiming
> theoretical accessibilities (e.g. Distler blog) are serving (ds)^2 as
> <mi>d</mi><msup><mi>s</mi><mn>2</mn></msup>, i.e. 2s ds!!!

I'm pretty sure Distler doesn't claim his math to be accessible, and  
I'm pretty sure he is quite aware of the paradox that AsTeR does not  
support MathML even though its author was on the WG.

http://golem.ph.utexas.edu/~distler/blog/archives/000199.html

> 6) There are problems with default rendering of entities

XML entities on the Web are b0rked. Since MathML is not human- 
writable anyway, let's get rid of the entities.

> Accessible code render ugly in screen whereas
> visually correct code being inaccessible.

"Accessible" code is just theory, right?

> 7) The possibility for automated searches of math continues being  
> largely
> a myth.

Many, many things related to searchability, internationalization and  
accessibility are myths in the realm of semantic markup.

Many times stylability is the benefit of semantic markup that people  
can easily observe and the rest tends to be theory-based hearsay.

> 8) Visual rendering is not incremental as in CSS. This can offer us
> problems with large documents or even with server failures. I find  
> just
> curious the w3c emphasis on abandoning non incremental rendering of  
> old
> HTML presentational table layout models in favour of CSS layouts,  
> whereas
> forcing usage of a non incremental MathML presentational markup. Some
> mathematical documents take order of 10 minutes before rendering in
> Firefox.

This is not a design problem with MathML. This is Mozilla bug #18333.

> 10) Advantages of being using a "standard" vanish when one observes  
> the
> infinite malleability of mathml code. For example people is simulating
> tensors with nested msup, msub, msubsup, and tricky mrows, instead  
> using
> <multiscript> and <none/>. Then hypothetical standardization  
> advantages
> are lost.

Yeah, MathML is presentational in practice.

> 12) The use of presentational markup is contrary to common sense.

Is LaTeX contrary to common sense? Which looks better a LaTeX  
printout or a Mathematica printout?

> A) Eliminate next text from specification
>
> "Authors are encouraged to use MathML for marking up mathematics"
>
> because authors would use more concise powerful and solid markup for
> mathematics.

-1 at least until an alternative is implemented and deployed in UAs.

> C) A more complete approach is providing a set of structural and/or
> semantic tags for usage with HTML5.

Scope creep.

> One needs little tags, because <sub>, <sup>, <var> and <table> can be
> reused.

I don't believe that considering that vast feature set LaTeX needs to  
provide.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/