On May 26, 2006, at 16:58, <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
http://hsivonen.iki.fi/
