[whatwg] Mathematics in HTML5

[juanrgonzaleza at canonicalscience.com]

**What is the goal?**

If I understand James and Ian’s statements correctly, the play is that
either one provides a perfect markup in less than 12 tags can offer us
dinamical pages with TeX quality for liquid layouts and generic web fonts
(even TeX cannot), was implemented in browsers with zero changes in the
parser =:-0 and was accepted and broadly used by community before was even
introduced in the draft of the spec OR one would implement THE
alternative.

The alternative is p-MathML 2 markup which is DOM unfriendly, CSS and
XSL-FO unfriendly, and even XML or HTML unfriendly:
<tag1><tag2>ccc</tag2></tag1> and <tag2>ccc</tag2> are not equivalent in
XML or HTML but can be in MathML.

The alternative introduces dozens of presentational markup elements
violating basic web guidelines. The alternative is incomplete and needs of
another several thousand of dozens of tags (c-MathML 2 and OpenMath
extensions) specially if accesibility is a target (and it is by law in
some countries).

The alternative needs of additional DOM and style specific extensions
since available CSS, XSL-FO, and DOM do not fit (really MathML does not
fit in the rest of the web).

The alternative is spreading ugly, structurally incorrect, and inaccesible
code on the web. Take the case of Distler Mussings blog, after several
attempts and a recent correction based in my "review" now it changed the
way {ds}^2 is encoded, but still the structure and the visual rendering
are wrong: e.g. ds is rendered in italic with small space between d and s
whereas the same ds -but in {ds}^2- is rendered without space and in roman
font.

Yes, the visual rendering of the alternative is, in many ocasions, poor:
certain nested fractions, matrices, and array structures, tensors, some
subsup constructs, predefined MathML entities. Moreover, due to
difficulties for authoring MathML code one can see incorrect renderings on
many MathML code generated by usual MathML tools: HERMES, IteX, ORCCA
translator, MathCast, ASCIIMath, and others. Some of equations contained
in canonicalscience site were corrected by hand after being generated by
popular MathML tools. I would do more fine-tuning of some equations still
remaining incorrect rendering in current version of the site but I decided
stop that nonsense since MathML is not way. I will update lot of examples
(extracted from academic sites where good visual quality is one of first
requisites) in canonical science today blog in near future.

The alternative (the spec) does not specify how one would encode something
so simple as \dot{q} and there was some intense debate about that topic
this year in the w3c MathML list with three main postures: all-Unicode
(minoritary), all-MathML (only Bruce), Unicode+MathML (mayoritary and
probably introduced in next MathML spec). Yes, you read ok, after 10 years
the first w3c attempt to encode mathematics on the web, we were discussing
how a trivial \dot{q} would be encoded just some months ago!!! Mathematica
5.2 visual rendering of the MathML code generated by IteX for \dot{q} was
poor that if hand-drawing by a 5 years babe!!! See MathML list for
details, links, and fragments of code.

The alternative needs of so many efforts on the browsers side that
browsers are ignoring it and even the own w3c editor/browser has a partial
support of p-MathML (c-MathML is ignored by Amaya).

The alternative (using more tags) is not able to encode script structures
could be encoded in ISO-12083 markup model (developed before). Moreover,
the number of tags increases exponentially in MathML for each new script
structures were added in future specs. because of the base interference
problem of MathML incorrect design.

The alternative adds both new parsing and WS rules to those of XML and HTML.

The alternative is formally deficient and it is not rare to see tools
exploiting holes in the w3c specification for generating tricky (nonsense)
code: e.g. <msup><mrow/><mn>37</mn></msup><mi>X</mi> when the correct code
is
<mmultiscripts><mi>X</mi><mprescripts/><mn>37</mn><none/></mmultiscripts>.

Moreover, Ian’s specific proposal introduces still more additional
(backward incompatible) parsing rules.

And the specific problems with Gecko MathML support: non-incremental
rendering...

I do not see requirements imposed to mathematical markup are being imposed
to MathML not in others parts of the spec: calendars, canvas. Is not the
"gauge" a bit unbalanced?


**Usage of weak arguments agains MathML alternative**

In this list I have heard.

- CSS approach cannot compete with MathML rendering quality

But I can provide examples of contrary! In fact, I will do in canonical
science today including snapshots of different formulae obtained from real
sites.

- People ask for MathML in HTML5.

People in this list asked for HTML-Math proposal and I think that almost
all participants in this list expressed some disapointment with MathML.

- People is not using MathML because cannot be used in HTML. That is, lack
of interest in MathML is mainly traced to XHTML trouble.

False. People can use MathML directly in HTML pages since years (see
recent link)

[http://www1.chapman.edu/~jipsen/mathml/asciimath.html]

Still authors are rejecting MathML.

- MathML is not popular in browsers because small target

False, same people (e.g. Microsoft) rejecting native support in browsers
is supporting MathML offline. The big problem with MathML is that is
browsers unfriendly and reason is rejected whereas developers focus on
implementation of other funcionalities in browsers.

- Implementation of HTML-Math is very expensive.

False again, with HTML-MathML being many times more expensive since spec
is more complex, ugly, redundant, and needs of lot of additional code,
tests, and extensions for correctly work: CSS extensions, DOM extensions,
Parser extensions...

- The CSS approach would prove is working before being implemented.

Where it has been proven that MathML is working on the next basic points:
i) structural markup. ii) visual rendering, iii) accesibility?

Please provide real code from the web rather than theroretical analisys.

- We, Ian and James, are providing an alternative

This sound me, cianure or guillotine?

**Political issues again?**

Since main emphasis of Ian and James discussion is not in technical issues
(I do not know of a single technical contributions to the math draft) but
in political and sociological issues. I am obligated to ask: Is there
hidden political points below this dicussion?

I ask because there was further politicial issues on MathML specification

"However, as I have observed again and again during the decade I've
devoted myself to the issues of electronic mathematical communication,
the principle challenges are not technical, but political. MathML is not
the way it is exclusively because of language design considerations --
it is the way it is because it was the politically feasible compromise
between the many conflicting interests of the consortium members that
had a stake is standardizing a markup for math notation."

Robert Miner (w3c MathML 2.0 editor)

"But as a standards organization, W3C cannot and should
not favor the interests of one particular interest group over others.
This is particularly true, as I explained in an earlier message, since
W3C is directly accountable to it dues-paying member organizations, and
only indirectly accountable to individuals with no official standing,
such as yourself."

Robert Miner (w3c MathML 2.0 editor)

Last part to be read like more dollars (or euros) imply more control of
final specs.

If reply is affirmative, some of us would waste our time in more
productive goals.



Juan R.

Center for CANONICAL |SCIENCE)