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

[whatwg] Mathematics in HTML5

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


Ian Hickson wrote:
> I would say MathML is not widely used because MathML doesn't work in
> HTML,  personally.

I do not know from where this idea get up. SVG is relatively popular and
implemented in many browsers, but the same browsers implementing SVG are
rejecting MathML. They are rejecting because difficulties for
implementation, not because HTML lack of.

The original mathematical work from the w3c was mathematical markup FOR
HTML. It was drafted so early as in HTML 3 epoque and strongly rejected by
community. Unfortunately subsequent first draft of MathML, MathML 1.x and
recent MathML 2.0 all habe been rejected by technicla motives rather than
HTML-relationship.

In fact, I do not know a single criticism to MathML emphasizing the point
you state. All public criticism are to design options and technical
details independent of host language.

> If we made MathML work in HTML, possibly with rules
> that make  the syntax easier (by implying tags as I suggested earlier),

Curiously, I suggested similar approach in my previous CanonMath language

[http://canonicalscience.blogspot.com/2006/02/choosing-notationsyntax-for-canonmath.html]

one could write something like

<CanonMath>
a+b<fraction/>2
</CanonMath>

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

next was converted to full presentation MathML 2.0, but it was strongly
rejected by MathML authors, see Carlisle reply for instance

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

Moreover, your proposal would be rejected by most authors and developers
(today rejecting MathML) because obtain all difficulties and limitations
of current MathML (between them incompatibllity with DOM, CSS, XSL-FO.)

More the rejection from w3c MathML guys that do not want to see a mixture
of textual strings with MathML own elements.

> then that  might well change, especially given that one UA already has
> extensive  and high-quality support for MathML.

I imagine that you mean Firefox browser with native MathML. Well I would
not call that ?extensive and high-quality support for MathML.?

I would say, ?partial incompletete support of less than one half the
official specification?.

Content MathML is not supported, only presentation MathML; of presentation
MathML not all tags are supported; of all tags supported not all are
working.

You can begin from the most simple teste of the MathML official test suite
and can see that MathML suport is weak in browser (I use Firefox 1.0) and
even most simplest test are either not correctly rendered or not at all
(compare with sample GIFS).

http://www.w3.org/Math/testsuite/testsuite/General/Math/math3.xml

http://www.w3.org/Math/testsuite/testsuite/General/Math/mathAdisplay1.xml

http://www.w3.org/Math/testsuite/testsuite/General/GenAttribs/style1.xml

http://www.w3.org/Math/testsuite/testsuite/General/GenAttribs/style2.xml

http://www.w3.org/Math/testsuite/testsuite/Presentation/TokenElements/mi/miAtoken5.xml

http://www.w3.org/Math/testsuite/testsuite/Presentation/TokenElements/mi/miScolorscope7.xml

http://www.w3.org/Math/testsuite/testsuite/Presentation/TokenElements/mi/miSfonts8.xml

http://www.w3.org/Math/testsuite/testsuite/Presentation/TokenElements/mi/miSfontsize9.xml

http://www.w3.org/Math/testsuite/testsuite/Presentation/TokenElements/mi/miSmathsize17.xml

http://www.w3.org/Math/testsuite/testsuite/Presentation/TokenElements/mi/miStoken10.xml

http://www.w3.org/Math/testsuite/testsuite/Presentation/TokenElements/mn/mn3.xml

http://www.w3.org/Math/testsuite/testsuite/Presentation/TokenElements/mn/mnAcolorname5.xml

http://www.w3.org/Math/testsuite/testsuite/Presentation/TokenElements/mn/mnAtoken6.xml

http://www.w3.org/Math/testsuite/testsuite/Presentation/TokenElements/mo/moAlargeop12.xml

http://www.w3.org/Math/testsuite/testsuite/Presentation/TokenElements/mo/moAminmax14.xml

http://www.w3.org/Math/testsuite/testsuite/Presentation/TokenElements/mo/moAmovable15.xml

http://www.w3.org/Math/testsuite/testsuite/Presentation/GeneralLayout/mrow/mrowBinferred2.xml

http://www.w3.org/Math/testsuite/testsuite/Presentation/GeneralLayout/mfrac/mfracAbevelled16.xml

http://www.w3.org/Math/testsuite/testsuite/Presentation/GeneralLayout/mfenced/mfencedAdelims6.xml

http://www.w3.org/Math/testsuite/testsuite/Presentation/GeneralLayout/mfenced/mfencedBfences7.xml

http://www.w3.org/Math/testsuite/testsuite/Presentation/ScriptsAndLimits/msubsup/msubsup1.xml

http://www.w3.org/Math/testsuite/testsuite/Presentation/ScriptsAndLimits/munder/munder1.xml

http://www.w3.org/Math/testsuite/testsuite/Presentation/ScriptsAndLimits/munder/munder2.xml

http://www.w3.org/Math/testsuite/testsuite/Presentation/ScriptsAndLimits/mmultiscripts/mmultiscripts2.xml

http://www.w3.org/Math/testsuite/testsuite/Presentation/TablesAndMatrices/mtable/mtable1.xml

http://www.w3.org/Math/testsuite/testsuite/Presentation/TablesAndMatrices/mtable/mtableAwidth1.xml

http://www.w3.org/Math/testsuite/testsuite/Presentation/TablesAndMatrices/mtable/mtableBsize1.xml

And many other test are not passed by the browser. However, most of those
test could be easily passed via a CSS approach such as that designed by
George. And in fact I believe that allmost (if not all) of above official
test could be passed *today* by Opera browser simply using CSS 2.1 and XML
MAIDEN markup.

Moreover some of MathML renderings (e.g. roots) in firefox only can be
achieved via downloading and installing special fonts. Fonts (CM) are
*not* designed for web. Moreover, due to special implementation of Mozilla
render module and TeX fonts. If tomorrow I can use special scientific
fonts (STIX ones for instance) I can use the fonts in George approach and
they will render in Opera browser, but not in Firefox, because for each
new set of fonts to be implemented in MathML engine, the whole core needs
to be recompiled! Therefore I you want use some future font in mathematics
wait until developers recompile source and launch a new Firefox browser
then donwload it and install in your computer. Cheap not?

Of course, all this is based in that MathML IG simply developed a markup
language incompatible with available technologies and difficult (or
imposible) to be fully implemented in browsers. MathML is a fiasco.
Explanation I have heard from some w3c people has been that browser
developers are 666 and that CSS guys want nto support MathML and that
authors are ?stupid? and only like LaTeX...

Ups! and do not forget that due to specificies of Gecko engine, some large
MathML documents can need of 10 minutes before being displayed in the
browser (without incremental rendering of any class), which is completely
unacceptable for users.

H?kon Wium Lie wrote:

> It takes years and years to produce new presentational features, write
> test suites and make them work interoperably. At this stage, any
> effort that relies on new CSS properties is a decade away from full
> deployment. By contrast, changing markup on the author side is very
> easy. So, I'd rather make the markup language CSS-friendly (and
> author-friendly) than the other way around.

