W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2006

[whatwg] Mathematics in HTML5

From: <juanrgonzaleza@canonicalscience.com>
Date: Thu, 8 Jun 2006 11:21:03 -0700 (PDT)
Message-ID: <3032.217.124.88.212.1149790863.squirrel@webmail.canonicalscience.com>

Henri Sivonen wrote:

> I think it is an economic problem rather than a technical problem.

Yes, this may be reason that a single man was able to do math in a browser
via XML-MAIDEN project in a few months, whereas dozens of others and even
entire communities cannot do it even after of 10 years. Money may be also
the reason of fiasco of IBM TeX approach to the web and of Wolfram fiasco
to the web via Wolfram draft (remember?). George alone may be more rich
that IBM, Desing Science, Wolfram Research, and others joined.

> It follows that I don't think the slow adoption is *necessarily*
> evidence of technical flaws.

Then you know nothing of the history of math on the web. I would recommend
you begin to revise history from the very beginning: HTML 3 Math, the
first draft from the w3c. Attemtp to search why was completely rejected.

> The part of population that is interested in mathematical typesetting
> is very small in proportion to the population as a whole. As I
> understood it at the time, that's why Netscape wasn't interested in
> devoting developer time to MathML. I don't know how decision making
> works at different browser companies, but I would hazard a guess that
> from the point of view of Opera, Apple and Microsoft, the business
> case for MathML is rather lousy compared to e.g. SVG, which is known
> to have spec problems as well, which conflicts with CSS and which   also
> doesn't work in text/html.

Well, always that anyone say me that math is for some little ones I always
reply then why MSWord has an equation editor?

Curiously history says contrary. History says that Microsoft was
interested in providing native MathML support for MSIE and initially
joined to MathML WG but due to technical problems they after rejected
native support and just added some improvements to MSIE for suporting of
third parties plugins. Mozilla has attempted to support MathML and even
most simple tests fail. Opera developers were interested in mathematics
but not in MathML because thecnical weakness of latter (see comments from
developers in the links I provided), etc.

I was interested in a full support for MathML in The Center for CANONICAL
|SCIENCE) but I abandoned the project by thecnical issues (technical
errors and weakness of MathML).

Content MathML is not supported because problems again and even very
recently it has been proved that something so simple as ?integral sin x
from 0 to x? is not correctly encoded in MathML due to an incorrect
desing.

Then people wannot waste time and money with never-working-thecnologies.
Because in the end you obtain an expensive technology that is poor that
old cheap ones.

> Hmm. Freaky economic problems are nowadays solved with Google money. :-P

Have you asked them about support of MathML? I did!

> FWIW, I completely agree with James Graham that automatic conversion
> from LaTeX is *the* top-of-the-list requirement for any kind of Web
> math.

Remember that MathML has not achieved that still.

> That already puts MathML ahead   of
> anything else that WHAT WG could come up with.

I think that you simply do not know you are talking here.

> If the WHAT WG really intends to address math, I think it would make
> sense to start by interviewing Roger Sidje, Jacques Distler, Eitan M.
> Gurari and Robert Miner to find out what they think are the problems
> that need to be solved (if any).

Robert Miner knows very well the limitations of MathML. Robert Miner has
recognized in public that MathML design is not so good because has
?political issues? in the w3c committe.

A pair of months ago he also publicly become interest in that would be
changed in future MathML 3.0 for doing it CSS friendly and suitable for
easy implementation in browsers. George offered him the short list of
changes.

Jacques Distler have attempted to offer mathematics in his blog using
*presentaional* MathML 2.0. He has largely failed and provides us
incorrect semantics, wrong structure, innaccesible and not searchable
code, and incorrect rendering of mathematics during years. Moreover, he
uses a very ugly approach based in a plugin for a IteX dialect is rather
limited.

For a small number of examples of very wrong (nonsensical) code Distler is
serving to the internet can see my

[http://canonicalscience.blogspot.com/2006/04/scientific-language-canonml-is.html]

Some of incorrect formulas the was encoding via MathML 2.0 were better
encoded in several geocities HTML pages by undergrad students.

In fact, I curiously said that the element of line for 5D spaces could be
better encoded using old but effective HTML code

<SPAN>ds</SPAN><SUP>2</SUP>

and Distler incorrectly thouhg that this was the way he would change the
mathML code of his inefficient blog. In fact just a pair of days ago the
change the code of element of line of (see above link for details)

[http://golem.ph.utexas.edu/~distler/blog/archives/000635.html]

to current

<msup><mi>ds</mi><mn>2</mn></msup>

that is a copy of my above HTML code. Unfortunately the code he generates
now continues being structurally invalid, inacesible to people with
disabilites, not searchable and rendering incorrectly. See my very recent
post in MathML list for more details:

[http://lists.w3.org/Archives/Public/www-math/2006Jun/0000.html]

If after 10 years people spacialists as Distler are still unable to encode
something so simple as (ds)^2 in despite of many efforts, time, money,
plugins, special mimes, authoring tools, fonts, rendering engines, special
fonts, two or three specifications, special markup, and devoted dialect of
LaTeX... then...

Curiously we can encode (ds)^2, rendering correctly, being structurally
valid and accesible when taking alternative ways.

Juan R.

Center for CANONICAL |SCIENCE)
Received on Thursday, 8 June 2006 11:21:03 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:27 UTC