W3C home > Mailing lists > Public > www-math@w3.org > February 2014

RE: Math Working Group Charter

From: Daniel Marques <dani@wiris.com>
Date: Wed, 19 Feb 2014 15:52:10 +0100
Message-ID: <5ee89a145af2edf6610666a405ee49a1@mail.gmail.com>
To: Frédéric WANG <fred.wang@free.fr>, www-math@w3.org

In fact, MathML touches the "Web Platform". Web browsers support embedding
any XML in the document and the access to it is straightforward using DOM
(this was possible only after IE fixed some lack of compatibility). Thanks
to that, it is possible to handle MathML or, eventually, any other XML
format like CML.

There are many things browsers can do to improve the usage of MathML while
not implementing the specification at all. For example, the attribute altimg
(and the whole altXXX attribute family) of the top level <math> tag could be
easily supported by most browsers. By providing a good support of the
WAI-ARIA standard, any implementation of MathML (native or as an add-on)
will also benefit from it. It is our duty to push in this direction.

Regarding computing the metrics and other font information from JavaScript,
this is a feature that JavaScript will implement sooner or later. Not
because any JavaScript based MathML render engine needs it, but because many
other general applications will benefit from it. Just imagine the Google
Drive Drawing tool where it could be possible to get more control over
rendered text.

Daniel Marques from WIRIS

-----Original Message-----
From: Frédéric WANG [mailto:fred.wang@free.fr]
Sent: miércoles, 19 de febrero de 2014 7:22
To: www-math@w3.org
Subject: Re: Math Working Group Charter

@Paul: I think the idea behind the Web platform is to extend the Web with
higher-level functionalities using Javascript and other HTML5 technologies
(including MathML) not to reinvent the wheel by implementing all the
low-level browser features (although I won't be surprised that some JS
extremists want that). So since you moved the discussion to text rendering,
note that it is one of the most complex part of browser layout and I don't
believe anyone is crazy enough to try to reimplement it in Javascript by
positioning individual glyphs with <span>'s etc. By extension, this is true
for math rendering which can be seen as some complex text layout. Even if
the lack of interest of some browser vendors has lead people to rely on
polyfills to fill the gap here, this is not justified from a purely
technical point of view.

So concretely to come back to the case of science, I believe the idea behind
the Web platform is to rely on native HTML5 features like MathML, SVG or
WebGL in order to create higher level features to easily do TeX-to-MathML
conversion, graph drawings, 3D schemas etc and not to do low level math
layout, which is one thing MathML was designed for. IIUC, that's the aspect
the MathJax project would like to progressively focus on once the native
MathML issue is fixed. This is also the kind of higher level API that I'm
sometimes missing for my EPUB samples.

Frédéric Wang
MathML Crowdfunding: ulule.com/mathematics-ebooks
Received on Wednesday, 19 February 2014 14:52:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:27:46 UTC