Yes! I had a similar debate with MathML WG this year and similar thoughts.
See my reply to Miller

[http://lists.w3.org/Archives/Public/www-math/2006Apr/0030]

> Historically, it's a common mistake to develop markup systems without
> giving much thought to presentation. For example, only when SGML was
> done did one start efforts to create a style sheet language for it
> (FOSI/DSSSL). Likewise with HTML. Given that CSS existed when MathML was
> created, I think the developers made a mistake by not creating a markup
> language that could be presented using existing CSS properties.
>

See also the ?excuse? on why they ignored CSS and decided reinvent the
wheel. It is curious as they believe that CSS support would be marginal
but that is being marginally supported in precisely MathML (even after 10
years!!).

But the MathML IG ignored also other previous approaches. For example
instead reusing previous ISO-12083 they reinvented a new ugly language
nobody is really using. George beginning from ISO12083 and doing minimal
changes (for CSS compatibility) is able to render mathematics in a browser
without sepcific mathematical code (only supporting standard CSS 2.1).

Content Markup also ignored previous lesson and there is lot of errors in
the markup. For example problems with binding and compositional design
begin to be solved in last versions of content MathML and OpenMath when
same problems had been solved in programing languages as LIPS decades ago.

The MathML IG has a tendency to ignore previous works and reinvent the
wheel (and like someone pointed in the Internet ?doing it squared?).

Ian Hickson wrote:

> Why not just re-use MathML? MathML already has defined semantics, a
> defined interpretation based on DOMs, defined DOM interfaces, and an
> implementation in at least one browser.

It is difficult resume tons of criticism, but basically we would not use
MathML because does not work well, and is incompatible with DOM, CSS,
XSL-FO, and even with the own XML. Since it is incompatible with available
technology it cannot be fully implemented in browsers, or in print
engines, since language is tecnhically defficient most of tools generate
invalid scary code is not searchable not accesible, since there is not
future (not present) search engines ignore the specification.

MathML specification also obligates you to learn additional redundant
methods, elements and attributes. For example, you are obligated to learn
a way to change font size or bold typeface in text but may learn other way
in MathML code. Moreover MathML violates the most basic web guidelines:
splitting content from presentation. One writes a semantic or structural
code in XML or HTML next is styled via CSS. MathML offers mathematical
versions of the deprecated <font> and family tags.


Juan R.

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

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