[whatwg] Mathematics on HTML5
hsivonen at iki.fi
Fri May 26 10:27:16 PDT 2006
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
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
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 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
> 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
> obligating to users to download and install new versions of browser
> 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
> 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
> 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.
> 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
> 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
> curious the w3c emphasis on abandoning non incremental rendering of
> HTML presentational table layout models in favour of CSS layouts,
> forcing usage of a non incremental MathML presentational markup. Some
> mathematical documents take order of 10 minutes before rendering in
This is not a design problem with MathML. This is Mozilla bug #18333.
> 10) Advantages of being using a "standard" vanish when one observes
> infinite malleability of mathml code. For example people is simulating
> tensors with nested msup, msub, msubsup, and tricky mrows, instead
> <multiscript> and <none/>. Then hypothetical standardization
> 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
-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.
> One needs little tags, because <sub>, <sup>, <var> and <table> can be
I don't believe that considering that vast feature set LaTeX needs to
hsivonen at iki.fi
More information about the whatwg